The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
kiss_sdl - Simple universal GUI widget toolkit for SDL
actsl


Joined: 09 Feb 2016
Posts: 83
Kiss is a known saying that means "Keep it simple". Different from
other widget toolkits where you are supposed to choose from the existing
widgets the one that fits you the best, in this toolkit, when there is
no widget that satisfies all your needs, modify an existing widget, or
write your own, it is simple to do that. The toolkit was made as simple
as ever possible, to finally solve the problem of an immense complexity
of most of the existing toolkits, which makes it impossible for many
people to even use them. At that it was made universal, many simpler
toolkits don't enable you to do many things that you want, due to their
restricted internal design.

This toolkit uses an original innovative approach for a widget toolkit,
this new approach enabled to make the widget toolkit very simple, and
simpler than widget toolkits previously written. The toolkit is written
in C, but can also be used in C++.

Please see the GitHub project page for more.

GitHub project page https://github.com/actsl/kiss_sdl

The screenshot is smaller than the actual window.

actsl


Joined: 09 Feb 2016
Posts: 83
The kiss_sdl widget toolkit is now improved a lot. It now has a window, multiline label, button, select button, vertical scrollbar, horizontal scrollbar, progress bar, entry box, textbox, and a combo box. All calls to external library functions from the widget functions are abstracted to separate source files, kiss_draw.c, kiss_general.c, and kiss_posix.c. By rewriting these functions, the implementation of the general operations can be changed, and different external libraries can be used. It now also works in Visual Studio, it was tested with the Visual Studio Community 2015. The new version 0.8.0 is in GitHub now.

https://github.com/actsl/kiss_sdl

The size of the screenshots below is now exactly how they appear on the screen.



MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Does it also have radio buttons and selection buttons too ?
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Ah yes, the selection (or rather checkbox) is there...
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Just got it all compiled, and it all works fine. However, changing the font to something else (as I would for my program), does show various clipping problems :

[img]https://onedrive.live.com/redir?resid=3422B1BA7F6B8DB1!4539&authkey=!ACRVDEC8ZBzQTvU&v=3&ithint=photo%2cpng[/img]

[img]https://onedrive.live.com/redir?resid=3422B1BA7F6B8DB1!4540&authkey=!ADopt4xBblPHnns&v=3&ithint=photo%2cpng[/img]

I think a clip rectangle will need to be used (if it isn't already).
actsl


Joined: 09 Feb 2016
Posts: 83
MrTAToad wrote:
Just got it all compiled, and it all works fine. However, changing the font to something else (as I would for my program), does show various clipping problems :

These were not clipping problems. I just released version 0.8.4 :

https://github.com/actsl/kiss_sdl

I tried it, and the problems that were there on your screenshots, were not there any more.

I also added descent, so the select button is now perfectly aligned with the baseline of the text, at least with that ttf font.

Vertically it seems that there is just not enough room for one more line in your combo box. It only draws a line when it can draw it with full height. Also it only draws a character when it can draw it with full width.
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Yes, that works better, although with the used font, it does seem that the combo box is getting the display string rather than the actual string, and thus displaying "Data not found" when selecting a city name that isn't completely displayed.

The only other problem is that to close the combo box you have to select something, rather than being able to click elsewhere to close it (and leave the current settings as they are).
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Word wrapping for static text boxes may be needed later on too...
actsl


Joined: 09 Feb 2016
Posts: 83
MrTAToad wrote:

> Yes, that works better, although with the used font, it does seem that the combo box is getting the display string rather than the actual string, and thus displaying "Data not found" when selecting a city name that isn't completely displayed.

Yes exactly. This comes from what the entry box is, what you see in it, is what there is, and nothing what you cannot see there.

> The only other problem is that to close the combo box you have to select something, rather than being able to click elsewhere to close it (and leave the current settings as they are).

Yes you can close the combo box without selecting anything, press Enter. Because when the combo box is open, this means that its entry box is open for editing, Enter ends the editing of the entry box, and thus closes the combo box. Closing the entry box by clicking outside of it, causes problems, because when the entry box is a part of a composite widget such as the combo box, it cannot take focus.

> Word wrapping for static text boxes may be needed later on too...

You may implement it in your code if you need it. Text box is not a list box the way it may look like, it is what it is called, a text box. The text editors such as vim have the text internally stored exactly in the same way as in the text box, as an array of pointers to strings. Thus everything can be done there, but this depends on what one may want to do, and there is a huge number of such things.

I think that only the basic things need to be implemented in the widget toolkit. They develop toolkits further and further, making them more and more advanced, trying to implement a standard way of doing things even for more complex applications. But if an application is complex, then there is no problem to implement more complex things in that application, thus it makes no sense to implement more complex things in the toolkit.
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
yes, its a very useful system.
actsl


Joined: 09 Feb 2016
Posts: 83
MrTAToad wrote:
yes, its a very useful system.

Thank you, you likely tested it and found that it works faultlessly.

But GitHub views are going down, by an exponential curve, no one is interested.

It is not just another widget toolkit, it is 2287 lines, yet it is universal. Others they say are simple, are over 10 000 lines. Some even say that Qt is simple, they obscure the meaning of simple, as it is in the Simple DirectMedia Layer.

And it is made very easy to change. What else can i do?
actsl


Joined: 09 Feb 2016
Posts: 83
MrTAToad wrote:
yes, its a very useful system.

Thank you, you likely tested it and found that it works faultlessly.

But GitHub views are going down, by an exponential curve, no one is interested.

It is not just another widget toolkit, it is 2287 lines, yet it is universal. Others they say are simple, are over 10 000 lines. Some even say that Qt is simple, they obscure the meaning of simple, as it is in the Simple DirectMedia Layer.

And it is made very easy to change. What else can i do?
actsl


Joined: 09 Feb 2016
Posts: 83
MrTAToad wrote:
yes, its a very useful system.

Thank you, you likely tested it and found that it works faultlessly.

It is not just another widget toolkit, it is 2287 lines, yet it is universal. Others they say are simple, are over 10 000 lines. Some even say that Qt is simple, they obscure the meaning of simple, as it is in the Simple DirectMedia Layer.

And it is made very easy to change. What else can i do?
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
There is not much more to do with it really, aside from making sure that it can be used on systems without keyboards Very Happy

Adding a few simple widgets would be good, namely icons - most others arent really needed.
actsl


Joined: 09 Feb 2016
Posts: 83
MrTAToad wrote:
There is not much more to do with it really, aside from making sure that it can be used on systems without keyboards Very Happy

Adding a few simple widgets would be good, namely icons - most others arent really needed.

Means that it is something like a hammer, easy to use, universal, and always works.

Thank you for testing it.

In GitHub there are a bit more views now, but it doesn't go further so fast. The reason being that people are reluctant to use it, because they don't know it. When they use it, then they will see that it's simple, but they cannot know it, without using it. This makes the curve up exponential too. I have seen that it is more like linear, when something is forced on people, it is exponential when people start to use something because of their free will.

The only thing missing now, is any screenshots and such, of using it in any game or application. Someone asked that in another thread, about what GUI to use for SDL2, where it appeared that this is the only widget toolkit now that anyone knowingly could make to work with SDL2. But even if there are others, then they are likely much more complex and not so easily changeable than this one.

Have you used it yet in any application or game of yours, if so, can you maybe see some screenshots? Or if anyone else has used it, nice to see some screenshots too.

Or I will be glad to answer if anyone wants to ask something.
actsl


Joined: 09 Feb 2016
Posts: 83
it may be that when one writes a graphical user interface for one's game or application, using that toolkit, then it may feel like writing one's own widgets directly in SDL. It is so thin layer, there is not much in between, and thus also not much that restricts one from doing whatever one may want to do. Yet the code there is important, the 1000 lines of C code in kiss_widgets.c and kiss_draw.c , as it shows how to do it. At least important to know, but also good to use as is, when one doesn't want to change anything. With that widget toolkit it thus is that, SDL is high level, and widget toolkit is low level.
Matthias


Joined: 17 Apr 2016
Posts: 3
I appreciate the idea behind your project of a low level gui widget toolkit. I was looking for a SDL based toolkit like this for some time now.

As a suggestion what you could do (and what usually ppl attract to projects like this, because you seem to care a lot about download rates and recognition), make a simple documentation that answers some basic questions like: What widgets are implemented? How to create your own widget? How are they implemented (e.g. code example, how to get a basic button)? How to manage the widgets (object oriented vs. procedural approach)? - Many ppl prefer to have a look into the doc. to see if the project is useful for them rather than to read the raw code or load compiler/IDE specific project files.

Another question I got, is there a focus feature implemented, e.g. can there be two widgets next to each other and you can switch from one to another? To be more specific about what I mean, here are two scenarios: 1) There are two buttons next to each other, the focus can be switched by tab from one to another, if pressing enter, the button which has the focus is pressed. 2) There are two widget forms (are there forms at all?), one of which is layered above the other form. By clicking on the form below it will become active and be shown in front of the other form.

