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.

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.
_______________________________________________
SDL mailing list

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

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

A couple of years ago, we saw KiWi on the mailing list: https://github.com/mobius3/KiWiIt 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



On Sun, Sep 11, 2016 at 7:22 AM, MrTAToad wrote:

On 9/11/16, MrTAToad wrote:

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
_______________________________________________
SDL mailing list

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

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.


_______________________________________________
SDL mailing list

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

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





Am 11.09.2016 um 13:22 schrieb "MrTAToad":

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.

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.

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




On Sun, Sep 11, 2016 at 3:43 PM, Sparks wrote:

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.

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.

On Sunday 11 September 2016 13:48:12 actsl wrote:
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
_______________________________________________
SDL mailing list

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

> 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

2016-09-11 20:40 GMT+02:00 actsl:

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.

--
Demelier David
_______________________________________________
SDL mailing list

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

2016-09-19 10:04 GMT-03:00, David Demelier:

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

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

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.

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!


On 19 September 2016 at 09:54, actsl wrote:

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.

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


On 30 September 2016 at 06:29, actsl wrote: