Kiss_sdl - Simple universal GUI widget toolkit for SDL


A very early picture of the theme selection window for my Assembloids game :


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


MrTAToad wrote:

A very early picture of the theme selection window for my Assembloids game :

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

kiss_sdl - Simple universal GUI widget toolkit for SDL2


Yes, really must stop using the IMG tag :slight_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


An updated graphic :

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


MrTAToad wrote:

Yes, really must stop using the IMG tag :slight_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 or to other image upload sites. I don’t know the privacy and copyright things there though. But as it is an early picture, then i provided it here just as an example.

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

kiss_sdl - Simple universal GUI widget toolkit for SDL2


I hope it’s interest!


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:

I hope it’s interest!

SDL mailing list
SDL at


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


Thanks for your clarification.


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 .

kiss_sdl - Simple generic GUI widget toolkit for SDL2


Fixed release 1.2.0, adding kiss_combo.png, in the new version 1.2.2 .

kiss_sdl - Simple generic GUI widget toolkit for SDL2


A user posted a pull request for high DPI displays, but i cannot test it, as i have no high DPI monitor.

kiss_sdl - Simple generic GUI widget toolkit for SDL2


A quick video of my game using KISS. Its a bit old now,as I’m using it more in the main game :


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

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.

kiss_sdl - Simple generic GUI widget toolkit for SDL2


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.

kiss_sdl - Simple generic GUI widget toolkit for SDL2


There was an issue posted in GitHub

about building kiss_sdl for Android. First it was written there

Good and simple little GUI kit!
I’m guessing it’s not compatible with mobile?
Anyone got it working?

and then

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.

kiss_sdl - Simple generic GUI widget toolkit for SDL2


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.

kiss_sdl - Simple generic GUI widget toolkit for SDL2


I saw that one thought about using kiss_sdl in the game Hope and then said:

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.
kiss_sdl - Simple generic GUI widget toolkit for SDL2


This thread was the second most viewed thread in the development forum, before moving the SDL Forum. Before moving the forum, last archived by the Wayback Machine on March 12, 2017, it had 87 460 views . Now all view counts are reset. People write a lot when they find any problems, but they don’t write anything when they don’t find any.

kiss_sdl - Simple generic GUI widget toolkit for SDL2


Is the high view count useful in that it kept it near the top of the forum?