List all GUI toolkits for SDL

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 DOn Sun, Sep 11, 2016 at 3:43 PM, Sparks wrote:

actsl wrote:

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

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jonny D wrote:

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

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.

1 Like

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.

JeffOn Sunday 11 September 2016 13:48:12 actsl 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.

j_post wrote:

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

2016-09-11 20:40 GMT+02:00 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.

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

1 Like

2016-09-19 10:04 GMT-03:00, David Demelier <demelier.david at gmail.com>:

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.

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

Jonny DOn Mon, Sep 19, 2016 at 11:49 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

2016-09-19 10:04 GMT-03:00, David Demelier <demelier.david at gmail.com>:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Travis McKinney wrote:

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

Good points. Should be straightforward enough to create raster GUI assets
on the fly.On 30 September 2016 at 06:29, actsl wrote:

Travis McKinney wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Also GWork. Skinnable. Good widget set.

Sparks wrote:

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.

Thank you!!! Whats that obsession with lines of code? Is it 1970 again?

This is a general theoretical question, i created a thread to discuss questions like these Does complexity matter (in general and in GUI) , it’s better to talk there, as this is not really about any particular GUI toolkit.

I am making HorusUI (an imgui lib for tool making) https://github.com/7thFACTOR/horus_ui

There is now also AGAR 1.5.0 for SDL 2.0.8.

SDL AGAR Announcement

I’ve just release the first version of bogue:

This is a GUI library written from scratch in SDL2, suitable for games or desktop applications.
(still under development). Probably not so interesting for many of you because it targets the ocaml language. (which, by the way, is a great language, very safe and really fun to code)

See the demo video:

I’ve got mine, see https://github.com/Photosounder/rouziclib/
It either uses software rendering or uses a rather exotic OpenCL renderer. It’s optionally markup-based, it has an editor, it has floating windows, text editing fields with undo, it has buttons, checkboxes, radio buttons, knobs with value editing and mathematical expression parsing, dropdown menus, a mouse-guided infinite zoom scrolling mode (everything is on an infinite plane, unless it’s a window that is pinned to the screen, you can move and zoom around with the cursor stuck in the centre), dithered floating point graphics, tiled mipmap-based picture displaying, and some weird stuff like being able to insert anything (like GUI elements) inside text as if it were a character (I like to insert text fields inside text, like in the second screenshot). Also it’s all scalable, not bitmap-based, and antialiased. See https://github.com/Photosounder/rouziclib-picture-viewer for an example project, the code for it is really small and simple.


BasicC GEM - 367 lines, 1000 lines all BasicC :slight_smile: