A question on GUIs

SDL Development
1

Hello,

After looking at all of the GUIs listed in SDL’s Library section, a question
occured to me.

Must all GUIs built for SDL be so controling? Maybe I’m reading the APIs
wrong, but from what I saw, you have to set up SDL through the GUI system if
you are going to use them. But why? I did some work on a smal GUI for my own
projects. Just some basic button,image,text input work, and I was able to do
it all without the GUI taking over my interface with SDL. For instance, as far
as I can tell, when you shut down the GUI, it shuts SDL down as well, thus
killing the app. With the one I have been working on, you can kill it, and
reinitalize it when/if ever you want.

I’m not trying to toot my own horn, I’m just pointing out that it is possible,
obviously. So then, with such wonderful libraries as SDL_ttf, SDL_mixer, and
SDL_net, why is there no, good looking, submissive GUI? Or, if there is, could
someone please point me to it (I’m wanting to focus on the games, not the GUIs)

I am aware of the gui’s listed under the library section of libsdl.org, but the
ones that seemed more like an addon seems quite… well, ugly.

Also, I am doing my work in C, not C++, and while I can integrate it, I’d
rather deal with libraries writen in C (yes, it is easier to write a GUI in
cpp, I do understand)

Long winded, sorry. So what is everyone else’s thoughts on the GUI’s for
SDL/OpenGL out on the net?

Also, I do not mean any of what I said to be taken as an insult to those who
have made the current GUI libraries. I am actually very impressed with them, I
just need something much lighter. Any suggestions anyone?

Micah

2

Also, I am doing my work in C, not C++, and while I can integrate it, I’d
rather deal with libraries writen in C (yes, it is easier to write a GUI in
cpp, I do understand)

I prefer plain C over C++ myself. C works fine. Gtk+/Gnome is
programmed in object oriented C for example.

Long winded, sorry. So what is everyone else’s thoughts on the GUI’s for
SDL/OpenGL out on the net?

So far I have written my own SDL widgets in C, too.

Also, I do not mean any of what I said to be taken as an insult to those who
have made the current GUI libraries. I am actually very impressed with them, I
just need something much lighter. Any suggestions anyone?

Don’t assume everyone else’s code is perfect. Maybe you are on to
something. Package it up and publish it.

ChrisOn 12/22/05, Micah Brening <micah.brening at gmail.com> wrote:

–
E-Mail: Chris Nystrom
Business: http://www.shaklee.net/austin
Blog: http://conversazione.blogspot.com/
AIM: nystromchris

3

I’ve had my own rather submissive GUI under development for a while now, but
it’s C++. Still, it only defines some abstract classes (Window, Button,
etc) and lets the developer do all the painting. I haven’t tried putting it
into any other projects to see how well it integrates, but I’m pretty sure
it’s not exactly domineering.On 12/22/05, Micah Brening <micah.brening at gmail.com> wrote:

Hello,

After looking at all of the GUIs listed in SDL’s Library section, a
question
occured to me.

Must all GUIs built for SDL be so controling? Maybe I’m reading the APIs
wrong, but from what I saw, you have to set up SDL through the GUI system
if
you are going to use them. But why? I did some work on a smal GUI for my
own
projects. Just some basic button,image,text input work, and I was able to
do
it all without the GUI taking over my interface with SDL. For instance,
as far
as I can tell, when you shut down the GUI, it shuts SDL down as well, thus
killing the app. With the one I have been working on, you can kill it,
and
reinitalize it when/if ever you want.

I’m not trying to toot my own horn, I’m just pointing out that it is
possible,
obviously. So then, with such wonderful libraries as SDL_ttf, SDL_mixer,
and
SDL_net, why is there no, good looking, submissive GUI? Or, if there is,
could
someone please point me to it (I’m wanting to focus on the games, not the
GUIs)

I am aware of the gui’s listed under the library section of libsdl.org,
but the
ones that seemed more like an addon seems quite… well, ugly.

Also, I am doing my work in C, not C++, and while I can integrate it, I’d
rather deal with libraries writen in C (yes, it is easier to write a GUI
in
cpp, I do understand)

