Hello,
I use Debian Wheezy and I not found in Google a GUI for SDL. I found
some proyects (wxwidgets, Qt, etc) but is not really for use in SDL.
I try other projects (agar, sdl-widgets, etc), but not are very
powerful and flexible and other mature and stable project like
wxwidgets.
I think a native GUI like wxwidgets are good idea.
P.D: yes, my English isn’t that good.
Hi,
In the mean time, check out libRocket. It’s very powerful, flexible and is easily integrated with SDL2. Downside? Development is barely alive. Thankfully, this doesn’t matter much at the moment, because the engine is already stable and provides plenty.
Cheers,
Jeffrey Carpenter <@Jeffrey_Carpenter>
-------------- next part --------------
A non-text attachment was scrubbed…
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1572 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20141128/834bae32/attachment.bin
To augment Jeff’s suggestion, you could also look into berkelium
http://berkelium.org/ or awesomium http://www.awesomium.com/ - you
essentially get the chromium browser’s rendering engine, so in a sense,
it’s similar to libRocket’s HTML-style interface design, but you also get
javascript, and on-par standards with webkit.
The major downside is that this is a lot of extra bloat. I would only
recommend either project if you are going to be using it a lot, because it
is a really heavy dependency.On Fri, Nov 28, 2014 at 7:31 AM, Jeffrey Carpenter wrote:
Hi,
In the mean time, check out libRocket. It’s very powerful, flexible and is
easily integrated with SDL2. Downside? Development is barely alive.
Thankfully, this doesn’t matter much at the moment, because the engine is
already stable and provides plenty.Cheers,
Jeffrey Carpenter
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Debian Wheezy only have SDL 1.2
2014-11-28 13:31 GMT+01:00 Jeffrey Carpenter :> Hi,
In the mean time, check out libRocket. It’s very powerful, flexible and is easily integrated with SDL2. Downside? Development is barely alive. Thankfully, this doesn’t matter much at the moment, because the engine is already stable and provides plenty.
Cheers,
Jeffrey Carpenter
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Short answer: It’s not going to happen.
Long answer: Most modern things written using SDL use OpenGL. A few
use Direct3D. There is no native OpenGL GUI, but there are a couple
of GUIs that can back-end into OpenGL like fltk. They’re pretty
heavy for what they are, though, and so you see much more often
people rolling their own. Who needs to worry about the traditional
2D aspects of rendering windows when the 3D system will handle the
details for you as a side effect of how it works?
For the few that use Direct3D, you’ve already got some access to
native Windows widgets?and you just can’t get much better than native
system controls in function. Getting them to look like you want them
to ? is an exercise for the reader.
2D games typically could benefit, but if they need extensive GUI
support, they are just as easily written in their native widget set
with an allocated pixel buffer as would be trying to shoehorn
something as large as fltk into the mix. And anything much smaller
can be stripped down more. At that point you’re back to the roll
your own approach.
Another part of the problem is that there used to be such GUIs for
SDL. They were for the software renderer, but they tended not to be
ported to the 2.0 Render API. Those most interested in such a thing
were counting on the promise of that API made in 1.3: It would always
be there, whether your game was 2D or 3D, and you’d always have
access to use it.
That promise never materialized, and support for fixed pipeline
OpenGL (required for OpenGL 1.x support, as well as for GLES 1.x) has
a lot to do with the reason why. Basically it’s not practically
possible to push the entire GL state on to a stack once a frame, do
stuff, and then put it all back the way it was. Without that, you’d
have to clearly set in stone what SDL expects when the renderer is
given control, and those expectations would have to be firmly
maintained. Possible, but hard. A few people have tinkered with it,
but nothing done that way could be released into a production
environment.
But doing that is a prerequisite for a GUI that can be used anywhere
SDL is used.
JosephOn Fri, Nov 28, 2014 at 01:11:43PM +0100, Altair Linux wrote:
Hello,
I use Debian Wheezy and I not found in Google a GUI for SDL. I found
some proyects (wxwidgets, Qt, etc) but is not really for use in SDL.I try other projects (agar, sdl-widgets, etc), but not are very
powerful and flexible and other mature and stable project like
wxwidgets.I think a native GUI like wxwidgets are good idea.
P.D: yes, my English isn’t that good.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2014-11-28 18:19 GMT-03:00, T. Joseph Carter :
Another part of the problem is that there used to be such GUIs for
SDL. They were for the software renderer, but they tended not to be
ported to the 2.0 Render API. Those most interested in such a thing
were counting on the promise of that API made in 1.3: It would always
be there, whether your game was 2D or 3D, and you’d always have
access to use it.That promise never materialized, and support for fixed pipeline
OpenGL (required for OpenGL 1.x support, as well as for GLES 1.x) has
a lot to do with the reason why. Basically it’s not practically
possible to push the entire GL state on to a stack once a frame, do
stuff, and then put it all back the way it was. Without that, you’d
have to clearly set in stone what SDL expects when the renderer is
given control, and those expectations would have to be firmly
maintained. Possible, but hard. A few people have tinkered with it,
but nothing done that way could be released into a production
environment.But doing that is a prerequisite for a GUI that can be used anywhere
SDL is used.
Forget all that, the mere fact of having multiple backends already
makes it unfeasible. Just a reminder that the renderer API has been
practically frozen since long ago since every time somebody propose an
improvement it never makes its way into the API because people insist
on only implementing it in only one backend. Now imagine if we needed
to keep every backend maintained to support that feature you mention.
The moment you use the renderer API is the moment you give up any
right to control how rendering is done.
What could be more feasible is for SDL2 to implement GUI logic, and
then let the program to draw it whatever way it wants. May seem
stupid, but 1) getting the logic right is actually the hardest part
(drawing is easy in comparison), 2) this is a common idiom in mobile
already and 3) SDL is already doing something like this with text
input (SDL handles text input logic, program decides how to draw
whatever text is being entered).
Hi,
I use Debian Wheezy and I not found in Google a GUI for SDL. I found
some proyects (wxwidgets, Qt, etc) but is not really for use in SDL.
If you don’t mind a (very) heavyweight solution, the following should
be possible:
gtk+ -> clutter-gtk -> clutter -> cogl -> SDL
As of release 1.9.4, Cogl supports an SDL back-end. I have not personally
tried the SDL back-end on Cogl, but I have tried the remainder of the
code path above.
That is, I’ve been able to successfully compile and run a demo of GTK+3
widgets embedded into Clutter actors via clutter-gtk. I saw it working
locally on Windows, I understand it works on OSX as well, and of course
on Linux.
clutter-gtk is performing all the appropriate world-to-screen translations,
so one can fully interact with the GTK+ widgets as they are spinning and
warping around on the screen (as Clutter actors) at 60Hz.
Kind of cool 
Regards,
Bill
I’m working on a DOM-like API upon SDL and also in the browser with
emscripten.
As you say, there no well established GUI for that.
There is Juice. I think it looks useful. I don’t use it because you
need to use their IDE. I like command line
There is also a little GUI which render vertex in a buffer that can be
used with SDL. Sorry, I don’t remenber its name. It’s on GitHub. You
don’t do the layout. The tool do it for you in a kind of worksheet of
controls.
Le Fri, 28 Nov 2014 17:42:35 -0800,
Bill Kelly a ?crit :> Hi,
I use Debian Wheezy and I not found in Google a GUI for SDL. I found
some proyects (wxwidgets, Qt, etc) but is not really for use in SDL.If you don’t mind a (very) heavyweight solution, the following should
be possible:gtk+ -> clutter-gtk -> clutter -> cogl -> SDL
As of release 1.9.4, Cogl supports an SDL back-end. I have not
personally tried the SDL back-end on Cogl, but I have tried the
remainder of the code path above.That is, I’ve been able to successfully compile and run a demo of
GTK+3 widgets embedded into Clutter actors via clutter-gtk. I saw it
working locally on Windows, I understand it works on OSX as well, and
of course on Linux.clutter-gtk is performing all the appropriate world-to-screen
translations, so one can fully interact with the GTK+ widgets as they
are spinning and warping around on the screen (as Clutter actors) at
60Hz.Kind of cool
Regards,
Bill
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
GTK+ will contain OpenGL context support as of next release.
If you’re using SDL just to manage an OpenGL context, you can easily switch between the GTK+ context in windowed mode, and a fullscreen SDL-managed context.
At this point I embed an SDL-managed OpenGL context in GTK+, using a GtkDrawingArea. After the next release of GTK+ I will use a hybrid method, where SDL is only used to manage a fullscreen context, and the native GTK+ OpenGL will be used for windowed contexts.
If you’re talking about using the SDL Renderer, then I have no advice, I’m not sure how this can be embedded in a GUI toolkit. I’m not sure why you’d want to anyway when OpenGL exists, and can do everything the SDL Renderer can and more.
SDL_CreateWindowFrom() is your friend.
Support of working features is less difficult than implementation.
But any attempt at implementation is shot down, so there’s no point.
Basically SDL’s renderer should probably be an extension library
since SDL_net and SDL_image are used far more often by developers
than the render API and the render API is functionally crippled
because nobody is allowed to touch it.
JosephOn Fri, Nov 28, 2014 at 08:42:18PM -0300, Sik the hedgehog wrote:
2014-11-28 18:19 GMT-03:00, T. Joseph Carter <@T_Joseph_Carter>:
Another part of the problem is that there used to be such GUIs for
SDL. They were for the software renderer, but they tended not to be
ported to the 2.0 Render API. Those most interested in such a thing
were counting on the promise of that API made in 1.3: It would always
be there, whether your game was 2D or 3D, and you’d always have
access to use it.That promise never materialized, and support for fixed pipeline
OpenGL (required for OpenGL 1.x support, as well as for GLES 1.x) has
a lot to do with the reason why. Basically it’s not practically
possible to push the entire GL state on to a stack once a frame, do
stuff, and then put it all back the way it was. Without that, you’d
have to clearly set in stone what SDL expects when the renderer is
given control, and those expectations would have to be firmly
maintained. Possible, but hard. A few people have tinkered with it,
but nothing done that way could be released into a production
environment.But doing that is a prerequisite for a GUI that can be used anywhere
SDL is used.Forget all that, the mere fact of having multiple backends already
makes it unfeasible. Just a reminder that the renderer API has been
practically frozen since long ago since every time somebody propose an
improvement it never makes its way into the API because people insist
on only implementing it in only one backend. Now imagine if we needed
to keep every backend maintained to support that feature you mention.
The moment you use the renderer API is the moment you give up any
right to control how rendering is done.What could be more feasible is for SDL2 to implement GUI logic, and
then let the program to draw it whatever way it wants. May seem
stupid, but 1) getting the logic right is actually the hardest part
(drawing is easy in comparison), 2) this is a common idiom in mobile
already and 3) SDL is already doing something like this with text
input (SDL handles text input logic, program decides how to draw
whatever text is being entered).
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2014-11-29 7:32 GMT-03:00, T. Joseph Carter :
Support of working features is less difficult than implementation.
But any attempt at implementation is shot down, so there’s no point.
Basically SDL’s renderer should probably be an extension library
since SDL_net and SDL_image are used far more often by developers
than the render API and the render API is functionally crippled
because nobody is allowed to touch it.Joseph
Not having to install a separate library just to get some simple
graphics on screen is nice though (although I guess now everybody will
argue you need to anyway since SDL2 can’t handle file formats).