Keep up the great work :-)!
actsl


Joined: 09 Feb 2016
Posts: 83
Matthias wrote:
I appreciate the idea behind your project of a low level gui widget toolkit. I was looking for a SDL based toolkit like this for some time now.

Thank you Matthias.

> make a simple documentation

Yes i have thought that, but then i thought, what should it be, like an explanation of the examples, or then like a reference of all functions, structures and variables. The problem with that is, that when the documentation is long, then this gives to users an impression that the project is very complex, when in fact it isn't. But thank you for suggestions, i would try to write it, when i get a clear idea what exactly to write.

> What widgets are implemented?

A window, multiline label, button, select button, vertical scrollbar, horizontal scrollbar, progress bar, entry box, text box, and combo box.

> How to create your own widget?

Do you mean, create your own custom widget, different from the standard widgets? There are four ways to do that. First is to create a composite widget, from several other widgets, a combo box is an example of this. Second is a user added functionality. Write your own event function and call the standard function from that. Then functionlity can be added in case when the standard function returns nonzero, but also new reactions to mouse and keyboard events can be added. This has to be done the same way it is done in the standard widget event functions though, like at least it should be first checked whether the widget is visible. Third, the functionality can also be added in case if the event is a NULL pointer. Like for games it may be important to add time dependent effects to widgets, like making them to continuously change shape, rather than being static. A progress bar is an example of this. And fourth is to write your own widget, by copying the structure and functions of a standard widget, and modifying them.

> code example, how to get a basic button

The new function for a button calculates its rectangle, copies the button's text and calculates its position, assigns the window argument to the member of its structure, and initializes other members of its structure to zero. The event fuction first writes one to the draw argument when the SDL window is exposed. Then it checks whether the button or the dialog window of the button has a mouse focus, and returns from the function if neither is true. Then it checks the mouse buttons and mouse motion, changes the state of the button based on these events, and returns nonzero when the button is released. A button has three states, normal (active 0, prelight 0), prelight (prelight 1) and active (active one). Normal is when the mouse pointer is not on the button, prelight is when the mouse pointer is on the button, and active is when the button is pressed. A separate image corresponds to each of these states, like in Windows widgets these images have a 3D look. The draw function makes the button visible, when its dialog window is visible. It then renders the image that corresponds to the current state of the button, and renders text to the button.

> How to manage the widgets (object oriented vs. procedural approach)?

No it is not object oriented, each widget has its own structure, it is not more complicated. There are no callbacks or signals and slots. For managing widget, one simply writes ones own event function, and calls the standard event function in that function. The standard function returns nonzero when the widget needs a reaction, like when a button is pressed, this enables to write the reaction. It is not made using callbacks, because callbacks only enable to write the reaction, while this approach enables the user to add functionality.

> Another question I got, is there a focus feature implemented, e.g. can there be two widgets next to each other and you can switch from one to another?

This is not exactly what focus is. A widget has a mouse focus when it processes the mouse events. Widget has a focus when its dialog window has a focus, or when the widget itself has a focus. The former enables a window with all its widgets to take focus, like when a window pops up, then focus can be removed from the window below it. The latter enables a single widget to get focus, so that mouse events don't affect any other widgets. Yes focus can be switched from one widget to the other, the other question is when is it useful. Yes focus is implemented.

> There are two buttons next to each other, the focus can be switched by tab from one to another

It is not necessary for buttons to take focus, or then i see no reason. I don't think it is necessary to select the widgets in the graphical user interface using keyboard, at least i have not seen anyone who does that. One can implement it of course, it is possible, though i don't see what need could there be for that. What concerns keyboard focus, then currently only an entry box (or an entry box in a combo box) gets the keyboard focus, when it's open. By focus i mean mouse focus though, if not explicitly said keyboard focus.

> There are two widget forms (are there forms at all?), one of which is layered above the other form. By clicking on the form below it will become active and be shown in front of the other form.

There is a confusion of terms, used in one or another widget toolkit. I don't know what exactly one may mean by form. There are windows, and widgets can be on these windows, so that when a window becomes visible, all widgets on it become visible. Such window is called a dialog window i think, at least in some widget toolkits. Do you mean like tabs, when you press on one of the tabs, the corresponding dialog becomes visible? Yes this can be done, for that just the visibility member of the structure of the window below has to be assigned nonzero, and the visibility member of the structure of the window in front has to be assigned zero, it's that simple. The window below then becomes visible, the window in front becomes invisible, and it also will not react to any events.

Have fun and, when you use that toolkit, or a modified version of it, in any of your game or application, then please show us your screenshots Smile
Matthias


Joined: 17 Apr 2016
Posts: 3
Hi actsl,

I really appreciated your detailed answer. Thanks a lot for that! (You may transform it into a PDF and voila, half of your documentation is finished already Wink )

Now that I got a better understanding of the capabilities of your project, I can clearly say, that I plan to do something with it. I promise I'll let you know, if I get something done :-).

Quote:
I don't know what exactly one may mean by form. There are windows, and widgets can be on these windows, so that when a window becomes visible, all widgets on it become visible.

That is what I meant. Kind of a container.

Thanks again and keep up the great work :-)!
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
I hope to be using it later, once my game is in a suitable state...
actsl


Joined: 09 Feb 2016
Posts: 83
I now succeeded to put together some manual, somewhat similar to the SDL_image manual, it also includes a full reference.

The manual is at the following link.

https://raw.githubusercontent.com/actsl/kiss_sdl/master/kiss_manual.pdf

The new release 0.8.8 of kiss_sdl is now in GitHub, the kiss_sdl project page:

https://github.com/actsl/kiss_sdl

Thank you MrTAToad, hope the pegasus horse be with you in creating your game, and want to see it when it is made.[/url]
actsl


