Kiss_sdl - Simple universal GUI widget toolkit for SDL


#1

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.


Rose - Cross-Platform C++ SDK that based on SDL(Version 1.0.10-20170727)
#2

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.

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


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


#3

Does it also have radio buttons and selection buttons too ?


#4

Ah yes, the selection (or rather checkbox) is there…


#5

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 :

image1

image2

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


#6

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 :

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.------------------------
kiss_sdl - Simple universal GUI widget toolkit for SDL2 https://github.com/actsl/kiss_sdl


#7

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


#8

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


#9

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.


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


#10

yes, its a very useful system.


#11

There is not much more to do with it really, aside from making sure that it can be used on systems without keyboards :smiley:

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


#12

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 :smiley:

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.


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


#13

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.


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


#14

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 :-)!


#15

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 :slight_smile:


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


#16

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 :-).

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 :-)!


#17

I hope to be using it later, once my game is in a suitable state…


#18

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.

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

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


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


#19

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.


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


#20

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.


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