Suggestion: native GUI |
Altair Linux
Guest
|
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 http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Suggestion: native GUI |
i8degrees
|
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 http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Suggestion: native GUI |
MrOzBarry
|
To augment Jeff's suggestion, you could also look into berkelium or awesomium - 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:
|
|||||||||||||
|
Suggestion: native GUI |
Altair Linux
Guest
|
Debian Wheezy only have SDL 1.2
2014-11-28 13:31 GMT+01:00 Jeffrey Carpenter:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Suggestion: native GUI |
Joseph Carter
|
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. Joseph On Fri, Nov 28, 2014 at 01:11:43PM +0100, Altair Linux wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Suggestion: native GUI |
Sik
|
2014-11-28 18:19 GMT-03:00, T. Joseph Carter:
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 http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Suggestion: native GUI |
Bill Kelly
Guest
|
Hi,
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 http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Suggestion: native GUI |
Marc
Guest
|
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 :
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Suggestion: native GUI |
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 On Fri, Nov 28, 2014 at 08:42:18PM -0300, Sik the hedgehog wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Suggestion: native GUI |
Sik
|
2014-11-29 7:32 GMT-03:00, T. Joseph Carter:
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). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|