Joined: 09 Feb 2016
Posts: 83
Talking about theory. This, creating all widgets at first and then switching the visibility of the widgets, instead of creating and destroying widgets dynamically, may look bad at first, because everyone is used to do it in the latter way. But what is the advantage of that, using less memory? It may even not decrease the use of memory, because all the user written functions for widgets have to be there anyway, a lot has to be there for all widgets. But this is even not the primary problem, as creating widgets dynamically to decrease the use of memory, can also be done with kiss_sdl, the other question is whether it's necessary.

When having thousands of widgets, it's better to allocate all structures of the widgets rather than having them in stack, as the size of the stack is limited. This though does not change really anything and does not much add complexity. It is also not about the widget toolkit at all, but only about the examples, in the examples the widgets were allocated in the stack, only because of simplicity, and for simple interfaces it is also not a problem when it is done in that way. But this is really a different matter and is not about dynamically creating and destroying widgets.

Doing it by switching the visibility is inevitable with a simple design, when all widgets are created first and all functions of these widgets are in the event loop and active. For creating and destroying widgets dynamically, in widget toolkits such as GTK, there is a hidden mechanism, which has a some kind of repository of information about all widgets. A mechanism that makes these widget toolkits more complex, but is rather mostly unnecessary. This mechanism adds only the functions of these widgets to the event loop, that currently exist, thus eliminating the need to have functions of all widgets in the event loop. One can implement such mechanism with kiss_sdl as well, but it would mostly be rather unnecessary.

Also it is difficult to see, when doing it like in GTK or Qt or other such toolkits, how can it be thread-safe. Because this repository of information about all widgets is likely central. With kiss_sdl, it is possible to process and draw different widgets in different threads completely independently, because nothing is central. This may make the graphical user interfaces much faster. There is this problem with all computers today, as their operating systems use widget toolkits that also may have some kind of central information repository for all widgets.
Matthias


Joined: 17 Apr 2016
Posts: 3
You've compiled a nice piece of manual :-)! Well done. I'm missing kind of a simple example though (not a copy of a full example code) on how to handle and work with your lib.

I wondered at another point very much. You are wrapping the SDL initialization by kiss_init() to full extend. This surprised me a little bit, usually you have external libs (e.g. SDL2_Image, SDL2_TTF) being initilized on top of the basic SDL init. part. I would have guessed your lib works the same way. I initilize the subsystems I need myself (not just EVERYTHING as kiss_init does), and I may want to use other flags to set up the window, too. - Why wouldn't you make kiss_init ask for a ready and set up renderer and window instead of doing the initialization yourself without being sure what the user really wants? - Perhaps I'm missing something though. Let me know :-).



Quote:
Talking about theory. This, creating all widgets at first and then switching the visibility of the widgets, instead of creating and destroying widgets dynamically, may look bad at first, because everyone is used to do it in the latter way. But what is the advantage of that, using less memory?


I guess in case of a SDL specifric low-level light-weight gui, it doesn't make much of a difference. For many SDL purposes a gui is just a basic need to have some menues available for the user until he joins the action (the real game/application). This gui isn't perhaps the best choice if you plan to create an operating system, there these considerations may make a difference. Then there would be a very gui intensive application, also in this case, this gui perhaps is not the best choice. Just my two cents. :-)
actsl


Joined: 09 Feb 2016
Posts: 83
Matthias wrote:
Why wouldn't you make kiss_init ask for a ready and set up renderer and window instead of doing the initialization yourself without being sure what the user really wants? - Perhaps I'm missing something though. Let me know :-).

Thanks.

No, you are not missing anything. It is made to be simple, so kiss_init() does everything when the user does not need anything special, a typical case. But when user wants to use different libraries for loading images, loading fonts, etc, then the user should rewrite the kiss_init() function, that is, to make changes there what correspond to ones needs. This is why kiss_init() is in kiss_draw.c and not in kiss_widgets.c, the functions in kiss_draw.c are meant to be overwritten when using different libraries, etc. At that no external library function is directly called from kiss_widgets.c, all what concerns drawing is done by calling functions in kiss_draw.c.

This is how this toolkit was made, it provides what is necessary for a typical case, but is made to be easily changeable, and some parts of it are considered to be rewritten when the user may need something other than typical. One may think how well it is done, but it is the only way to make such widget toolkit, provided that it has to be simple, and at that universal. Should be good for programmers, who like to do the programming, and not choose from an available options in some huge library, and then follow the instructions of how to do that, in the monkey see monkey do style.

Start to play with the examples, change them and see what happens. I don't know what is so difficult in the examples. Calculating the coordinates of the widgets may look a kind of long, but then it's a simple and straight-forward thing to do. At least, calculating the coordinates, widths and heights of the widgets, this is understood right after it's said, but reading about packing of widgets in the manuals of some toolkits, i say one's face turns red before finishing reading it.
actsl


Joined: 09 Feb 2016
Posts: 83
Matthias wrote:
I'm missing kind of a simple example though

I may explain you the second example, if that may anyhow help.

First there is an arrray of structures, initialized with data about the bigger cities in USA.

Next are the user written event function. In the first two functions, the other of the select buttons is toggled, when a select button is toggled by clicking on it. This gives an effect like radio buttons. One can see that the standard function is called in the if condition, and the reaction is when that standard function returns nonzero.

Next there is a user written event function for combo box, it provides a reaction when the combo box closes, the chosen text is then in the combobox->entry.text. This is searched in the combo box array (combobox->textbox.array), and its index is calculated. Then depending on the state of the select1 widget (the member of its structure select1->selected) one of the two text is written to a string, with the data from the cities array, at the previously found index. Next the string is copied to the entry widget (entry->text), limiting it to the width of the entry box by '\0'. Also the scrollbar is set to 0, so that it is at the beginning and doesn't move. And the variable draw is assigned nonzero as always when anything is changes that needs to be drawn.

Next there is a user written scrollbar event function, which is a reaction when the scrollbar's slider moves. First the index of the first character in the string is calculated, by subtracting from the length of the string the number of characters that are visibe, and this number is the maximum number of characters in the entry box, multiplied by the scrollbar's fraction (hscrollbar->fraction). Always 0.5 has to be added when rounding a float expression by casting to int. Then the text starting from that index is copied to the entry box, so that its length is limited by the width.

The user written button function only assigns nonzero to the variable quit, to quit the application.

Everything necessary is defined in the beginning of the main() function, including structures for all widgets. After the other initializations, what is important is initializing the variable size array a. The structure of the array a is defined in the stack, the same as the structures of the widgets. A new array shall be created with that structure, and then the names of the cities from the cities array are appended to that array. Later this array is passed as an argument to the function that creates a combo box.

Next all the widgets are created. The widget structures ara passed to the new functions as first arguments. The window is the dialog window for all the widgets there, thus its second argument is NULL, the second argument for all other widget is a reference to that window. The third argument in severeal widgets is whether to decorate the widgets, which in this example is every time 1.

It is important to assign zero to the hscrollbar.step too, because at first the entry box is empty, and thus the scrollbar should not move.

Next, assigning 1 to the window.visible does that magick trick that makes all the widgets visible at once, because this window is set as a dialog window for all our widgets.

Next there is a main loop while !quit as usual for such applications, the additional code there can be the implementation of the game or whatever. It is good to have a delay, it's better to be 5 ms or more, because 5 ms used to be the time period of the operating system's scheduler, this gives some more time for the operating system and other programs.

