SDL Forum Index
SDL
Simple DirectMedia Layer Forums
Reply to topic
actsl


Joined: 09 Feb 2016
Posts: 83
Reply with quote
MrTAToad wrote:
The only slight problem at the moment is text selected from a dropdown option can overwrite the text entry box (and not clip) - that can be sorted later.

I don't understand what do you want to do.

_________________
kiss_sdl - Simple generic GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
View user's profileSend private message
kiss_sdl - Simple universal GUI widget toolkit for SDL
MrOzBarry


Joined: 26 Jun 2010
Posts: 620
Reply with quote
I'm just going to chime in as a FRP sort of guy, I agree there are good cases for globals when it comes to constants, but be weary when globals are modified during the lifetime of the app.  If you have some sort of state attached to kiss_sdl that is completely localized, you may want something like:

Code:

struct {
  // Things that would normally be global go in here
  SDL_Renderer *renderer;
} KISS_STATE;


KISS_STATE *kiss_init(...);



From here, you have two options.  One is you have a single swappable global state, ie:


Code:

kiss_use_state(KISS_STATE *);
KISS_STATE *kiss_get_state(void);
KISS_STATE *kiss_copy_state();
// For any function that needs to use a global var, use kiss_get_state().  If you need to modify it,  copy it, modify the copy, then kiss_use_state on the copy.



This will break all the examples, but it's only a few lines to change.  You could have kiss_init still rendering an SDL_Renderer * and create a global KISS_STATE in the background, for compatibility.  You'd have a separate `KISS_STATE *kiss_init_state()` method that would eventually be the migration path


Or you pass the KISS_STATE* into every function that needs access to the global state.  This is a much more painful refactor, but it has some advantages with immutability.  I could go on about the merits of this approach, but the bottom line is that it is a very painful refactor, and will break every example and every project using it.



But again, this is just opinion.  The idea of your keeping it simple means that what you currently have, along with globals, is probably the simplest, so don't take what I wrote as heavy criticism or a need to refactor, just thoughts.


On the brighter side, good job, this is a neat little ui kit to get a simple app off the ground!


On Mon, Jul 4, 2016 at 4:59 PM, actsl wrote:
Quote:
It is ok to modify, it is made for that.

There is by itself nothing wrong in global variables, it is important how they are used. Getting rid of global variables is the easiest way to avoid all the problems they may cause, but it is just a no-brainer to solve the problems. In kiss_sdl, global variables are supposed to be used as constants only, and changed only during the initiation. When one really does not like them, then it is ok to get rid of them, but i didn't do it because i didn't want to make the code more complex. One more argument to the functions, or one more member to the structures, all matters. Or if you have some other reason why you want to get rid of them, have several sets of settings or whatever, that's perfectly ok.



kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

View user's profileSend private message
actsl


Joined: 09 Feb 2016
Posts: 83
Reply with quote
kiss_get_state() is to get a pointer to a global structure by function? Accessing by function enables to modify access, etc, but i don't think it is necessary in the default version, as global variables are used there just as simple constants. That is of course, a user should observe that, which is not that good, as some users may ignore that and change global variables, and then complain about unknown problems. It is a more flexible method, but it adds complexity. And the ultimate goal was that the default version were simple, so that new users can quickly start to use it, then change it when they learn more and need to do that.

I have also written an interpreter, where all was reentrant and thread-safe, no global variables of course. But there it was necessary, as one may want to embed the interpreter, and run multiple instances of it simultaneously. It was yet different for the interpreter though, as that interpreter had no global settings used everywhere. Widget toolkit is different in that respect, in that it has certain global settings that are used by all instances, or even threads that there may be.

_________________
kiss_sdl - Simple generic GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
View user's profileSend private message
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Reply with quote
actsl wrote:
MrTAToad wrote:
The only slight problem at the moment is text selected from a dropdown option can overwrite the text entry box (and not clip) - that can be sorted later.

I don't understand what do you want to do.

The problem is that text can exceed the available size - all it needs is a clip rectable setup for the text entry box
View user's profileSend private message
actsl


Joined: 09 Feb 2016
Posts: 83
Reply with quote
MrTAToad wrote:
actsl wrote:
MrTAToad wrote:
The only slight problem at the moment is text selected from a dropdown option can overwrite the text entry box (and not clip) - that can be sorted later.

I don't understand what do you want to do.

The problem is that text can exceed the available size - all it needs is a clip rectable setup for the text entry box

How can it be? The text selected from the text box of the combo box is clipped by the width of the entry box of the combo box (combobox->entry.textwidth) when copied to the entry box of the combo box, by the following, line 802 in the kiss_widgets.c of the kiss_sdl version 1.0.12, in the function kiss_combobox_event() .
Code:
      kiss_string_copy(combobox->entry.text,
         kiss_maxlength(kiss_textfont,
         combobox->entry.textwidth,
         (char *) kiss_array_data(combobox->textbox.array,
         index), NULL),
         (char *) kiss_array_data(combobox->textbox.array,
         index), NULL);