Long winded, sorry. So what is everyone else’s thoughts on the GUI’s for
SDL/OpenGL out on the net?

Also, I do not mean any of what I said to be taken as an insult to those
who
have made the current GUI libraries. I am actually very impressed with
them, I
just need something much lighter. Any suggestions anyone?

Micah

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

–
Cheers,
Josh

PGP: http://revvy.box43.net/Josh_Matthews.asc

4

Micah Brening <micah.brening gmail.com> writes:

Hello,
I wanted to comment on the two followups that were posted, but to spare gmane,
I’ll just reply once.

In reply from the message from Chris:

I prefer plain C over C++ myself. C works fine. Gtk+/Gnome is
programmed in object oriented C for example.

Good to hear!
Yes, C++ has more features,
yes, when used right, C++ is more powerful.
But for me, as a programmer, I hardly use any of those features.
Most I can emulate with C. C does all I want it to do.
Sounds like I may not be alone.

So far I have written my own SDL widgets in C, too.

I had read somewhere that for best performance, in a game,
it’s best to hard code all of the GUI.
But if a GUI library were writen very lightly yet powerful,
would there be all that much of a difference?

Don’t assume everyone else’s code is perfect. Maybe you are on to
something. Package it up and publish it.

Give me a few more months to get some more features
(labels, text, checkboxes, text input, etc…) and I may.
But don’t wait for it since I’d wager anyone else reading from this group would
do it better.
Just a simple, skinable, perhaps scriptable GUI on demand.
(It’s there when you need it, and not when you don’t)

Also, follow your own advice, you said you had writen your own widgets, package
them up and publish it.

In reply to the message from Josh:

I’ve had my own rather submissive GUI under development for a while now, but
it’s C++. Still, it only defines some abstract classes (Window, Button, etc)
and lets the developer do all the painting. I haven’t tried putting it into
any other projects to see how well it integrates, but I’m pretty sure it’s not
exactly domineering.

Don’t take me wrong, I’ve got nothing against C++.
It’s a kick-butt language, very powerful.
And kudos on letting the developer do the painting,
because you could in theory,
take the surface you’d normally blit,
and turn it into a OpenGL structure,
and there you go, it supports OpenGL
(yes, you get a performance hit when generating textures,
but if done correctly…)
I say, keep up development on it.
When it is where you want it, let us in on it :wink:

5

Guichan is a very minimalistic gui that is much less intrusive.

El jue, 22-12-2005 a las 23:10 +0000, Micah Brening escribi?:> Hello,

After looking at all of the GUIs listed in SDL’s Library section, a question
occured to me.

Must all GUIs built for SDL be so controling? Maybe I’m reading the APIs
wrong, but from what I saw, you have to set up SDL through the GUI system if
you are going to use them. But why? I did some work on a smal GUI for my own
projects. Just some basic button,image,text input work, and I was able to do
it all without the GUI taking over my interface with SDL. For instance, as far
as I can tell, when you shut down the GUI, it shuts SDL down as well, thus
killing the app. With the one I have been working on, you can kill it, and
reinitalize it when/if ever you want.

I’m not trying to toot my own horn, I’m just pointing out that it is possible,
obviously. So then, with such wonderful libraries as SDL_ttf, SDL_mixer, and
SDL_net, why is there no, good looking, submissive GUI? Or, if there is, could
someone please point me to it (I’m wanting to focus on the games, not the GUIs)

I am aware of the gui’s listed under the library section of libsdl.org, but the
ones that seemed more like an addon seems quite… well, ugly.

Also, I am doing my work in C, not C++, and while I can integrate it, I’d
rather deal with libraries writen in C (yes, it is easier to write a GUI in
cpp, I do understand)

Long winded, sorry. So what is everyone else’s thoughts on the GUI’s for
SDL/OpenGL out on the net?

Also, I do not mean any of what I said to be taken as an insult to those who
have made the current GUI libraries. I am actually very impressed with them, I
just need something much lighter. Any suggestions anyone?

Micah

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
Roger D. Vargas
Formatur Santiago