Next there is an event loop, that goes through all events that currently happened. In that loop there are the event functions of all the widgets, user written, or the standard function for the widgets which event functions the user did not overwrite. In our case the order of these functions is not really important. The event is passed to the functions as an argument.

Next the combo box and scrollbar event functions are called again outside the event loop, with the event argument NULL. It is explained why it is done in the manual, in brief, this is necessary for all widgets that have a certain continuous movement.

Next there is a drawing part, which is done only when the variable draw is nonzero, and in the end of it zero is assigned again to that variable. It begins with clearing the renderer, and ends with presenting everything drawn on the screen. Next there are draw functions of the widgets, which can be overwritten by the user as well, the same way as the event functions. The standard draw functions return nonzero when anything needs to be drawn. But in our case no additional drawing were done. The only thing important in our case what concerns the order of the drawing functions, is that the combo box has to be after the scrollbar and the entry box, as it partly covers them when it's open.

Finally all the objects allocated are freed by the kiss_clean(). The array objects is passed to that function. It is the same array that were passed to kiss_init(), where all the allocated objects were added to that array, and as you noticed, we also added the array a for the combo box, to that array. Adding allocated objects to the array in that way, enables to free them all at once, with one function.

Hope it was useful for anyone. For these things one should know C well, like pointers and things. No other knowledge is really necessary.
actsl


Joined: 09 Feb 2016
Posts: 83
Matthias wrote:
I'm missing kind of a simple example though (not a copy of a full example code) on how to handle and work with your lib.

I will not explain here all the details of the widget toolkit, except when asked. But ok, there should be some hello world for everything. The code below creates a kind of simple message box, with only a label and a button.

To compile this, just create a new directory, copy all files from the kiss_sdl distribution to there, create a file hello.c , and write the following code in it. Then say in linux, copy kiss_makefile to makefile, and there simply replace kiss_example1 everywhere with hello. Then open terminal in that directory, write make, and then ./hello to run it.

Code:
#include "kiss_sdl.h"

void button_event(kiss_button *button, SDL_Event *e, int *draw,
   int *quit)
{
   if (kiss_button_event(button, e, draw)) *quit = 1;
}

int main(int argc, char **argv)
{
   SDL_Renderer *renderer;
   SDL_Event e;
   kiss_array objects;
   kiss_window window;
   kiss_label label;
   kiss_button button;
   char message[KISS_MAX_LENGTH];
   int draw, quit;

   quit = 0;
   draw = 1;
   kiss_array_new(&objects);
   renderer = kiss_init("Hello kiss_sdl", &objects, 320, 120);
   kiss_window_new(&window, NULL, 0, 0, 0, kiss_screen_width,
      kiss_screen_height);
   strcpy(message, "Hello World!");
   kiss_label_new(&label, &window, message, window.rect.w / 2 -
      strlen(message) * kiss_text_advance / 2, window.rect.h / 2 -
      (kiss_text_fontheight + 2 * kiss_button_height) / 2);
   label.textcolor.r = 255;
   kiss_button_new(&button, &window, "OK",
      window.rect.w / 2 - kiss_button_width / 2,
      label.rect.y + kiss_text_fontheight + kiss_button_height);
   window.visible = 1;
   while (!quit) {
      SDL_Delay(10);
      while (SDL_PollEvent(&e)) {
         if (e.type == SDL_QUIT) quit = 1;
         kiss_window_event(&window, &e, &draw);
         button_event(&button, &e, &draw, &quit);
      }
      if (!draw) continue;
      SDL_RenderClear(renderer);
      kiss_window_draw(&window, renderer);
      kiss_label_draw(&label, renderer);
      kiss_button_draw(&button, renderer);
      SDL_RenderPresent(renderer);
      draw = 0;
   }
   kiss_clean(&objects);
   return 0;
}


All that needs to be included, is kiss_sdl.h .

First, the standard event function for button is overwritten by the user, with the function button_event(). The reason for overwriting that function, is to make the program to quit, when pressing the OK button. For overwriting the event function, the standard event function is called in the if condition with the same arguments as the overwritten function, except quit, and the if statement body is *quit = 1 , which ends the main loop. Notice the pointers, a variable, when the function may change it, is passed as a pointer. draw and quit are local variables defined in main(), which means that they are passed to the event functions with a reference operator, as &draw and &quit.

The main() function header has to be int main(int argc, char **argv) , i don't even remember why it cannot be int main(void) , but this is how it works.

Then all the necessary variables are defined, there is not much to explain, this is what needs to be defined. As you see, we also define three widgets, window, label and button.

We initialize quit and draw, by assigning 1 to quit and 1 to draw. Assigning 1 to draw makes sure that everything is drawn at the beginning. Next we create the array object, which is necessary to store references to allocated objects, but we don't have to do anything else with it, than just to pass it to kiss_init() and kiss_clean().

kiss_init() creates the SDL main window, and returns the renderer. There is not much about it, the window's width and height have to be passed to it as its last arguments. Next we create the window widget, this would be like a dialog window on which are all our widgets. We pass the window widget structire to it, then NULL, because it is the bottom window, and is not on any other window. The next argument is decorate, it's 1 in the kiss_sdl examples, but this time we pass 0 to it, to show that the widgets borders can not be decorated. The last 4 arguments are x, y, width and height of the widget. Because we cover all the surface of the SDL window with it, these are 0, 0, and the kiss_sdl variables kiss_screen_width and kiss_screen_height, which are the width and height of the SDL window.

Next we copy the text of the message to the char array message, and create a label with window as its dialog window, and the message.

The low level widget toolkit differs from the advanced widget toolkits such as GTK, in that all the coordinates, widths and heights of the widgets, have to be calculated manually. Also all the coordinates are SDL window coordinates, so when the coordinates have to be relative to the dialog window, the dialog window coordinates have to be added to the widget's coordinates, which is not difficult to do though.

Our dialog window's width is window.rect.w , the width of our label is strlen(message) * kiss_text_advance . kiss_text_advance is the horizontal distance from the beginning of a character, to the beginning of the next character, in pixels. All coordinates, widths and heights are in pixels. Now to center the widget in the dialog window, its x coordinate has to be window x + window width / 2 - widget width / 2, because it has to be half the widget width less than half the window width. In our case the window x is 0, so the x coordinate of the label is window.rect.w / 2 - strlen(message) * kiss_text_advance / 2.

We want that the label with the button below it, were also verically at the center of the window. We would have one button height between the label and the button, this is a good distance between them. In that case the total height of all our widgets is kiss_text_fontheight + 2 * kiss_button_height . The kiss_text_fontheight is the height of the text font, this should not be confused with the kiss_text_lineheight, which is the vertical distance from the beginning of a line, to the beginning of the next line, which is not the same as kiss_text_fontheight. Thus the y coordinate of the label is window.rect.h / 2 - (kiss_text_fontheight + 2 * kiss_button_height) / 2 , and everything is perfectly centered.

We make it a bit nicer, and make the message red. label.textcolor.r is the value of the red component of the label's text color. As it by default is black, then assigning 255 to it, makes the text red. This is how the features of a widget can be changed later after creating it, by changing the values of its structure.

