GUI Elements in Cross-Platform Tool Programming

Quote:

Original post by treeway Im implementing a tool which will run on Linux/MAC/Windows, I've written the 3d component which uses OPENGL/DirectX, CGFX, COLLADA, XFiles, BSP and PhysX. I now want to be able to add menus etc with something along the lines of MFC but plaform independent. I know how to program GUI's in MFC and with JAVA Swing but I find Java is too slow. Are there any alternatives to rolling my own interface using sprites?

wxWidgets would be my first suggestion, followed by QT (if you are GPL-compatible, and don't mind the strange language extensions) - both allow you to embed an OpenGl context in a control, and both run on Windows/Mac/Linux.

If you prefer to render your own UI, CEGUI is about the best in terms of features and active development.

thanks I'll look into your suggestions.

I personally prefer gtkmm. It's a C++ wrapper around the GTK+ library (used in Gnome and Gimp). I like it because it goes very well with C++ programs: It plays well with std::string and STL containers (other libraries require their own types for this), it doesn't require a preprocessor (QT does) and it doesn't use macros (wxWidgets does).

Give it a try.

There is also FLTK(Fast Light Tool Kit) which is as it's name descibe a fast light widget toolkit. It's pretty stable and very easy to intergrate and get up and running. Proably not as powerful as the others.

-ddn

Quote:

Original post by alvaro I like it because it goes very well with C++ programs: It plays well with std::string and STL containers (other libraries require their own types for this), it doesn't require a preprocessor (QT does) and it doesn't use macros (wxWidgets does).

My only reservation would be that I have found GTK+ an absolute pain to distribute on the Mac, and not much better on Windows - that said, it was a while ago, and the process may be more mature by now.

I have made very complex drag and drop Swing GUIs and never found it slow. To be fair, many frameworks like Swing penalize you greatly for poor design. I did find Swing lacking in the MVC department and eventually developed my own framework (adding a little more overhead) without any performance penalty AFAIK. YMMV

I have been searching for a cross platform library for my own project. I had got to the stage I anticipated using wxWidgets but then I found an excellent library that seems to be little known. The library is called JUCE and can be found at http://www.rawmaterialsoftware.com/juce/ Definintely recommend taking a look. It supports Windows/OS X/Linux and is also available as a single amalgamated cpp/h file (like SQLite) making it easy to drop in to a project.

Why not draw your own menus?

It can't be too difficult (I am planning to do it in my own library). You need to draw one rectangle and then to draw some strings. Taht big rectangle is your menubar and strings are "menus". You also have some "bounding rectangle" per string, so that you can test what menu mouse is in. And then you need another big rectangle per menu, in which you draw strings vertically. Those strings are menu items. If you plan to have submenus, then you will probably need some simpler layout manager where you will put some code to calculate where to draw submenu (to left or to right of menu, or to draw it above or below depending on how much space in windows is to left, right, up or down).

You also might want to look at cegui: http://www.cegui.org.uk/wiki/index.php/Main_Page

Mixing native drawing code with opengl/directx is not performance wise (usually) and can be messy to code. It is easier to use gl resp. dx to draw gui to.

Quote:

Original post by joe_bubamara Why not draw your own menus? Mixing native drawing code with opengl/directx is not performance wise (usually) and can be messy to code. It is easier to use gl resp. dx to draw gui to.

If you want to build a full editor, or similar tool, you need a lot of complex GUI widgets, which the native GUI already has. On top of that, the 3D view in most tools is not the only focus, so embedding that in a native control works fine.

Quote:

Original post by swiftcoder Quote: Original post by joe_bubamara Why not draw your own menus? Mixing native drawing code with opengl/directx is not performance wise (usually) and can be messy to code. It is easier to use gl resp. dx to draw gui to. If you want to build a full editor, or similar tool, you need a lot of complex GUI widgets, which the native GUI already has. On top of that, the 3D view in most tools is not the only focus, so embedding that in a native control works fine.

Main difference is well that both his own component and libs like Qt, or wx, has different kind of message pump, and both have one. So he will have to rewrite his own gl component to fitt it into framework code. It is not impossible of course.

Using something like cegui, does not require that; and also it is quite trivial to implement simple menu, button, non-formatted input and check-boxes with sprites. One will anyway have some game gui? So all that can be reused for game gui as well. Using Qt or similar for in-game gui is not very beautifull nor performance wise. So he will anyway need some simple gui, so it is equally well to use it for other purpose as well? That is just my reasoning, and why I am rolling own gui.

Quote:

Original post by joe_bubamara Quote: Original post by swiftcoder Quote: Original post by joe_bubamara Why not draw your own menus? Mixing native drawing code with opengl/directx is not performance wise (usually) and can be messy to code. It is easier to use gl resp. dx to draw gui to. If you want to build a full editor, or similar tool, you need a lot of complex GUI widgets, which the native GUI already has. On top of that, the 3D view in most tools is not the only focus, so embedding that in a native control works fine. Main difference is well that both his own component and libs like Qt, or wx, has different kind of message pump, and both have one. So he will have to rewrite his own gl component to fitt it into framework code. It is not impossible of course.

You are assuming that he is a lousy software architect, and his graphics code handles the message pump. If his program is well designed, then the graphics component wont care (or even know) what the main loop is doing with events.

Quote:

Original post by swiftcoder Quote: Original post by joe_bubamara Quote: Original post by swiftcoder Quote: Original post by joe_bubamara Why not draw your own menus? Mixing native drawing code with opengl/directx is not performance wise (usually) and can be messy to code. It is easier to use gl resp. dx to draw gui to. If you want to build a full editor, or similar tool, you need a lot of complex GUI widgets, which the native GUI already has. On top of that, the 3D view in most tools is not the only focus, so embedding that in a native control works fine. Main difference is well that both his own component and libs like Qt, or wx, has different kind of message pump, and both have one. So he will have to rewrite his own gl component to fitt it into framework code. It is not impossible of course. You are assuming that he is a lousy software architect, and his graphics code handles the message pump. If his program is well designed, then the graphics component wont care (or even know) what the main loop is doing with events.

Why should I assume that :-)? I just assumed that he is trying to make a game and usuall way is to have a non-blocking message pump. I also asumed that he will have some in-game gui, and that he probably can reuse same code, unless he really can not do without advanced widgets, like formatted text input, sliders, scrollbars, calc sheets, tabbed bars and alike. As long as he can do with buttons, menus, simple (non-formatted) text input, checkboxes, radiobuttons and similar, and some simple containers, rolling own gui is not too dificult. Blender is perfect example.

Quote:

Original post by joe_bubamara Blender is perfect example.

Bender's GUI is entirely non-intuitive, and fails to meet the User Interface Guidelines on any of its target platforms. Tools are often aimed at level designers/artists, thus the UI needs to be fairly accessible. In-engine editors are notoriously unfriendly to new users, as well as clunky to use.