6

Micah Brening wrote:

Hello,

After looking at all of the GUIs listed in SDL’s Library section, a question
occured to me.

Must all GUIs built for SDL be so controling? Maybe I’m reading the APIs
wrong, but from what I saw, you have to set up SDL through the GUI system if
you are going to use them. But why? I did some work on a smal GUI for my own
projects. Just some basic button,image,text input work, and I was able to do
it all without the GUI taking over my interface with SDL. For instance, as far
as I can tell, when you shut down the GUI, it shuts SDL down as well, thus
killing the app. With the one I have been working on, you can kill it, and
reinitalize it when/if ever you want.

The problem is the event loop. Your buttons (widgets) have to listen
for mouse and keyboard events. If you hook up there you don’t need any more
to access raw SDL routines and if you do you will end up doing the same thing
twice. One for when you gui is on and one for when is off. So most people assume
what the hell? keep it on.

I am also writing a c++ SDL GUI. For me the major problems were that no SDL toolkit had
a layout manager ala Qt or GTK. The ones that had one were wftk (very slow) and agar
(C and GTK based). All the others are using pixel coordinates…

     .bill
7

Vassilis Virvilis <vasvir iit.demokritos.gr> writes:

The problem is the event loop. Your buttons (widgets) have to listen
for mouse and keyboard events. If you hook up there you don’t need any more
to access raw SDL routines and if you do you will end up doing the same thing
twice.

Well, for that, what I used was registering callbacks.
A button, for example, listens to mouse button events,
and mouse motion events (for mouseover)
So in the game, you simply parse the events to see if it is anything you need,
then pass the event structure to the GUI parser
which checks to see what kind of event,
and then calls up the registered functions to deal with it,
passing the pointers needed.

But you are right. It does mean there would be duplication.
But it doesn’t seem to cost all too much,
and it gives me freedom to not be completely dependant
on the GUI drawing functions.

Also, with the setup I have now, I can shut off the GUI all together,
call up a console (sdl_console or oglconsole) and set up the game that way.

For me the major problems were that no SDL toolkit had
a layout manager ala Qt or GTK.

But then, if you need a layout manager and such,
then you aren’t using it for a simple game menu, I wouldn’t think.
So, yes, if you are making a multimedia application, a good, fast,
and very powerful GUI would be very good.
But I’m talking about a simple collection for buttons,
images, and so on, for games.

In fact, I guess I’m thinking a simple GUI system to be compared to oglconsole
(a brilliant yet simple library)
It is there for you to call up, but it is submissive to your every command.
It doesn’t set up the window for you.
It doesn’t dictate anything about how you program, or what all you use.
It does what it needs for itself, and leaves you to the rest.

Micah

8

Roger D. Vargas <roger ehtsc.co.cu> writes:

Guichan is a very minimalistic gui that is much less intrusive.

Hmm, and it also looked pretty good as well.
I guess I should investigate it a little further, thank you.

9

Actually there is a great SDL/OpenGL GUI library.

http://gigi.sourceforge.net/

I maintain the website (needs some updates but waiting for specific
release) and am using it for my project. The author originally wrote it
for his project http://freeorion.sourceforge.net

The library supports a comprehensive set of controls/widgets, great
general usability (mouse wheel and whatnot work as expected), and the
render function is completely overrideable.

It’s a very powerful library. Let me know if you find it useful. Also
if you decide to use it in your project email me from the website, I’ll
add a link to it to the projects list.

Shawn McCool

10

GiGi was the first GUI system that I looked at when deciding on one,
but I decided not to use it when I compiled the example program and
some of the text was rendered out of place. Also, getting the library
to compile with the supplied MSVC project file was less than fun.On 12/23/05, Shawn McCool wrote:

Actually there is a great SDL/OpenGL GUI library.

http://gigi.sourceforge.net/

I maintain the website (needs some updates but waiting for specific
release) and am using it for my project. The author originally wrote it
for his project http://freeorion.sourceforge.net

The library supports a comprehensive set of controls/widgets, great
general usability (mouse wheel and whatnot work as expected), and the
render function is completely overrideable.