Next we create a button, with the dialog window window, and the text "OK" on it. The x coordinate of the button is calculated in the same way as the x coordinate of the label, as it has to be horizontally centered, thus it is window.rect.w / 2 - kiss_button_width / 2 . We calculate the y coordinate of the button relative to the y coordinate of the label, thus it is label.rect.y + kiss_text_fontheight + kiss_button_height .

Next we do that magical thing, window.visible = 1 . This makes visible that window, and all the widgets on it.

Next there is the typical main loop, while quit is zero. It starts with SDL_Delay(10) , which gives 10 milliseconds time in every iteration, for the operating system and other programs. Next is the event loop.

Every iteration of the event loop gives a different event e, if there are any events. First we check whether the event is SDL_QUIT, which means that the user closed the window, by clicking on the x at the upper left corner of the window, using a keyboard shortcut or by other ways of closing it. In that case we assign nonzero to quit, to end the main loop, and quit the program.

Next we call the event functions of the window and the button. We should formally call the window event function, just to process the exposed event, to find when the window and everything on it has to be redrawn. Though it works without it, as calling the button's event function does the same. Notice that we called the standard window event function, but the overwritten button event function, which also has the argument quit.

This is how it is done in a low level widget toolkit, things have to be done manually, like the event functions have to be added to the event loop manually. Which is not difficult though, and at that the widget toolkit is much simpler, and there is much less to learn. But no glorious one function to do all the main loop, and event loop, nothing like that. And when there is that glorious function, then any thinking person certainly asks, how can one do other things while the widgets are active, or how to add some event processing. And this would not be that simple any more. Abstraction is for hiding details for making certain tasks simpler, but abstraction that always hides everything, is not good.

Next in the main loop is the drawing, which we do only when draw is nonzero. Draw is assigned 0 again in the end of the drawing, so that something somewhere has to assign nonzero to it again, to draw again. The drawing is a complete redraw of the SDL window, drawing a single frame, so to say. It starts with clearing the renderer, and ends with presenting the renderer, the standard SDL functions. The standard draw functions of all the three widgets are called in between these, there is not more to it.

After the end of the main loop, kiss_clean() is called, with the reference to the array objects passed to it, this frees all the allocated objects, and quits SDL and all its subsystems. Finally, return 0 has to be there by standard.

The widgets don't do many automagical things in this simple dialog, only the button becomes lighter when the mouse is on it, and darker when clicked. I simply took a pattern of wood, and cut a proper size piece out of it, for a button. Then i made 3 images out of it, first is with the normal brightness, second is with the brightness increased, and third is with the brightness decreased. But these can be any images, like one may make them 3D, having 3D buttons.

I hope that this gave everyone an idea of how a low level widget toolkit differs from advanced widget toolkits, such as GTK.



The new version 0.8.12 of kiss_sdl is now in GitHub at the following link. You may notice that the version number increased, but i didn't really change anything, only added the manual.

https://github.com/actsl/kiss_sdl
actsl


Joined: 09 Feb 2016
Posts: 83
Version 0.10.0 released https://github.com/actsl/kiss_sdl

UTF-8 support, structures for resources, a compiler macro for path to resources. If you knew me, i'm very reluctant to change it.
actsl


Joined: 09 Feb 2016
Posts: 83
Two things i have to explain, after i just talked with someone in the #sdl channel.

1. It is intentionally unfinished.

2. The GUI does not look pretty by opinion of some, this is first because of the reason 1., the graphics is only primitive. But why was it drafted like this, it was on the principle that computer is an equivalent of a pen and paper. Not a machine or a control panel of a machine, like these who designed the Windows GUI likely thought. But pen and paper. We write on a white paper, with a pen of one color. Like we could write on a paper with flowers printed on it, but we don't. Pen and paper are intentionally made simple, that nothing would distract us, when we read, what we wrote.

3. It is not really skinnable, except that it is easy of course to change all images and fonts, and changing colors should also be simple. But it is rather made easy to change, so that you take it, and make out of it what you want to do.

And happy spring to everyone!
actsl


Joined: 09 Feb 2016
Posts: 83
Version 0.10.2 is now in GitHub with some bug fixes https://github.com/actsl/kiss_sdl .
kiss_sdl - Simple universal GUI widget toolkit for SDL
markand


Joined: 11 Jun 2012
Posts: 31
Le 09/05/2016 07:01, actsl a ťcrit :
Quote:
Version 0.10.0 released https://github.com/actsl/kiss_sdl

UTF-8 support, structures for resources, a compiler macro for path to
resources. If you knew me, i'm very reluctant to change it.


Some things that I would like to understand:

* The library is completely based on SDL, why don't use the same naming
convention ? Example Kiss_WindowDraw instead of kiss_window_draw,
* It would be nice to have a real build system (like CMake).

Regarding the look and feel, well... I think it needs some
reconsideration :-).

Kind regards,

--
David Demelier

_______________________________________________
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
markand wrote:

> The library is completely based on SDL, why don't use the same naming
convention ? Example Kiss_WindowDraw instead of kiss_window_draw

Because i don't like the CaMel naming convention, and i think that it makes names difficult to read. If it would be more integrated to SDL2, i may change the naming convention.

> It would be nice to have a real build system (like CMake).

I in general don't like anything that needs and creates many rubbish files. Also i don't like CMake that much, why not to have a simpler automake, with just some macros in the makefile, for appropriate paths, like a simple macro preprocessor. In that way, only makefile would be necessary, just like in the usual compiling with makefile only. But with that one may write in the makefile some general names of the libraries, etc, so makefile doesn't have to be edited when installing new versions of the libraries or such. But as long as CMake is almost the only way to do that, at least what concerns Windows, then of course when one wants to use an automake, then CMake is often the only option

There was an issue created in the kiss_sdl project https://github.com/actsl/kiss_sdl/issues/1 , which was quickly solved and closed. It was caused by a mistake of the user, that he did not add a definition, to CMakeLists.txt , like add_definitions(-DRESDIR=\"../../src/\") , that adds a macro definition to the compiler's command line, that provides a relative path from the executable, to the resources (fonts and images, the path can also be absolute). He tried to compile the examples of my widget toolkit, in Macintosh. It built well, but running it resulted in a segmentation fault. It appeared that the only reason was that he put the executable into a different directory, but did not add the path to resources, as explained above, and the executable didn't know where to load the resources. After he did that, it worked well.

So if you want an example of how to build this widget toolkit with CMake, then in the discussion of that issue there is provided the initial test project https://github.com/actsl/kiss_sdl/files/265266/Test_KISS.zip that only needs adding a definition for path of the resources in CMakeLists.txt , as said above, and it works. I also provided a test project there, but it was a simplistic case with the executable in the same directory as the source, just to test whether the issue was only in the missing path to resources, and it appeared to be.

> Regarding the look and feel, well... I think it needs some
reconsideration

I wrote about the general considerations of the look and feel, before in this thread. But one should consider that i did not try to make it into any finalized product, with a polished look and feel. This also would restrict one to use only a certain look and feel, which i think at least what concerns games, is not a good thing to do at all. And a possible looks and feels used in games, and why not also in applications, are very different. Therefore i provided only a simple initial, very generic look and feel, that can be changed into the look and feel that the user desires.

It is simple to change the look and feel. The easiest way is to replace the images for the elements of the widgets, there are only a few of them, and the fonts. It is also easy to change the colors of the widgets and also draw additional things on the widgets, like a graphical background, by overwriting the base drawing functions, the code of the widget toolkit doesn't have to be changed at all for that. The code of the widget toolkit is made though easily changeable too, with everything abstracted away, so using different font libraries, image libraries, or even a different graphics library, may not be difficult at all.

Someone made a fork of it too, it looks like that he is going to use it as a widget toolkit on some 3D surface.

Now i think that i made all the changes necessary, and the code of the widget toolkit will not change any more. The version 0.10.4 of kiss_sdl is now in GitHub https://github.com/actsl/kiss_sdl .

I hope you have fun using it.
actsl


Joined: 09 Feb 2016
Posts: 83
The version 0.10.6 of kiss_sdl is now in GitHub with added support for building C++ projects https://github.com/actsl/kiss_sdl .
actsl


Joined: 09 Feb 2016
Posts: 83
The new version 0.10.8 of kiss_sdl is now in GitHub, with improved using with C++ https://github.com/actsl/kiss_sdl .
actsl


Joined: 09 Feb 2016
Posts: 83
If you want to build it with CMake, this is an example CMake project for it that i made https://github.com/actsl/kiss_sdl/files/283114/cmakekiss.zip , works for me in Linux. Others say that for making it to work in Macintosh, the 6. line in the CMakeLists.txt should be changed to the following.

Code:
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
   "${Test_KISS_SOURCE_DIR}/cmake")

As of now, i'm not willing to change it to using CMake, as i want that the users can reliably build and compile it. With makefile, it now evidently builds and works faultlessly in Linux, Windows MinGW, Visual Studio and Macintosh, with both 64 bit and 32 bit operating systems. No one has knowingly tested it yet with Android or iOS, but it should work with these as well, that is, with almost anything that has a screen.

If you want to make it to dynamic library, change what needs to be changed in kiss_makefile , similar to that below. I wrote it in the way i know it should be done, i have tested that, but not with that makefile. You may only need a dynamic library, if you want to use kiss_sdl in a commercial product, and want that the library license will not extend to the product.

Code:
LDFLAGS = -lSDL2 -lSDL2_image -lSDL2_ttf -L. -lkiss_sdl
LIB = libkiss_sdl.so
all: $(LIB) $(EXE1) $(EXE2)
$(EXE1): kiss_example1.o
   $(C) $^ $(LDFLAGS) -o $@
$(EXE2): kiss_example2.o
   $(C) $^ $(LDFLAGS) -o $@
$(LIB): kiss_widgets.o kiss_draw.o kiss_general.o kiss_posix.o
   $(C) -shared $^ $(LDFLAGS) -o $@

There are no issues, it is now beta tested by users, and it looks like that there is now no more need for any new releases or commits. So i think that it can now, as of the version 0.10.8 , declared to be stable. I'm now waiting for screenshots from MrTAToad and others who said to try it, of using it in a game or application. This also may give an idea of how different the look can be, as i avoided to add to it any graphics gibberish, or anything else that is easy to make, so that it is not bloated.
actsl


Joined: 09 Feb 2016
Posts: 83
I post this to announce that kiss_sdl now has become stable, there is the stable release 1.0.4 in GitHub now https://github.com/actsl/kiss_sdl .

I tested building a dynamic library, and it appears that it has to be like this below. The second lines in targets have to start with tabs, but posting code here replaces tabs with spaces. So write there tabs.

Code:
LDFLAGS = -lSDL2 -lSDL2_image -lSDL2_ttf -L. -lkiss_sdl
CFLAGS = -Wall -c -std=c89 -fPIC
LIB = libkiss_sdl.so
all: $(LIB) $(EXE1) $(EXE2)
$(EXE1): kiss_example1.o
   $(C) $^ $(LDFLAGS) -o $@
$(EXE2): kiss_example2.o
   $(C) $^ $(LDFLAGS) -o $@
$(LIB): kiss_widgets.o kiss_draw.o kiss_general.o kiss_posix.o
   $(C) -shared $^ -o $@

I don't want to make any new commits or new releases in GitHub, and i hope that there will not be any, so that the users can rely on it remaining what it is. Some users are active though, and propose changes, some of which enable to diversify the GUI, without adding any complexity at all. I'm all against unnecessary restrictions, but as it is KISS, then the most important is to keep it small and simple, as well as easily changeable.

I also added options to build in Macintosh in kiss_makefile. The only way how it now builds in Mac, is with CMake, and i found the locations where the SDL2 libraries are installed in Mac, from the CMake files from Mac. I have no Mac, so if someone has Mac, i would be thankful if one would test whether it builds with these options with makefile in Mac, or what possibly should be changed so that it will.
actsl


Joined: 09 Feb 2016
Posts: 83
Makefile now works in Macintosh, in the new version 1.0.6 https://github.com/actsl/kiss_sdl .
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Busy implementing it in my game now (seriously upgrading my Assembloids game).

Have made a few changes, mainly because I will be eventually needing it converted back to SDL1 at some point in the future (due to using a system that only has SDL1).

Namely :

Returning constants instead of return 0;/return -1; for success/error
Removed SDL initialisation in kiss_init and SDL shutdown in kiss_clean (as my SDK will be initialised first). Although it wouldn't make any difference, the code would just be taking up memory for no good reason.
Pass the SDL renderer to KISS and remove the parameters in functions, so using a private variable for SDL_Renderer
If a value of <=0 is passed for the screen width/height when initialising and/or window creation, then it will use the current screen size.
Add function to enable/disable window viability, rather than accessing structure variables directly.
actsl


Joined: 09 Feb 2016
Posts: 83
MrTAToad wrote:

> Removed SDL initialisation in kiss_init and SDL shutdown in kiss_clean (as my SDK will be initialised first).

Right, these should often be separate. I though want the default code to be as simple to use for beginners, as possible, so i don't want to separate them in the default version. I'm always in between keeping it easy to use for beginners, and making it more flexible for advanced users. The latter can be done by easy means, like it is easy to change it so that different resources (fonts and images) can be used in different widgets, but i always choose the former, as making starting to use it easy for beginners is so vital.

That one would change it, this is what it is thought to be, one can use it as is in the simple cases, and then change it in accordance with one's needs. A thing like that cannot be made simple otherwise.

> Although it wouldn't make any difference, the code would just be taking up memory for no good reason.

My system monitor didn't show any significant increase of memory use when running the examples.

Valgrind tough showed a significant memory leak at exit, which was caused by a wrong order of destroying the resources. This is now fixed in the new release, version 1.0.8 https://github.com/actsl/kiss_sdl .

Valgrind however, when testing kiss_example1, writes that at the end:

Code:
LEAK SUMMARY:
    definitely lost: 21,003 bytes in 474 blocks
    indirectly lost: 0 bytes in 0 blocks
      possibly lost: 0 bytes in 0 blocks
    still reachable: 89,416 bytes in 551 blocks
         suppressed: 0 bytes in 0 blocks

At that, all was traced to SDL_Init(), SDL_CreateWindow(), SDL_CreateRenderer() and SDL_RenderClear(). To SDL_RenderClear() though only one time, and it's always 63 bytes, no matter for how much to use the program, that is, no matter how many times to select things and do whatever in the user interface, it's always only 63 bytes during the entire run of the program. I don't know by now what is it caused by.

> Pass the SDL renderer to KISS and remove the parameters in functions, so using a private variable for SDL_Renderer

Not a bad idea but, makes the _new function calls too long, and they are long already.

> Add function to enable/disable window viability, rather than accessing structure variables directly.