_________________
kiss_sdl - Simple generic GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
View user's profileSend private message
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Reply with quote
Whoopsy - my fault. I was using a kiss_font structure that was defined, but not actually used, so the font advance was always 0...
View user's profileSend private message
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Reply with quote
A very early picture of the theme selection window for my Assembloids game :

[img]https://drive.google.com/open?id=0Bzff3iRdz9JqbjJGd1BodlJaRm8[/img]

It does need changing of course (and a few extra things need to be added), but the general layout is there.
View user's profileSend private message
actsl


Joined: 09 Feb 2016
Posts: 83
Reply with quote
MrTAToad wrote:
A very early picture of the theme selection window for my Assembloids game :

[img]https://drive.google.com/open?id=0Bzff3iRdz9JqbjJGd1BodlJaRm8[/img]

It does need changing of course (and a few extra things need to be added), but the general layout is there.

Thanks, great!

Clickable link to the screenshot (it doesn't work with img tags):

https://drive.google.com/open?id=0Bzff3iRdz9JqbjJGd1BodlJaRm8

_________________
kiss_sdl - Simple generic GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
View user's profileSend private message
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Reply with quote
Yes, really must stop using the IMG tag Smile

Will be adding three things to the system : Horizontal and vertical lines/seperators and the most important : icons, plus flags for buttons - that way centring and whatnot can be automatic
View user's profileSend private message
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Reply with quote
An updated graphic : https://drive.google.com/file/d/0Bzff3iRdz9JqLWNDSVlJUC1wc1E/view?usp=sharing

Some things left to do include changing the font colour to something more readable and to find out why the icon graphic isn't being scaled down.

Finally, the button size needs changing
View user's profileSend private message
actsl


Joined: 09 Feb 2016
Posts: 83
Reply with quote
MrTAToad wrote:
Yes, really must stop using the IMG tag Smile

Yes there seems to be no way to use it with Google drive. There is an iframe provided, but that's for html. I changed html to on in my profile, yet html is still off when posting. And it cannot be done with BBCode in any way.

To embed the images, you may upload them to postimage https://postimage.org or to other image upload sites. I don't know the privacy and copyright things there though. But as it is an early picture, then i provided it here just as an example.

Btw, i found that this thread is now the biggest ongoing thread in the sdl development forum by the number of views. Except maybe the thread about the Windows Phone 8 support, but that too seems to be solved, in that there may not be more Windows Phone 8 support. This shows an interest, or it shows no alternative what concerns any widget toolkits for SDL2, anyone could make to work. Is it interest?


_________________
kiss_sdl - Simple generic GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
View user's profileSend private message
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Reply with quote
I hope it's interest!
View user's profileSend private message
kiss_sdl - Simple universal GUI widget toolkit for SDL
Ben Henning
Guest

Reply with quote
Apologies in advance that I haven't taken a look at the source, but is this an immediately rendered GUI system?

On Sat, Jul 23, 2016 at 5:39 AM, MrTAToad wrote:
Quote:
I hope it's interest!


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: kiss_sdl - Simple universal GUI widget toolkit for SDL
actsl


Joined: 09 Feb 2016
Posts: 83
Reply with quote
Ben Henning wrote:
Apologies in advance that I haven't taken a look at the source, but is this an immediately rendered GUI system?

As i understand this is a question, immediate GUI versus retained GUI such as GTK and Qt.

It is not immediate GUI in the sense that it only renders the GUI elements, it is not that primitive.

The event and draw functions are called directly from the main loop. The rendering and the event processing is not hidden from the user different from a retained GUI, and user can add functionality to both. In that sense it is immediate GUI. This is good for games in that the GUI is not separated from the game, all is done in the same way.

There is always a question of the balance between storing something in the widget's structure (or somewhere else), or calculating it in the drawing (rendering) function. Calculating it in a drawing function provides more flexibility, in that less is calculated when creating the widget, and thus more in the widget's structure can be changed dynamically, after creating the widget, without any inconsistencies when drawing.

One disadvantage of that is speed, though that may not be the most important. The other disadvantage is that it makes the drawing and event functions more complex, which has to be avoided when keeping it small and simple. But it is not about, this and that is right, it is always a question of balance. In kiss_sdl, the absolute preference is that the default version has to be simple, so that the beginners can easily start to use it. And also that the code is simple, so it is easy to understand and thus also easy to change.

The beginners like the simplicity. The advanced users always see it as unnecessarily too restrictive. But the advanced users always know how to change it, and can do it easily. Like rewriting one widget is not so big change, but it may provide exactly what a user may need. Some users have suggested several changes already, maybe there should be some advanced version of it in addition to the simple version, or some repository of different versions.

What concerns simplicity, some beginners may not agree at all, they find very complicated and difficult to understand even the default version that is said to be simple. 2300 lines of code is not exactly a very simple code, even when it is clear and well written, but the matter is that it cannot be done more simply, provided that it also has to be rudimentary and general, to be useful for most common practical purposes. It takes some effort to learn it, and one doesn't even start that effort when one is not absolutely sure that this is the right thing to choose, is high quality, works well, is well documented, has a good technical support, can be used for most purposes one may have, and is also widely used by others who find it to be good. The requirements such that when they are all fully required, then this makes creating any new toolkit completely impossible. This makes keeping it small and simple, an even greater priority.

But providing everything for every possible case, like in the advanced GUI-s such as GTK and QT, is not a good idea, in that it makes the GUI much too complex. And complexity can never be completely hidden, so it also adds complexity to the code and makes the code less easy to understand. And worse than that, makes it inflexible, so that trying to do something that is not provided, requires dealing with and overcoming all the complexity.

So that all is a question of balance. It is said that a bow maker has to have a good sense of proportion, otherwise one cannot make a good bow.

If one knows some immediate GUI-s, one finds that it is not like that or another immediate GUI. There are different ways how immediate GUI-s can be made, and different ways how immediate GUI can be defined. When defining immediate GUI the most generally, in that the event processing and rendering is not hidden from the user, then it is an immediate GUI. But by some other definitions it may said to be a slightly retained GUI, in a very limited way.

_________________
kiss_sdl - Simple generic GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl
View user's profileSend private message
kiss_sdl - Simple universal GUI widget toolkit for SDL
Ben Henning
Guest

Reply with quote
Thanks for your clarification.

On Tue, Jul 26, 2016 at 9:38 AM, actsl wrote:
Quote:



Ben Henning wrote:

Apologies in advance that I haven't taken a look at the source, but is this an immediately rendered GUI system?



As i understand this is a question, immediate GUI versus retained GUI such as GTK and Qt.

It is not immediate GUI in the sense that it only renders the GUI elements, it is not that primitive.

The event and draw functions are called directly from the main loop. The rendering and the event processing is not hidden from the user different from a retained GUI, and user can add functionality to both. In that sense it is immediate GUI. This is good for games in that the GUI is not separated from the game, all is done in the same way.

There is always a question of the balance between storing something in the widget's structure (or somewhere else), or calculating it in the drawing (rendering) function. Calculating it in a drawing function provides more flexibility, in that less is calculated when creating the widget, and thus more in the widget's structure can be changed dynamically, after creating the widget, without any inconsistencies when drawing.

One disadvantage of that is speed, though that may not be the most important. The other disadvantage is that it makes the drawing and event functions more complex, which has to be avoided when keeping it small and simple. But it is not about, this and that is right, it is always a question of balance. In kiss_sdl, the absolute preference is that the default version has to be simple, so that the beginners can easily start to use it. And also that the code is simple, so it is easy to understand and thus also easy to change.

The beginners like the simplicity. The advanced users always see it as unnecessarily too restrictive. But the advanced users always know how to change it, and can do it easily. Like rewriting one widget is not so big change, but it may provide exactly what a user may need. Some users have suggested several changes already, maybe there should be some advanced version of it in addition to the simple version, or some repository of different versions.

What concerns simplicity, some beginners may not agree at all, they find very complicated and difficult to understand even the default version that is said to be simple. 2300 lines of code is not exactly a very simple code, even when it is clear and well written, but the matter is that it cannot be done more simply, provided that it also has to be rudimentary and general, to be useful for most common practical purposes. It takes some effort to learn it, and one doesn't even start that effort when one is not absolutely sure that this is the right thing to choose, is high quality, works well, is well documented, has a good technical support, can be used for most purposes one may have, and is also widely used by others who find it to be good. The requirements such that when they are all fully required, then this makes creating any new toolkit completely impossible. This makes keeping it small and simple, an even greater priority.

But providing everything for every possible case, like in the advanced GUI-s such as GTK and QT, is not a good idea, in that it makes the GUI much too complex. And complexity can never be completely hidden, so it also adds complexity to the code and makes the code less easy to understand. And worse than that, makes it inflexible, so that trying to do something that is not provided, requires dealing with and overcoming all the complexity.

So that all is a question of balance. It is said that a bow maker has to have a good sense of proportion, otherwise one cannot make a good bow.

If one knows some immediate GUI-s, one finds that it is not like that or another immediate GUI. There are different ways how immediate GUI-s can be made, and different ways how immediate GUI can be defined. When defining immediate GUI the most generally, in that the event processing and rendering is not hidden from the user, then it is an immediate GUI. But by some other definitions it may said to be a slightly retained GUI, in a very limited way.



kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

kiss_sdl - Simple universal GUI widget toolkit for SDL
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT  
Page 5 of 6  

  
  
 Reply to topic