It’s a very powerful library. Let me know if you find it useful. Also
if you decide to use it in your project email me from the website, I’ll
add a link to it to the projects list.

11

Shawn McCool wrote:

Actually there is a great SDL/OpenGL GUI library.

http://gigi.sourceforge.net/

I maintain the website (needs some updates but waiting for specific
release) and am using it for my project. The author originally wrote it
for his project http://freeorion.sourceforge.net

Looks like an update for the GUI toolkits page is required. I haven’t heard
this one or Guichan before amongst others I already knew such as paragui,
aedGUI etc…

GIGI looks pretty impressive by the way…

     .bill
12

Shawn McCool <shawn jockstocks.com> writes:

Actually there is a great SDL/OpenGL GUI library.

http://gigi.sourceforge.net/

It looks like a very attractive GUI library. The only problem I can see so far
would be that it is writen in C++, requiring me to get Boost, and Devil (not a
problem, just… extra dependancies) As long as I can interface to it from C,
I will certainly give it a try. And since I’m not using Visual Studio for my
windows port, I don’t need to worry about that (referencing a previous post)

The library supports a comprehensive set of controls/widgets, great
general usability (mouse wheel and whatnot work as expected), and the
render function is completely overrideable.

Very good that the render functions are overrideable, since I wish to support
SDL drawing, as well as OpenGL (not at the same time to the main screen of
course, but when choosing a graphics backend)

It’s a very powerful library. Let me know if you find it useful. Also
if you decide to use it in your project email me from the website, I’ll
add a link to it to the projects list.

I’ll certainly check it out, Thanks for the link (I found it in the SDL Library
after you mentioned it, I’m not sure how I missed it)

Micah

13

Micah Brening <micah.brening at gmail.com> wrote:

I prefer plain C over C++ myself. C works fine. Gtk+/Gnome is
programmed in object oriented C for example.

Good to hear!
Yes, C++ has more features,
yes, when used right, C++ is more powerful.
But for me, as a programmer, I hardly use any of those features.
Most I can emulate with C. C does all I want it to do.
Sounds like I may not be alone.

sorry, but these arguments sound masochistic to me. And the mentioned
gtk+ is a perfectly good example to not code an OO toolkit in C. awfully
long function names, no namespaces, casts all over the place. i think
the only valid reason, gtk is done in C, is that at the time it was
started, C++ wasn’t that mature and portable. where is the point in
coding OO, using a language that does not support it, when on the other
hand, there is an OO counterpart of that language?

just my 2 cents …
clemens

p.s.: hopefully not starting a flamewar here.

14

Clemens Kirchgatterer <clemens 1541.org> writes:

sorry, but these arguments sound masochistic to me. And the mentioned
gtk+ is a perfectly good example to not code an OO toolkit in C. awfully
long function names, no namespaces, casts all over the place. i think
the only valid reason, gtk is done in C, is that at the time it was
started, C++ wasn’t that mature and portable. where is the point in
coding OO, using a language that does not support it, when on the other
hand, there is an OO counterpart of that language?

Well, as one that prefers C, I do have to agree with what you said. The long
function names has caused many compilation errors for me due to not spelling a
function correctly (oohh, I wrote new_buttn_mouse_event_listener instead of
new_button… blah blah blah) I never used namespaces, but I believe you anyway.

My ownly problem is that C fits my mind better (though I learned C++ first) I
have been working on one project for about a year, I kept switching between C
and C++. C++ was developing faster, but C was running faster (a difference
between 30fps and 50fps on one of my dumpster PCs(litterally collected from the
trash)) If I found how to make C++ run as fast as C, I may switch to it and
stick with it. (that or just forget it all together and stick with Assembly)

But this is getting off topic, sorry for the ramble

p.s.: hopefully not starting a flamewar here.

Heh, I agree there as well. I probably shouldn’t even reply to this one in case
it does spur on something. No offence meant people! Just rambling.

Micah

15

Long winded, sorry. So what is everyone else’s thoughts on the GUI’s for
SDL/OpenGL out on the net?