To enable/disable window visibility? Not a bad idea but, i avoid everything that makes it anyhow more bloated.

Please post your screenshots when your game somewhat starts to run, it's very important for people to get an idea of it, to see it used in a game or application. Your game does not have to work completely yet when posting these. And many thanks for the work you do. And to all others who are using it now, i know some who do. They all may realize the importance of the work all we do, for creating a simple alternative of GUI.

Fixed a memory leak at exit after testing with valgrind, in the new version 1.0.8 https://github.com/actsl/kiss_sdl .
actsl


Joined: 09 Feb 2016
Posts: 83
Could you think what can happen Wink This was not the right way to fix it. The resources have to be freed in the opposite order than they are allocated.

Freeing resources in the opposite order than they are allocated, in the new version 1.0.10 https://github.com/actsl/kiss_sdl .
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Each text box, button etc could do with its own font.

In addition, text entry needs to deal with keyboard repeating - at the moment press a key and it thinks the key is being held down for a second or so.
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
image_new also needs a check to make sure a graphic is actually loaded...[/code]
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Do wish we could edit posts Smile

The same check is needed for font loading too...
actsl


Joined: 09 Feb 2016
Posts: 83
I see you want to extend it, then do. But i'm not willing to have different images and fonts in different widgets in the default version, for the reasons i said in my previous posts. Except one can load ones own fonts and manually change the fonts of the label widgets to whatever fonts one wants. Which at all doesn't mean that for some purposes extending it is not necessary or needed, no doubt it is. kiss_sdl is a kind of barebones, but it is barebones which can be used as such, and a complete GUI can be made with it as such. When something is barebones, then naturally one wants to add flesh to it, which is not difficult to do. One should understand my unwillingness to change it anyhow, but it may be difficult to see, as i changed it all the time.

It is that, talking about how to write a code for certain purposes, is easier to do. But it is more difficult for me, as it is not about coding only, but about all the principles of a general low level widget toolkit. What it should be and what it should not be, that is. And there are no easy solutions, what in coding are usually no-brainers. I'm a programmer, but more than that i'm an innovator, i have a working experience in innovation, and innovation in software. And innovation has its ways of doing things.
actsl


Joined: 09 Feb 2016
Posts: 83
Ah, it is indeed bad that one cannot edit the post here, though i also fully understand their mailing list needs.

You said keys don't repeat? The operating system does repeating the keys. In what platform do you use it? Repeating the keys works well for me in Linux and Windows (Windows 7), i have not tested it by myself in Macintosh, but people did, and if there were so big problem as that, i think they did certainly say it. Maybe it's about the settings of your operating system, normally keys should repeat.
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Oh yes, keys repeat - unfortunately every key press repeats...
actsl


Joined: 09 Feb 2016
Posts: 83
MrTAToad wrote:
Oh yes, keys repeat - unfortunately every key press repeats...

Every time there is SDL_TEXTINPUT event, it receives event->text.text, which is the string of chars for one character. That is, it is always a string with length 1, if one uses only ascii characters, more if there is a unicode character.

If you receive a character twice, this means that there had to be two SDL_TEXTINPUT events for the same key press. I don't know how this can happen. I have never seen that in any platforms. Then it should be something about the SDL or the operating system. There is nothing about setting it in the code of kiss_sdl, than SDL_StartTextInput(), once in kiss_init(). Fixing it in the rest of the code may not be possible, unless when one knows that every key press always causes two events.

Find out with some test code, whether your key presses always cause two SDL_TEXTINPUT events, and when this is the case, then this is a general problem, and should be talked somewhere separately, of how to fix it.

I don't know of course what else may be wrong. It looks like adding an event function of an entry widget twice to the event loop or something. Anyway, by that what you say, i cannot reproduce it.
actsl


Joined: 09 Feb 2016
Posts: 83
But you are of course right that it should not go ahead when an image or a font cannot be loaded, this is my bad attention. It is fixed now, it prints a message to stderr when a resource cannot be loaded, frees the resources, and kiss_init() returns NULL.

So one more release :p

kiss_init() now returns NULL at error, in the new version 1.0.12 https://github.com/actsl/kiss_sdl .
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
It is also possible to position widgets on/outside the decoration area. I think a valid area needs to be calculated for display of widgets (x+borderSize+1,y+borderSize+1,w-borderSize-1,h-borderSize-1) - or preferably when the window displayed first - and this is then used to offset widget positions and detection.

Could also instead use it for a clipping area, although I dont prefer that as it could have a speed problem
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Actually that wont work due to combo boxes Smile
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
I'm actually seeing if it will - I need it really to be able to centre text
actsl


Joined: 09 Feb 2016
Posts: 83
What problem is centering text? You add to the origin x of an area, half the width of that area, minus half the width of your text. Or i didn't understand the problem you have.
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
The problem is that currently widgets are based on the screen position rather than the position of the window.

At the moment (although I have only tested one widget at the moment), it seems to be working - a widget's X & Y position also takes into account a windows X & Y position plus the windows decoration size, so that all widgets are inside a window and just cant appear everywhere.

It should work with lists fine as the text will e positioned inside a new window with up/down arrows based on the position of the initial wndow.
actsl


Joined: 09 Feb 2016
Posts: 83
Yes these are simple calculations, all is much simpler when all coordinates are screen coordinates, that is SDL window coordinates. There are calculations, but these calculations are easy to understand, self-evident and need almost no explanation. Different from like, widget packing in GTK.
actsl


Joined: 09 Feb 2016
Posts: 83
With widget toolkits there is always that question, did i used the right one, or did i had to use another one. With kiss_sdl there might not be such question, as kiss_sdl is a generic, rudimentary way of creating graphical user interfaces in SDL. So it is almost like making it only in SDL, or if you made it only in SDL, and in a simple enough way, then it likely may not much differ. This is just to say again why kiss_sdl is not yet another widget toolkit. Or it is, but only what concerns the basic way of doing things, which is the same in almost all widget toolkits, but is mostly hidden.
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
One thing that is a problem (but more to do with SDL2 events), is that holding down the mouse button for up/down/left/right slider buttons will only generate one event, so you have to keep tapping the buttons...
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
What is needed (later) is to record button status in the polling event and then KISS uses that.
actsl


Joined: 09 Feb 2016
Posts: 83
MrTAToad wrote:
One thing that is a problem (but more to do with SDL2 events), is that holding down the mouse button for up/down/left/right slider buttons will only generate one event, so you have to keep tapping the buttons...

The event function of a scrollbar, progress bar and combo box has to be in the event loop and also in the main loop after the event loop with the event argument NULL. This generates pseudo "time events". Because mouse clicking is not repeated by the operating system like a key press, so some "time events" are necessary for repeated clicking.

When doing it so, adding the scrollbar event function in two places, isn't the clicking on the arrows repeated then? I have never seen that happening, so when you did not forget to add the scrollbar event function second time with the event argument NULL, and the clicking is still not repeated, then you should write a bug report, writing the platform where you use it, and everything else that makes it possible to reproduce the bug.

It is the function kiss_getticks() in kiss_draw.c which provides the number of milliseconds since the initialization, that is used to generate the repeated "click events". This function by default just calls the function SDL_GetTicks(). So when it really doesn't work, then likely SDL_GetTicks() doesn't work for some reason.

