[SDL] List all GUI toolkits for SDL

[Daniel V]

How many GUI toolkits is there for SDL currently to use?

And how many are thinking of making their own GUI toolkit for SDL?

And what is the web Links to them and what platforms do they support,
and what SDL version? And what are the dependencies of other libraries
does these GUI toolkits have?

And to you currently thinking of making a GUI toolk kit, or has made one...
What was your goal?
What was you currently lacking?
What style of programming is it that you want to suooort?

Currently I am also thinking of making a GUI toolkit, so you can make
point an click applications that can run in the Linux terminal, that
also can be compiled all the common window system. And is also
thinking of giving it a state machine, so it scales well to bigger
applications, and to get separation of GUI and the rest of the
program. So programs can easily be converted to be client server
application, or to easily improve the GUI later for use under window
systems.

// Daniel V.

[MrTAToad]

SDL1 or SDL2 ?

For the former, I dont know. For the latter its around 3/4

SDL1
Geeonx GUI (http://forums.libsdl.org/viewtopic.php?t=12088)

SDL2 GUI[u]
Guichan - Uses OpenGL - (http://forums.libsdl.org/viewtopic.php?t=12073)
KISS - (http://forums.libsdl.org/viewtopic.php?t=11772)
Nanogui - Uses OpenGL - (http://forums.libsdl.org/viewtopic.php?t=11636&highlight=gui)
neoGFX - Uses OpenGL - (http://forums.libsdl.org/viewtopic.php?t=12033&highlight=gui)
SDL_gui - Seems to be specifically geared towards Android (https://github.com/mozeal/SDL_gui)

SDL_widgets - This is.. a weird one... Its a GUI system alright, but overly complicated and works only for specific compilers (because it is too Linux orientated) (http://members.chello.nl/w.boeke/SDL-widgets/)

[Jonathan Dearborn]

A couple of years ago, we saw KiWi on the mailing list:
https://github.com/mobius3/KiWi
It may have even been the first to be announced for SDL2.

If you use SDL_gpu or OpenGL directly, you can additionally set up
rendering for librocket (http://librocket.com/) and Nuklear (
https://github.com/vurtun/nuklear). These would work on either SDL1.2 or
SDL2 and they look great.

Jonny D

Post by MrTAToad
SDL1 or SDL2 ?
For the former, I dont know. For the latter its around 3/4
SDL1
Geeonx GUI (http://forums.libsdl.org/viewtopic.php?t=12088)
SDL2 GUI[u]
Guichan - Uses OpenGL - (http://forums.libsdl.org/viewtopic.php?t=12073)
KISS - (http://forums.libsdl.org/viewtopic.php?t=11772)
Nanogui - Uses OpenGL - (http://forums.libsdl.org/view
topic.php?t=11636&highlight=gui)
neoGFX - Uses OpenGL - (http://forums.libsdl.org/view
topic.php?t=12033&highlight=gui)
SDL_gui - Seems to be specifically geared towards Android (
https://github.com/mozeal/SDL_gui)
SDL_widgets - This is.. a weird one... Its a GUI system alright, but
overly complicated and works only for specific compilers (because it is too
Linux orientated) (http://members.chello.nl/w.boeke/SDL-widgets/)
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Eric Wing]

Post by MrTAToad
SDL1 or SDL2 ?
For the former, I dont know. For the latter its around 3/4
SDL1
Geeonx GUI (http://forums.libsdl.org/viewtopic.php?t=12088)
SDL2 GUI[u]
Guichan - Uses OpenGL - (http://forums.libsdl.org/viewtopic.php?t=12073)
KISS - (http://forums.libsdl.org/viewtopic.php?t=11772)
Nanogui - Uses OpenGL -
(http://forums.libsdl.org/viewtopic.php?t=11636&highlight=gui)
neoGFX - Uses OpenGL -
(http://forums.libsdl.org/viewtopic.php?t=12033&highlight=gui)
SDL_gui - Seems to be specifically geared towards Android
(https://github.com/mozeal/SDL_gui)
SDL_widgets - This is.. a weird one... Its a GUI system alright, but overly
complicated and works only for specific compilers (because it is too Linux
orientated) (http://members.chello.nl/w.boeke/SDL-widgets/)

Additionally,

KiWi (Killer Widgets) - Built on the SDL2 2D renderer. Pure C.
https://github.com/mobius3/KiWi

Nuklear - Renderer agnostic, no dependency, header-only, pure C,
Immediate Mode GUI. Repo contains adaptors, including SDL+OpenGL.
(I've been working on an SDL_gpu adaptor.)
https://github.com/vurtun/nuklear

[ancientcc]

Rose - Built on last SDL version: SDL2-2.0.4. Language: C/C++. Mainly focus
on iOS, Android and Windows.
https://github.com/freeors/Rose

Main feature
.Provide Rose Studio, it can simplify create project on all platform.
.Really achieve "one code and run all platform".
.Render image use OpenGL/ES that SDL2 provided.
.Has a platform-independent, full widget's window system.
.More detailed framework, deep into unit level on "Big Map".
.Powerful animation.
.Integrate gettext to handle internationalization.
.PowerFul BLE support.

[Martin Gerhardy]

there is also turbobadger with has a pull request open to show the usage with sdl2.

Post by MrTAToad
SDL1 or SDL2 ?
For the former, I dont know. For the latter its around 3/4
SDL1
Geeonx GUI (http://forums.libsdl.org/viewtopic.php?t=12088)
SDL2 GUI[u]
Guichan - Uses OpenGL - (http://forums.libsdl.org/viewtopic.php?t=12073)
KISS - (http://forums.libsdl.org/viewtopic.php?t=11772)
Nanogui - Uses OpenGL - (http://forums.libsdl.org/viewtopic.php?t=11636&highlight=gui)
neoGFX - Uses OpenGL - (http://forums.libsdl.org/viewtopic.php?t=12033&highlight=gui)
SDL_gui - Seems to be specifically geared towards Android (https://github.com/mozeal/SDL_gui)
SDL_widgets - This is.. a weird one... Its a GUI system alright, but overly complicated and works only for specific compilers (because it is too Linux orientated) (http://members.chello.nl/w.boeke/SDL-widgets/)
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[actsl]

The number of lines of code in all these GUI toolkits is as follows:

Geeonx -- closed source
Nanogui -- 20525 lines
Guichan -- 28362 lines
neoGFX -- not finished, but will likely be an advanced type of big toolkit
SDL_gui -- 7514 lines
SDL-widgets -- 10301 lines
KiWi -- 5600 lines
Nuklear -- 34692 lines
Rose -- 40207 lines

kiss_sdl -- 2437 lines. I didn't make it if it were not smaller than any of these, what sense does it make to write yet another GUI toolkit. The paradigm of that is "Unnecessary complexity is evil" versus "Complexity doesn't matter".

But this is a comparison of these only from my perspective, about only one aspect of them. May interest some people too though. But some others my compere these GUI toolkits from some other perspective, that's interesting too.

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

[Sparks]

Number of lines in the code base no way equates to the quality of the library itself, it is a meaningless metric to use just to compare the libraries by LOC, unless you are comparing libraries that do the exact same thing.

[Jonathan Dearborn]

I also would argue (as others have) that more lines of code does not imply
more complexity.

The reason: The complexity passed on to the user when he wants the UI to
look a certain way is the complexity that counts. This can occur either in
the API or in code structure when API design fails and he has to modify the
library.

Jonny D

Post by Sparks
Number of lines in the code base no way equates to the quality of the
library itself, it is a meaningless metric to use just to compare the
libraries by LOC, unless you are comparing libraries that do the exact same
thing.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[David Demelier]

Post by actsl
Geeonx -- closed source
Nanogui -- 20525 lines
Guichan -- 28362 lines
neoGFX -- not finished, but will likely be an advanced type of big toolkit
SDL_gui -- 7514 lines
SDL-widgets -- 10301 lines
KiWi -- 5600 lines
Nuklear -- 34692 lines
Rose -- 40207 lines
kiss_sdl -- 2437 lines. I didn't make it if it were not smaller than any of
these, what sense does it make to write yet another GUI toolkit. The
paradigm of that is "Unnecessary complexity is evil" versus "Complexity
doesn't matter".
But this is a comparison of these only from my perspective, about only one
aspect of them. May interest some people too though. But some others my
compere these GUI toolkits from some other perspective, that's interesting
too.

I know wonder if you are a troll.

Each time we are talking about GUI you still comparing the number of
lines of code. Stop promoting your toolkit because it has less lines
of code and saying other toolkits are bloat and complex. A software is
not necessary more complex by having more lines of code.

If your GUI only offers buttons, combobox and lists while a toolkit
provides file chooser, color selector, web view, tabs, stacks, themes,
etc, it is not bloat or complex but obviously has more lines of code.
It just has more features.

[Sik the hedgehog]

Post by David Demelier
I know wonder if you are a troll.
Each time we are talking about GUI you still comparing the number of
lines of code. Stop promoting your toolkit because it has less lines
of code and saying other toolkits are bloat and complex. A software is
not necessary more complex by having more lines of code.
If your GUI only offers buttons, combobox and lists while a toolkit
provides file chooser, color selector, web view, tabs, stacks, themes,
etc, it is not bloat or complex but obviously has more lines of code.
It just has more features.

I'm surprised you didn't mention the obvious one: blank lines,
comments and other lines that aren't actual code (like having { on its
own line instead of right after the parenthesis). And even that
doesn't matter because it all depends on what the compiler does -
sometimes it'll do a better job with seemingly unoptimal code, simply
because it understands it better.

[Jonathan Dearborn]

What, you don't think putting { on the next line increases the complexity
of a library?

Jonny D


On Mon, Sep 19, 2016 at 11:49 AM, Sik the hedgehog <

Post by Sik the hedgehog

Post by David Demelier
I know wonder if you are a troll.
Each time we are talking about GUI you still comparing the number of
lines of code. Stop promoting your toolkit because it has less lines
of code and saying other toolkits are bloat and complex. A software is
not necessary more complex by having more lines of code.
If your GUI only offers buttons, combobox and lists while a toolkit
provides file chooser, color selector, web view, tabs, stacks, themes,
etc, it is not bloat or complex but obviously has more lines of code.
It just has more features.

I'm surprised you didn't mention the obvious one: blank lines,
comments and other lines that aren't actual code (like having { on its
own line instead of right after the parenthesis). And even that
doesn't matter because it all depends on what the compiler does -
sometimes it'll do a better job with seemingly unoptimal code, simply
because it understands it better.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[actsl]

I also would argue (as others have) that more lines of code does not imply more complexity.
The reason: The complexity passed on to the user when he wants the UI to look a certain way is the complexity that counts.  This can occur either in the API or in code structure when API design fails and he has to modify the library.

Right but, the complexity of the code cannot be completely hidden, and attempt to do so may decrease the freedom of the user to do what the user wants to do, or what may be necessary to do in some case.

But as i said, this is only one aspect of comparing the libraries, i agree that it no way says everything about the code or the library, other features have to be considered also to meaningfully compare. Yet the number of lines of code is one important aspect in comparing the codes.

I would like to see someone comparing these GUI toolkits by other features.

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

[MrTAToad]

The other criteria to judge them on is how often they are updated and how good the instructions are. If they are several years old, then the chances of getting and bugs/solving problems are remote.

And if you have to wade through badly written and poorly documented code, you'll be moving to something else very quickly.

[j_post]

Post by actsl
Right but, the complexity of the code cannot be completely hidden, and
attempt to do so may decrease the freedom of the user to do what the user
wants to do, or what may be necessary to do in some case.
But as i said, this is only one aspect of comparing the libraries, i agree
that it no way says everything about the code or the library, other
features have to be considered also to meaningfully compare. Yet the
number of lines of code is one important aspect in comparing the codes.

I would say that lines of code is of relative unimportance. Decades ago, when
computers were *slow* compared to today, I wrote some software that was
heavily table driven. This increased lines of code immensely compared to
algorithmic computations, but it was blindingly *fast*, which was one of my
primary objectives. It was also conceptually simple and therefore easy to
maintain.

I believe that the most important aspect of software is summed up by what I
would tell the programmers who worked for me: "I don't care how difficult it is
for you to write the code, I care about how easy it is for the customers to
use."

Beyond that, I think the most important characteristics of good software are,
in no rigorous order,

Algorithmically correct: it does what it's supposed to do and nothing else. It
is essentially bug free in that unusual circumstances, such as unexpected
input will not cause it to do anything insane.

Simplicity: it should be easy to maintain.

Flexibility: it should be easy to add new features or modify behavior.

If it involves a GUI, it should be intuitive and pleasant to look at (which
IMHO kiss_sdl is not - the graphics are too primitive).

If it doesn't have a gui, it should be intuitive and easy to use.

And so on... I'm not trying to write a treatise on good software design.

Lines of code is near the bottom of the list.

I did take a very brief look at your code, with a view to adapting it to SDL
1.2. I have a lot of code using 1.2 and rather than rewrite it for 2.0, I
think it would be easier to just rewrite it in Java, which also takes care of
porting issues - specifically that Apple intentionally makes it difficult for 3rd
party developers to compile code for Macs.

I admit I didn't have time to look at your code in more depth, but at first
glance it didn't seem to be all that easy to modify it for SDL 1.2 (and then
there's the graphics issue).

Nevertheless, I would encourage you to continue working on kiss_sdl, but don't
get hung up on lines of code. Keep It Simple is not the same as keep it short.

Jeff

[actsl]

I believe that the most important aspect of software is summed up by what I would tell the programmers who worked for me: "I don't care how difficult it is for you to write the code, I care about how easy it is for the customers to use."

Thanks god i don't work for you.

If it involves a GUI, it should be intuitive and pleasant to look at (which IMHO kiss_sdl is not - the graphics are too primitive).

So you want it all, elephant in a matchbox, and if one doesn't provide it, one is too bad? I don't think graphics is the most difficult part of a GUI toolkit, so i didn't add much of it.

I did take a very brief look at your code, with a view to adapting it to SDL 1.2. I have a lot of code using 1.2 and rather than rewrite it for 2.0, I think it would be easier to just rewrite it in Java, which also takes care of porting issues - specifically that Apple intentionally makes it difficult for 3rd party developers to compile code for Macs.

Yes sure, if you tried to rewrite it in Java, it's sure not that easy to modify it in that way, it is not written in a way good for Java. And thanks goodness you couldn't rewrite it in Java, Java is a bad language, imho.

These are just my opinions, our opinions differ, i hope you don't mind, i hope you understand that not everyone thinks the way you do. I think though that you are one in the camp "Complexity doesn't matter", so we are in different camps. I'm in a different camp, and there are people in my camp, yeah, give me fire to make coffee in the morning :)

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

[actsl]

Who knows programming, knows that comments and blank lines are all part of the code, there cannot be too many, for code to be readable. So even there, complexity matters. The number of lines of code is a measure of complexity of the code, considering that the code is well written. And is not obfuscated, in kiss_sdl it isn't. It is some measure, yet not the only measure of complexity. Yet it matters when the code has to be easily changeable, when the code is too long, it is not easily understandable, and also not easily changeable.

The details like placement of { depend on the coding style. In C code the good style is Kernighan & Ritchie coding style, or the Linux kernel coding style, which comes from this, i think many agree. This also somewhat determines the number of comments.

I think it can be argued endlessly whether the number of lines of code matters, or doesn't matter at all. But i think the bottom line is, it still somewhat matters. And more generally, complexity matters.

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

[Travis McKinney]

I love the terminal fallback idea.
What I'm looking for in a GUI is good subpixel rendering and anti aliasing.
I want crisp pixel free lines, shapes and text at any resolution.
Currently looking at adapting the AGG GUI.
Do any of the above mentioned GUIs have this capability?

I liken the lines of code metric to movie ratings. Something to go on but
doesn't determine wether I will like the film.
Also characters of code would be a better metric, especially for my coding
style, which is obsessively columnar,
I absolutely cannot abide by long lines in my own code. Multiple nested
templates, long lists of function parameters are all broken onto multiple
lines. A new line before and after every curly brace.
The main advantage is that I can use a tiling window manager to easily
compare 8+ files on one workspace!

Post by actsl
Who knows programming, knows that comments and blank lines are all part of
the code, there cannot be too many, for code to be readable. So even there,
complexity matters. The number of lines of code is a measure of complexity
of the code, considering that the code is well written. And is not
obfuscated, in kiss_sdl it isn't. It is some measure, yet not the only
measure of complexity. Yet it matters when the code has to be easily
changeable, when the code is too long, it is not easily understandable, and
also not easily changeable.
The details like placement of { depend on the coding style. In C code the
good style is Kernighan & Ritchie coding style, or the Linux kernel coding
style, which comes from this, i think many agree. This also somewhat
determines the number of comments.
I think it can be argued endlessly whether the number of lines of code
matters, or doesn't matter at all. But i think the bottom line is, it still
somewhat matters. And more generally, complexity matters.
------------------------------
kiss_sdl - Simple generic GUI widget toolkit for SDL2
https://github.com/actsl/kiss_sdl
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[actsl]

Post by Travis McKinney
want crisp pixel free lines, shapes and text at any resolution.

If what SDL2 does is not good enough for you, then kiss_sdl is not what you are looking for. Or you have to write the rendering yourself, which is not that difficult to do. Like MrTAToad used some other font library with kiss_sdl successfully, knowingly with no problem. This is how to do it with kiss_sdl, kiss_sdl is a simple or one could say rudimentary, GUI toolkit.

If you want some kind of very advanced rendering, out of the box, there are many different kinds of, then you may tell to MrFlibble what you want, he is currently writing the neoGFX GUI library, and he may add what you want. This would be an advanced and much more complex GUI library, this may be what appeals to you.

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

[Travis McKinney]

Good points. Should be straightforward enough to create raster GUI assets
on the fly.

Post by Travis McKinney
want crisp pixel free lines, shapes and text at any resolution.
If what SDL2 does is not good enough for you, then kiss_sdl is not what
you are looking for. Or you have to write the rendering yourself, which is
not that difficult to do. Like MrTAToad used some other font library with
kiss_sdl successfully, knowingly with no problem. This is how to do it with
kiss_sdl, kiss_sdl is a simple or one could say rudimentary, GUI toolkit.
If you want some kind of very advanced rendering, out of the box, there
are many different kinds of, then you may tell to MrFlibble what you want,
he is currently writing the neoGFX GUI library, and he may add what you
want. This would be an advanced and much more complex GUI library, this may
be what appeals to you.
------------------------------
kiss_sdl - Simple generic GUI widget toolkit for SDL2
https://github.com/actsl/kiss_sdl
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org