Also, I do not mean any of what I said to be taken as an insult to those who
have made the current GUI libraries. I am actually very impressed with them, I
just need something much lighter. Any suggestions anyone?

I wrote my own GUI (in C++). I needed something that would work with
both SDL and OpenGL rendering, was very customizable, integrated well
with the rest of my engine, and had the widgets I wanted to use. I
started this over a year ago. Back then I wasn’t able to find any GUI
that matched my specs. The bigger problem though is that from what I’ve
seen, these projects tend to get abandoned (like many open source
projects without a large user base).

My GUI isn’t perfect, but it’s pretty good. I’ve refactored it a few
times, and each time it got a bit better. It has a lot of widgets which
are set up through XML (including a list box that supports multiple
columns as well as images in the rows/cells), there’s a Window Manager
that takes care of window Z sorting, and other stuff. It also has
bindings to Lua through LuaBind. I’ve been thinking about releasing a
lot of my engine after I’m done with my game. All of it is supposed to
be portable by design, although I haven’t tested that yet. Is there any
interest in Yet Another GUI (and other things)?

16

Is there any
interest in Yet Another GUI (and other things)?

I’m interested. Does it support joysticks?

17

Is there any
interest in Yet Another GUI (and other things)?

I’m interested. Does it support joysticks?

The GUI responds to mouse motion/button events and keyboard events. The
events are custom classes, but right now they simply wrap the SDL event
pointers to reduce overhead. It’s not really designed with joysticks in
mind in that sense, but it’s not hard to change because the mouse event
is only accessed in one place (an event handler function in the widget
base class) and then a virtual function is called for the event, which
handles it. Changing this would allow you to generate mouse events based
on joystick input. The GUI doesn’t care where the events come from.

There’s just one hack I have right now that would be a problem.
Basically, when a widget becomes visible it has to check if it has mouse
focus (if the mouse is over it when this happens). Right now I’m using
SDL_GetMouseState() to do this because there’s no other way for it to
know the mouse position until a mouse motion event occurs. This is
because a widget doesn’t get any events while it’s not visible. I want
to change this to something more elegant, but haven’t figured out a
better solution yet.

18

Ilya Olevsky wrote:

There’s just one hack I have right now that would be a problem.
Basically, when a widget becomes visible it has to check if it has
mouse focus (if the mouse is over it when this happens). Right now
I’m using SDL_GetMouseState() to do this because there’s no other way
for it to know the mouse position until a mouse motion event occurs.
This is because a widget doesn’t get any events while it’s not
visible. I want to change this to something more elegant, but haven’t
figured out a better solution yet.

i keep track of the current mouse position in an “somehow” globally
available struct { int x, y, button, state }; whenever there is a mouse
event i update this struct. you could even initialize it with
SDL_GetMouseState() at startup.

got the idea?

clemens

19

El lun, 26-12-2005 a las 19:08 -0500, Ilya Olevsky escribi?:

My GUI isn’t perfect, but it’s pretty good. I’ve refactored it a few
times, and each time it got a bit better. It has a lot of widgets which
are set up through XML (including a list box that supports multiple
columns as well as images in the rows/cells), there’s a Window Manager
that takes care of window Z sorting, and other stuff. It also has
bindings to Lua through LuaBind. I’ve been thinking about releasing a
lot of my engine after I’m done with my game. All of it is supposed to
be portable by design, although I haven’t tested that yet. Is there any
interest in Yet Another GUI (and other things)?
Yes, Im interested. Im writing my own GUI now, but could use any other
if it suits my needs.–
Roger D. Vargas
Formatur Santiago

20

i keep track of the current mouse position in an “somehow” globally
available struct { int x, y, button, state }; whenever there is a mouse
event i update this struct. you could even initialize it with
SDL_GetMouseState() at startup.

Yeah, I thought about this last night and decided that I’ll have to
store the latest mouse coordinates in the Window Manager. When a widget
becomes visible, the Window Manager can send it a MouseMotion event with
the current coordinates so that it can automatically check if it has
mouse focus.