Why is it done in that way? First it is simple, and difficult to fail, as it only relies on getting the milliseconds, by default with SDL_GetTicks(). But second, calling an event function with the event argument NULL, is the general way of doing things. Like, one can generate some continuous animation of ones widgets, and activate it by calling the event function of that widget also with the event argument NULL. Thus generating effects which one cannot even easily dream about when using widget toolkits like GTK or Qt.
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Yes, I didn't have the routine in the two places.

The text part was somewhat similar - I suspect it was effectively polling twice.
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
I've modified the system a fair bit now (https://drive.google.com/file/d/0Bzff3iRdz9Jqd0F3RmJ0Vy1DSUE/view?usp=sharing) to get rid of the global variables and to add various extra things I will be needing for my game (which I should now be able to continue with).

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.
actsl


Joined: 09 Feb 2016
Posts: 83
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.
actsl


Joined: 09 Feb 2016
Posts: 83
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 universal GUI widget toolkit for SDL
MrOzBarry


Joined: 26 Jun 2010
Posts: 620
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

actsl


Joined: 09 Feb 2016
Posts: 83
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.
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
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
actsl


Joined: 09 Feb 2016
Posts: 83
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);
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
Whoopsy - my fault. I was using a kiss_font structure that was defined, but not actually used, so the font advance was always 0...
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
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.
actsl


Joined: 09 Feb 2016
Posts: 83
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
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
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
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
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
actsl


Joined: 09 Feb 2016
Posts: 83
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?

MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
I hope it's interest!
kiss_sdl - Simple universal GUI widget toolkit for SDL
Ben Henning
Guest

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
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 SDL
Ben Henning
Guest

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

actsl


Joined: 09 Feb 2016
Posts: 83
Two of the most active users saw it as the biggest problem that different widgets cannot have different fonts and images, thus i had to make that change. I'm convinced that the core should not be anyhow restrictive, anything that forms a core in any code. I hope it will be the last change, but it was inevitable. It was only a small change and it is also backward compatible. It was implemented by using magic numbers, that enable to check whether a resource (image or font) is assigned. Additional resources can now be loaded after the init function, and their structures can be assigned to the widget structures before creating (initializing) the widgets with the ..._new() functions. This enables a new creative dimension, like a slider can now be easily made out of scrollbar just by loading different images for arrows and vslider or hslider.

Different widgets can now have different fonts and images, in the new version 1.2.0 https://github.com/actsl/kiss_sdl .
actsl


Joined: 09 Feb 2016
Posts: 83
Fixed release 1.2.0, adding kiss_combo.png, in the new version 1.2.2 https://github.com/actsl/kiss_sdl .
actsl


Joined: 09 Feb 2016
Posts: 83
A user posted a pull request for high DPI displays, but i cannot test it, as i have no high DPI monitor.
MrTAToad


Joined: 13 Feb 2014
Posts: 205
Location: Chichester, England
A quick video of my game using KISS. Its a bit old now,as I'm using it more in the main game : https://www.youtube.com/watch?v=ZkNVwCtkN7M
Re: kiss_sdl - Simple universal GUI widget toolkit for SDL
actsl


Joined: 09 Feb 2016
Posts: 83
markand wrote:
Regarding the look and feel, well... I think it needs some
reconsideration :-).

You may not believe how easy it is to change the look and feel. I tried to keep the default version simple, so it were easy for beginners to use, change, and play with it. Thus by default there is only a rudimentary graphics. But if you need something more advanced, you may fork it in GitHub and make a more advanced version of it. Very possible to do, and i'm sure there would be people who want to use it.

kiss_sdl now appears first when searching GitHub for C widget toolkit https://github.com/search?l=C&q=widget+toolkit&type=Repositories&utf8=%E2%9C%93 . Before tcl/tk surprisingly, which is an old and most widely used widget toolkit. I still think it's the best, though much more complex than mine and it is not for C, but tcl, the whole tcl interpreted language has to be embedded for using it. But i think it's an alternative for these who want a more advanced widget toolkit. imgui is more popular, it is historic, the first immediate GUI, who will not give the credit, though it is a lot more complex than mine and not really very easy to use.

And thanks a lot to MrTAToad for nice video.
actsl


Joined: 09 Feb 2016
Posts: 83
There is one feedback that i may need, do the border and edge also have to be different for different widgets or is it OK that they are the same for all widgets, and everything remains as it is? By now i don't change anything.

I found it looks like that tcl/tk is hosted in SourceForge, so this is likely some mirror of it there, but it was the first there.
actsl


Joined: 09 Feb 2016
Posts: 83
There was an issue posted in GitHub https://github.com/actsl/kiss_sdl/issues/11 about building kiss_sdl for Android. First it was written there
Quote:
Good and simple little GUI kit!
I'm guessing it's not compatible with mobile?
Anyone got it working?
and then
Quote:
Disregard works fine!
Android didn't handle the fprintf stderr.
It was a missing texture.
Thanks for the GUI, it's pretty cool!

So i wrote this to let you know that it can be built for Android. I have the Android Studio installed and have an Android emulator, so i can test any builds for Android.
actsl


Joined: 09 Feb 2016
Posts: 83
A bit about theory. Some may think writing code is just about implementation, but there has to be theory, otherwise it becomes clumsy, unnecessarily too complex, inflexible, inefficient and often unreliable.

The GUI toolkits are mostly complex, and it is a problem how to make them simpler. Immediate GUI, using the widget functions as if conditions in the event processing loop, makes it simpler, and more easily changeable. And this is implemented in kiss_sdl, but implementing all the possible functionality for widgets still makes widget toolkits complex. This is because what software is, different from things like electronics for example, it has to be very flexible, thus the number of possibilities that may have to be implemented, is great. Electronics has to be flexible too, but the difference is in degree.

Thus what the solution should be to still make it simple. Implementing all possible functionality is evidently not an option. Also implementing all possible functionality often makes it more difficult to use a library or toolkit, because of its complexity, and because it is mostly impossible to foresee all possible functionality, with that solution adding a new functionality requires overcoming all the complexity there. Just providing examples is another extreme, but not good either, because examples are often too particular, and it is mostly impossible to write one example that is generic enough. So there has to be something in between. I didn't find a term for that, so i had to coin a term. I call it principal code.

Principal code is implementing the core functionality and most important functionality, so that it can be changed to implement any specific functionality, and doing that is easy. When there is a principal code, then the developers don't have to start from nothing every time, and write the same basic things again and again. Yet it often implements the most that is necessary, and only with a few small changes it is possible to make what one needs. Also most of the simple things can be written using a principal code only, without any changes. This is the way to provide flexibility and generality, while still maintaining simplicity.

Principal code is a general term for any kind of code. What concerns GUI, then it's called principal GUI. Because GUI used to be the most complex of the libraries, then the first to implement that principle is GUI.
actsl


Joined: 09 Feb 2016
Posts: 83
I saw that one thought about using kiss_sdl in the game Hope http://hope.glusoft.com and then said:

Quote:
kiss_sdl : Very lightweight library where the rendering is performed by SDL and SDL_image. So I need to modify the library to use SDL_gpu, quite a bit of work. Developed by one person, so it could be buggy.
...
After all these research I decided to simply do a small command line tool myself something very small, where I can warp, get an object and change a variable.

All that said without even once trying it. The last change was made more than 6 months ago now, and no one has found any bugs since then. And by GitHub statistics i estimate that it has been downloaded at least 10 times in a day.