Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenGL Widget Set Recommendations?

Cliff posted more than 11 years ago | from the for-the-coders-among-us dept.

Programming 154

rrwood asks: "I'm starting work on what is more or less an open-source 3D modeling application, and I'd like to make it as cross-platform as possible (Linux, FreeBSD, Windows, MacOS, etc.). OpenGL takes care of the 3D rendering I'm going to need, but I also need some sort of widget set, and I'm looking for advice as to what to use in that regard. I've done my Google homework and have come up with the following, but would like feedback from anyone who has already used any of these, or has recommendations about anything I may have missed. Yes, I know about Blender, and be reassured I am not planning on reinventing that wheel, okay? :-) So, here's what I've found so far. As I said, if anyone can add to this list or share his/her experiences actually working with any of these, that would be greatly appreciated."

"GLUI provides a flexible windowing system and a rich selection of widgets (buttons, checkboxes, radio button sets, spinners, text boxes, arcballs, dividers, packing panels, packing columns, etc.). GLUI's design is very straightforward, and the docs and examples are extremely well done. GLUI is highly portable, since it depends only on OpenGL and Glut.

GLOW is 'a cross-platform object-oriented framework for building interactive applications using OpenGL or similar APIs such as Mesa.' GLOW is basically an elegant C++ wrapper around Glut, providing push buttons, check boxes, radio buttons, scroll bars, sliders, text fields, menus, etc. This is a really nice description of GLOW, including comparisons to GLUI and MUI.

Speaking of MUI, Steve Baker's advice is basically 'just don't.' Instead, Steve recommends PUI, which he wrote. :) Actually, he speaks very highly of GLUI, and does a nice job of pointing out the subtle differences between GLUI and PUI.

PUI is part of PLIB, a rich and vibrant set of libraries for cross-platform game development. This is a wonderful intro to PUI. Go read it right now. Really. PUI itself does all the sorts of stuff I'm looking for, and perhaps more. It looks to be very stable and mature, too.

LibUFO is a C++ widget set for OpenGL, currently in alpha. Features include pluggable look and feel, theme support, and layout manager support. LibUFO can be used with GLUT, SDL or any native GL context, so it is highly portable, too. Except for the fact that this is only alpha code at this point, it looks quite nice.

FOX is a C++ toolkit for developing cross-platform GUI apps. It seems like a fairly standard C++ framework, with built-in OpenGL widgets, too. By all accounts, FOX is quite mature and stable, with a fairly active developer base. FOX supports many OSes, but not, unfortunately, the Mac. And yes, I could easily hack out Mac support myself, but I don't want to do that-- I want to write my app.

FLTK is another cross-platform C++ GUI toolkit with OpenGL support. The advantage of FLTK over FOX is that FLTK supports MacOS X (not 9.x and earlier-- too bad).

DirectFB is a library built on top of a framebuffer device such as the Linux framebuffer or SDL. There seems to be some 3D support in there via DirectFBGL, though the docs say that there is no hardware acceleration support (i.e. Mesa vs OpenGL). The thing that makes DirectFB particularly attractive is the fact that Gtk/Gdk has been ported to it.

SDL and ParaGUI are also an attractive option. SDL is insanely portable, and ParaGUI is a wonderful GUI/widget toolkit that runs on top of SDL. You really need to see the ParaGUI demos running to appreciate how slick it is. The screenshots are nice and all, but they don't do it justice. As well, ParaGUI is really slick in its support for themes, XML, and Python.

PicoGUI was a recent SlashDotting victim. As mentioned at that time, PicoGUI is actually a sophisticated client-server framework, capable of running in a wide variety of environments, including on top of OpenGL. There is plenty of info at the PicoGUI FAQ, including a few comments that suggest it would be a perfectly reasonable choice for what I'm looking at doing. Given the scope of what PicoGUI is trying to achieve, I'm a little nervous that it might be overkill for what I want to do.

Fresco is another client-server framework which some may have previously known as Berlin. Fresco seems very cool, but again, I suspect it is overkill for what I'm doing.

The GUI Toolkit/Framework Page is also an excellent resource for cross-platform development of all stripes.

And the OpenGL Toolkit FAQ is also an excellent resource with special emphasis on OpenGL."

Sorry! There are no comments related to the filter you selected.

first post (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4954262)

first post

Re:first post (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4954294)

And as god intended!

WxWindows (2, Informative)

Anonymous Coward | more than 11 years ago | (#4954274)

wxWindows [] gives you a single, easy-to-use API for writing GUI applications on multiple platforms. Link with the appropriate library for your platform (Windows/Unix/Mac, others coming shortly) and compiler (almost any popular C++ compiler), and your application will adopt the look and feel appropriate to that platform. On top of great GUI functionality, wxWindows gives you: online help, network programming, streams, clipboard and drag and drop, multithreading, image loading and saving in a variety of popular formats, database support, HTML viewing and printing, and much much more.

"Excellent, stable and intuitive API. Very straightforward to learn and easy to port Java, X11 and Win32 code to."
"Thanks heaps for the best piece of software I've ever come across."
"wxWindows 2 has been an absolute dream."
"I've never had an easier porting experience."
"I never thought that cross-platform development could be so easy and simply cool."
"I have used wxWindows in the past very successfully on multiple projects, and think it's the bee's knees. Thanks for everything!"
"wxWindows is jaw dropping amazing. Community support from the mailing list is extraordinary. Are you sure this is free?"
"wxWindows is one of the most magnificent development projects in existence.."

Re:WxWindows (4, Informative)

watzinaneihm (627119) | more than 11 years ago | (#4954351)

Be careful about threading in wxWindows. About 6 months back I had to write a program using wxWindows and the threading gave me some problems.Most of those libraries are being improved AFAIK
Also worry about memory leaks. I am not sure If the code I wrote was leaking it or whether it was wxWindows, but hte programs did leak gallons of memory.
Not that I am an authority on wxWindows, or that it is a bad library, just a warning. Maybe some other readers have had experiences?

Re:memory leaks in WxWindows (1)

VZ (143926) | more than 11 years ago | (#4955003)

[disclaimer: I'm an active member of wx dev team]

If you think you've found a memory leak in wxWindows, please do let us know about it (comp.soft-sys.wxwindows). Remember that if our users don't report the bugs to us, we have much harder time fixing them.

Of course, in my experience, memory leaks in wxWindows are more often than not leaks (or bugs) in the user code but if you're sure your code is ok, please try to report the problem. Posting a bug report won't take much longer than posting to Slashdot (although arguably it's not as much fun).


Re:WxWindows (1)

Unregistered (584479) | more than 11 years ago | (#4955164)

Nice. Does it subscribe to the Apple interface guidelines on it's own or would certain parts need redoing? But for *NIX/Win32 tghis looks interesting. Any thoughts on this vs qt

wxWindows (2, Informative)

Hanji (626246) | more than 11 years ago | (#4954277)

You might want to look into wxWindows [] It's a cross-platform GUI library that works using platforms' native GUIs, so that your app will take on the look of the platform you build it on. It supports OpenGL nicely, and has what is, in my opinion at least, a beautiful, intuitive OO C++ interface.


Anonymous Coward | more than 11 years ago | (#4954292)

No karma whore for you! #@ -1; Refundant @#


Anonymous Coward | more than 11 years ago | (#4954331)

1 minute difference between posts, Moderators abuse the -1 Redundant

No Kidding (0)

Anonymous Coward | more than 11 years ago | (#4954360)

whoever modded that as redundant shouldn't be allowed to moderate...


Anonymous Coward | more than 11 years ago | (#4954404)

Redudndant modderrattes YUO!

Write your own (-1, Offtopic)

anonymous coword (615639) | more than 11 years ago | (#4954288)

In z80 assembly, thats what I was taught.

Additional requirement - Widgets on textures! (4, Interesting)

kbonin (58917) | more than 11 years ago | (#4954309)

I'd throw out an additional requirement for an ideal OpenGL GUI library, one that's lead me to start developing my own (It'll be open source when done.)

It'd be nice if a cross-platform widget/GUI library existed that would allow me to place the GUI's into the environment, by rendering to textures or virtual GUI planes, instead of just as yet another 2d desktop library. Its not TOO much additional work if done from the beginning...

Think of the fun you could have w/ full GUI support in the environment. A 3d embeddable Gecko control, anyone? :) (Wish that code was cleaner...)

Wait (0)

Anonymous Coward | more than 11 years ago | (#4954344)


Re:Additional requirement - Widgets on textures! (1)

jooon (518881) | more than 11 years ago | (#4955147)

A 3d embeddable Gecko control, anyone? :) (Wish that code was cleaner...)

You mean like something taken out of a David Cronenberg film?

libUFO (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4954312)

has been quite useful to us here, check out res-2.jpg

Coin3D offers 3D widgets (2, Informative)

Anonymous Coward | more than 11 years ago | (#4954313)

Coin3D ( is a GPL rendition of the Open Inventor toolkit by SGI. This toolkit is a C++ class heirarchy that overlays OpenGL and is really quite nice. It has rendering and scene manipulation tools like material editors. The toolkit has bindings for Trolltechs Qt, and they are working on one for Gtk. I think they have Motif. I'm pretty sure it works on Lintel and MacOS X. I got working on my Mac with Yellow Dog Linux on it.

Good luck.

Portability (4, Informative)

cbv (221379) | more than 11 years ago | (#4954323)

For your GUI, take a look at GNUstep [] . It supports Linux, the BSDs, Solaris and Windows and is (pretty much) compatible with Cocoa.

For your 3D graphic stuff, take a look at the GNU 3DKit [] .

wxWindows, FLTK (4, Interesting)

g4dget (579145) | more than 11 years ago | (#4954329)

If your needs are modest, you might want to use FLTK. It's simple and you can link with it statically. If you need a full-blown widget set, wxWindows [] is a good choice. Both of them let you embed OpenGL windows inside the GUI. They are not implemented using OpenGL as the graphics layer, however: they use whatever native GUI there is and embedd OpenGL windows.

I would recommend against using widget sets with OpenGL as a graphics layer unless you really need it: OpenGL is less than ideal for that purpose.

Re:wxWindows, FLTK (1)

John Miles (108215) | more than 11 years ago | (#4954347)

I would recommend against using widget sets with OpenGL as a graphics layer unless you really need it: OpenGL is less than ideal for that purpose.

Just curious: why do you say that?

Re:wxWindows, FLTK (3, Insightful)

JFMulder (59706) | more than 11 years ago | (#4954473)

I guess it would have to do with the fact that 99% of the time you work in double buffering mode. So a click on a button in the interface will mean you'll have to do an entire redraw of the window, and that is really slow. You have do redrawyour whole desktop, than flip buffers. One cool hack tought would be to always write your UI modifications on the front buffer, but it would be hell to keep track of everything that is under the pop ups. OS widgets are fast : the changes when you interact with a widget are local and don't demand a whole screen redraw, since they work in single buffer environment.

Re:wxWindows, FLTK (2)

g4dget (579145) | more than 11 years ago | (#4955141)

OpenGL has lots of overhead, it's not supported on many devices/screens, it doesn't address many important functions like window management and internationalization, and it doesn't easily give you as much control at the pixel level as 2D graphics APIs designed for user interfaces. Probably as a consequence, I have yet to see an OpenGL-based widget set with the same functionality and quality as wxWindows or even FLTK.

Re:wxWindows, FLTK (4, Interesting)

ikoleverhate (607286) | more than 11 years ago | (#4954427)

Worth pointing out that FLTK not only lets you have OpenGL windows inside it's windows, but that ALL it's widgets' draw functions can contain OpenGL code (whether a specific OpenGL widget or not). This means you can have lit and textured buttons for example, and have the mouse pointer as a light source. ;)

I'm not sure if any of the others do the same as I have never used them.

Re:wxWindows, FLTK (0)

Anonymous Coward | more than 11 years ago | (#4954442)

in s0cvIET RUssIas, FLTK wsxWINdows YUO!

My favorite wdget (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4954330)


Open Source? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4954343)

I'm starting work on what is more or less an open-source 3D modeling application
If it it more than open source, how much more? If it is less, how much less?

Re:Open Source? (0)

Anonymous Coward | more than 11 years ago | (#4954585)

Fucking moderators. I don't see how the parent is off topic.

Defanetley SDL (2, Insightful)

anonymous coword (615639) | more than 11 years ago | (#4954345)

It is the best XPlatform library out there for stuff like this! It is supported extensiveley by the community, and it is commerically used as well, you would be best off with that, because its a platform that most people have heard of, not to mention better libary compatibliilty!

Re:Defanetley SDL (0)

Anonymous Coward | more than 11 years ago | (#4954424)

worest speeling EVAR!

Re:Defanetley SDL (1)

azcoffeehabit (533327) | more than 11 years ago | (#4954512)

Yeah SDL is one of the best API's around. It has everything you need to make cross platform OpenGL. Input, window management, music, multi-threading, 2D & 3D capabilities.. It has it all :)

There are some books about SDL, but the really good stuff can be found in the online documentation off of the web site. SDL also has really good community support. I have had nothing but good experiences with SDL and I would recommend it to everyone.

Re:Defanetley SDL (0)

Anonymous Coward | more than 11 years ago | (#4954845)

I object to the claims of SDL being supported "extensiveley" by the community. Nothing has been done with its Documentation Project for at least two years. Other than book$, there's not much else to go on.

Actually (2, Insightful)

Anonymous Coward | more than 11 years ago | (#4954355)

You ARE reinventing the wheel. But don't let that stop you, you may just come up with a better/cheaper/faster Wheel.

Consider (0)

Anonymous Coward | more than 11 years ago | (#4954824)

In Soviet Russia, the wheel reinvents you!

Mozilla XUL (1)

mgarriss (615232) | more than 11 years ago | (#4954357)

Mozilla has a nice GUI building XML language called XUL. It's cross platform has support for skins and themes and such.

Re:Mozilla XUL (0)

Anonymous Coward | more than 11 years ago | (#4954402)

except that it can't be used within OpenGL unless you something we don't

PUI (2)

Micah (278) | more than 11 years ago | (#4954363)

I haven't personally used it, but FlightGear [] uses PUI. It looks slick, and FG is probably one of the most advanced Open Source projects ever.

Re:PUI (0)

Anonymous Coward | more than 11 years ago | (#4954576)

Wow! Flightgear really looks slick! Judging from the screenshots at's main page, it should be up to the standards of a 1998 flight simulator in only a few short years!

Objectively, compared to retail box flight sims, flight gear is very little very late.

However, compared to other open source projects, it is a testament to hard work, product-focusedness, and the passion and smarts of its creators.

The previous two sentences converge at the major problem with OSS as it exists today.

SDL is OK (2, Informative)

Saiai Hakutyoutani (599875) | more than 11 years ago | (#4954371)

For a layer to put between OpenGL and your OS of choice, SDL is more than OK. It even works on PlayStation 2! Don't know if OpenGL will run on a PS2 though =P

SDL doesn't have a GUI actually, but there are several GUIs made FOR SDL by other people.

Good luck!

Qt (3, Informative)

Sesse (5616) | more than 11 years ago | (#4954373)

You definitely forgot Qt [] . The only downside is that it's commercial on Win32 (unless you're running MSVC6), apart from that it does its job very well, and has a very reasonable OpenGL widget.

As for wxWindows (which others have suggested), I tried it some time ago and I think it truly sucked. Hopefully it has improved since then :-)

/* Steinar */

Re:Qt (0)

Anonymous Coward | more than 11 years ago | (#4954423)

All of thees posts about wxWindows, QT, XUL, etc. don't understand. The poster wasn't asking about standard UI toolkits, he wants one that will work within OpenGL

Re:Qt (1)

Sesse (5616) | more than 11 years ago | (#4954430)

In that case, several of his own suggestions seem to be wrong in exactly the same aspect. :-)

/* Steinar */

Re:Qt (1)

Unregistered (584479) | more than 11 years ago | (#4955173)

I have been using qt for my development. Since i don't have a windoze compiler i haven't used it cross platform, but signals/slots are great and designer is a well done tool but not necessary.

blah (0)

Anonymous Coward | more than 11 years ago | (#4954399)


Pick one platform and fuck the rest. Windows users does NOT like using other widget sets than the deafult Win32. I would never use your program over a native win32 program if it meant it came bundled with 1MB+ of dll files to provide GUI support. Why? well.. it reminds me of something called VISUAL BASIC!!!

Re:blah (0)

Anonymous Coward | more than 11 years ago | (#4954703)

Yes, in this day and age, the future of computing is all about keeping file sizes small. With _200 gigabyte_ hard drives costing less than $300 and increasingly ubiquitous fast internet connections, the emphasis needs to be, on, for example, creating tiny ELF binaries.

What open source does not need, if it wants to beat microsoft, is an environment that allows non-31337 h4X0r programmers to devleop business applications quickly. No, developing such tools is a surefire recipe for mainstream disaster. Let's instead mock the users of such tools until they accept our whining to the extent that { Perl | Python | some other nonsense } actually does the same thing.

Deck the halls with Cliff's balls (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4954437)

fa la la la la la la la suck my dick
Merry Fishmas you /. fuckers

GTK? (2, Informative)

DavidTurner (614097) | more than 11 years ago | (#4954439)

Another big one which you've missed is the GTK. It has a glarea module for OpenGL drawing areas, and has the advantage of a very strong design. On the other hand, since your focus is on building an OpenGL-based system, why bother with the overhead of a widget set at all? Don't reject the idea out of hand. Not having a pre-designed widget set will force you to think carefully about your interface. In my opinion, this is the major shortcoming of most commercial modelling systems - a counter-intuitive UI.

Re:GTK? (0)

Anonymous Coward | more than 11 years ago | (#4954603)

has the advantage of a very strong design

Huh? You mean that uglier-than-sin, fucked-up shit-for-design, retched, vomitous excuse for a GUI called GTK? You're joking right?

Cross platform widgets are BAD (5, Interesting)

JFMulder (59706) | more than 11 years ago | (#4954446)

Of course, from a technological angle, cross-platform widgets (we'll call them CPW from now on) are an elegant solution. Design your UI once, and you're done. This seem like A Good Thing.

The problem with CPW is that it gives more time to the user to adapt to your widgets. Of course, one can argue that once you can use the widgets in one environment, you can use them everywhere. That is true. The problem is that not all your users are as good with computers as you are, and it may put an extra strain on the user to learn between the basics of your system and the host OS. How do you drag and drop? How do you move around windows? What happens when you double click on the top? Does it maximise? Does it roll up just to show the title bar?

Take a clue from the major players in the industry. From what I've heard, Adobe updated PhotoShop to give it the Mac OS X look and feel by using it's native widgets. Many companies are now making wrappers around existing library calls, instead of making widgets. That way you have a unified API for all your supported platforms to design your UI on, but also have the advantage of keeping the usual behaviour and look and feel of an application.

Sadly, I don't know of any public library that accomplishes this. But I'm sure that if you looked around enough, you should be able to find a few.

Good luck!

Re:Cross platform widgets are BAD (4, Informative)

Hanji (626246) | more than 11 years ago | (#4954606)

wxWindows []
It does exactly what you describe. It provides a single API, that, when linked with the appropriate platform's libs, creates the GUI using that platforms GUI.

Re:Cross platform widgets are BAD (2, Informative)

SparhawkA (608965) | more than 11 years ago | (#4954619)

While this is true for cross-platform applications which operate identically in each environment, those that assume the look and feel of the target system can greatly reduce the problem. I highly recommend wxWindows [] as a candidate API for your project as it automatically will make adjustments for you. The documentation is also quite good and there is a solid community of developers from which to learn. (I used it this last semester on an assignment - it's awesome.)

If you absolutely need your widgets to be a part of the 3D environment... you're going to have to keep looking.

Good luck!

Re:Cross platform widgets are BAD (0)

Anonymous Coward | more than 11 years ago | (#4954675)

How do you drag and drop? How do you move around windows? What happens when you double click on the top? Does it maximise? Does it roll up just to show the title bar?

This is mostly misinformed. I don't know about the first one, but the rest are not dependent on widgets. Windows don't get control of their own titlebar, for instance, in X or MS Windows. Moving around windows is also not dependent on widgets - if you move by alt-tab, for instance, whatever manages your windows catches alt-tab before it gets sent to your app.

Re:Cross platform widgets are BAD (0)

Spellbinder (615834) | more than 11 years ago | (#4954766)

because of this there is something called windows manager..
think about how annoying it would be if you double click on one windows and it maximises then same on the next and it minimizes :p
he got a point but the wrong examples =((
in windows there is a lot of standardisation in applications layout
the save icon always looks same, undo is in the second menu from left and so on =)
'not power users' dont even know how the function they are looking for is called, they just know where it should be...
if they have to search anything you annoy 'em and they will stop using your application

Re:Cross platform widgets are BAD (1)

kaphka (50736) | more than 11 years ago | (#4955079)

Windows don't get control of their own titlebar, for instance, in X or MS Windows. Moving around windows is also not dependent on widgets - if you move by alt-tab, for instance, whatever manages your windows catches alt-tab before it gets sent to your app.
You're right about alt-tab, but that's an exception. Badly written Windows programs can take control of just about everything else. To break the title bar, all they have to do is create an undecorated window and draw the title themselves.

JFMulder hit the nail right on the head, though. When developers decide to use their own widgets instead of those provided by the platform (usually so they can offer a choice of l33t "skins",) they're very unlikely to make them complete, especially when it comes to behaviors that are fairly obscure. Sure, it's not fair to expect a programmer to know all the subtleties of every environment in which his program might run -- that's what abstraction is for. Is it really worth it to throw away that advantage, just so your program can have a 3d-accelerated GUI?

Re:Cross platform widgets are BAD(Yeah right!!!) (2, Informative)

master_p (608214) | more than 11 years ago | (#4954879)

Don't tell me you don't know Qt [] !!! it's the best, totally cross platform, and definitely preserving the look and feel of the host O/S. And it is not only a GUI toolkit, it has everything:

native look and feel

database support

OpenGL support

XML through SAX and DOM implementations

true componentatization through the signal-and-slot mechanism

theme support

app settings and DLL transparent handling

lots of container templates which are easy to use

full visual environment intergrated nicely with various IDEs

source code 100% compatibility from platform to platform

multithreading and synchronization abstraction using the native O/S

networking abstraction using the native O/S

regular expression handling

HTML support

internationalization support with the easiest handling of UTF-8, ASCII and UNICODE formats

some of the best widget sets with full geometry management

follows C++ logic, unlike other toolkits like MFC or wxWindows

Its only downside is that you have to pay for it, but it is definitely worth it, because it is simply the best toolkit out there!!!

Having just built and deployed a SDL app (2)

codepunk (167897) | more than 11 years ago | (#4954450)

SDL is the way to go, easy easy easy....

Re:Having just built and deployed a SDL app (1)

Hanji (626246) | more than 11 years ago | (#4954639)

SDL is easy, yes, but for a GUI app it's probably not the best choice. There is ParaGUI, but something that implements controls using the platforms native libs is probably better, and I've had a lot of problems getting ParaGUI working.

I second that, with caveats (2, Insightful)

It'sVersusItsGuy (599536) | more than 11 years ago | (#4954680)

I agree wholeheartedly that SDL is an awesome API. I'm using it to develop a cross-platform game with OpenGL as the graphics engine. (SDL is used for the startup, events, and sound). However, SDL doesn't provide any set of widgets by default. You'll have to use someone else's widget set or develop your own, and just because a widget set is SDL doesn't mean it will mesh cleanly with your OpenGL context.

That said, since I developed my own 2D sprite library in C++ on top of OpenGL I'm writing my own set of widgets that will leverage the sprite engine. Basically this comes down to building my own "responder" chain, keeping track of which item has the focus, testing clicks inside my widgets (which are sprites in most cases), etc.

There are obvious advantages to building your own widgets, such as the aforementioned leveraging of your graphics engine to create a distinctive interface. And there are obvious disadvantages, such as the added development time required to put the whole thing together. Either way you will learn a lot about how (not) to implement a GUI.

For most games you can get away with a very minimal GUI, basically testing for clicks inside rectangles, but if you need to do more, such as building a level editor, it's nice to have all the standard items like menus, checkboxes, and file dialogs.

Think why Not what. (2)

crovira (10242) | more than 11 years ago | (#4954452)

Why are people using GUIs?

They basically want to enter textual (single or multi-line text, numbers, dates, currency [specie and quantity]) or spacial (2D or 3D coordinate system point[s]) data
to navigate relationships between objects. Think 0|1:0|1|N relationships (select from a list which may be a simple or a compound presentation of text, graphical or mixed views of objects.

Radio Buttons, push butons and other 'screen candy' should be switchable without the developer being involved. This has been available in Smalltalk (Widgets) since '91. Extend don't re-invent.

Let the user theme the presentations. Let the coder concentrate on the objects and the relationships, what's important.

And set up your API's on data streams so that you NEVER waste a cycle pumping data one pixel beyond what's visible. (There is NOTHING as disgusting as waiting on a GUI to fill a window that only shows a few Ks of data with a the complete contents of a multi-megabyte file.)

Duh!!! (2, Funny)

decep (137319) | more than 11 years ago | (#4954454)

http://www.googl... damn... he's already been there.

FastGraph (1)

andr0meda (167375) | more than 11 years ago | (#4954469)

Slightly offtopic, since it's not about widgets, but I thought I'd mention it anyway:

There used to be a graphics library called FastGraph by infamous Ted gruber Software, and surprisingly it is still around [] (It actually predates borlands BGI driver, if people still remember that one). I used it 10 years ago to take my first feeble steps in graphics in c++, and designed my own widgets and basicly invented my own buttons/frames/menus system all by myself, and to this day the framework of that code is still usuable. Anyway, it's not a recommendation or anything, I would never used it at this time.

BGI? nooooooo! (2)

CoolVibe (11466) | more than 11 years ago | (#4954565)

Geez, BGI sucked so much, I wrote my own graphics routines in assembler those days, because BGI *sucked* *so* *fucking* *much*. Yeah I do remember fastgraph though. But my asm routines were faster and did what I wanted then to do. But of course if I would have wanted portability back then I'd definately use it.

prototyping is important (2, Interesting)

FranTaylor (164577) | more than 11 years ago | (#4954474)

I've written some very nice 3-D apps using OpenInventor and Motif. OpenInventor is excellent for prototyping 3-D apps. I worked on a simulator project where we used OpenInventor, Motif and Scheme. We had Scheme bindings for everything. Since Scheme is interpreted, we could make changes "on-the-fly" without recompiling or even restarting the program.

Prototyping tools are different from production tools. It's okay (even preferable) to prototype in one environment, and write the deliverable in another. 3-D design is not cut-and dried, so you will spend a lot of time messing with how things look. This is much easier in an interpreted world than in one that requires compiling and linking of big C++ executables every time you decide that the red cube is a little too big.

Re:prototyping is important (1)

JudgeJackson (167835) | more than 11 years ago | (#4954918)

Lisp is nice in this regard... develop in a real-time interpreted environment and then compile it all to native code when you release it.

Check out ClanLib (2)

drivers (45076) | more than 11 years ago | (#4954488)

It has a section of the API called ClanGUI as well as ClanGL and ClanGUI works with ClanGL. However this project is often buggy and incomplete. Might be worth looking at though if you don't mind submitting bug reports (or patches for that matter!). I use ClanLib and ClanGL in a game I'm working on.

OGRE is another option (1)

mcoletti (367) | more than 11 years ago | (#4954499)

OGRE [] is an OpenGL (and alternatively DirectX) scenegraph library that's still in development, but may already provide useful functionality. Think of this as a next generation SGI Open Inventor. I've used Open Inventor and have recently switched to OGRE since OI shows it's pre-ISO C++ standard roots. (And pre-Scott Meyers. And pre-Gang of Four Design Patterns.)

Re:OGRE is another option (0)

Anonymous Coward | more than 11 years ago | (#4954903)

Gee. Coding by celebrity.

SWT (1)

j4im (133469) | more than 11 years ago | (#4954509)

I cast a vote for SWT. That's the toolkit developed by IBM et. al. for the eclipse [] project. It allows you to write your GUI in Java, with native bindings on a variety of platforms for a conventional look and feel (GTK or Motif on Linux/Unix; Windows and Mac too). I've used it a bit and found it very functional and pleasant to code with. It's also very straightforward to yank the SWT out of the eclipse package, and the whole thing is under an LGPL-like license (CPL), as far as I can tell.

Re:SWT (0)

Anonymous Coward | more than 11 years ago | (#4954554)

And if you use gcj you can compile down to native code, deploy without a proprietary JVM, and use the wonderful CNI native code interface to C++. Nirvana.

Re:SWT (1)

AG (3175) | more than 11 years ago | (#4954589)

Even easier.... Grab
[] sn apshot.tar.gz

and just configure/make to get with gcj.

Check out how Blender3d does it (1)

quinticent (230886) | more than 11 years ago | (#4954536)

They use an all OpenGL widget set. I was amazed to see that you could scale the widgets like any OpenGL object.

GLUI Rocks! (1)

shidda (535234) | more than 11 years ago | (#4954542)

I have used GLUI for my 3rd year computer science dissertation. I used it for a cross platform GUI interface. I found GLUI to be excellent for my needs. It looks very nice it is very easy to achieve what you need in very short c++ code.

The fact that GLUI is built on top of glut means that it is as cross platform as glut itself. I have not used any of the other toolkits but I would definitely use this toolkit again.

If you are intrested in what i used it for I have a short description of my dissertation (with screenshots) at : []

Hope this helps.

Steer clear of... (0)

Anonymous Coward | more than 11 years ago | (#4954544)

Anything that closely resembles the ugly abortion-on-a-stick called GTK

Create a native GUI (0)

Anonymous Coward | more than 11 years ago | (#4954546)

Using traditional menus and methods do not work for this kind of app. Please ignore the /. robots.
3D animation & modeling applications require more interaction than almost any other type. They have many features that need to be exposed yet organized.
I recommend creating your own GUI and rendering it in the OpenGL context with the rest of the app. You're already going to use the mouse in an OpenGL context, so you shouldn't have too manny issues using that space.
You can write code for input, doc handling, and creating the OpenGL context natively...

People won't use your program because its portable (0)

Anonymous Coward | more than 11 years ago | (#4954551)

Uh, this might seem, at first sight, to be a fairly stupid recommendation, and in fact, it may turn out to be a stupid recommendation at second and third sights as well, but anyway, I suggest that instead of looking for an insanely portable GUI solution, you just drop the cross-platform requirement or at least pare it down to perhaps 2 platforms.

You'll be working on your app for _years_ and nobody can predict the future. Besides, you want to focus on making your app be the best 3D modeling environment it can be; not the best cross-platform 3D modeling environment.

When your app becomes good enough, people will want to port it no matter what. At that point, you'll have _specialists_ working on integrating your app with their favorite OS, and all your dull lowest-common-denominator code will be thrown out anyway.

So pick the toolkit that results in the best 3D modeler for your platform and perhaps one other platform. Then just use common sense: i.e. don't rely on side-effects that only occur in a very particular batch of stepping 3 Pentium II's, but don't abstract your design into oblivion either.

Anything above and beyond that, at this early stage, is just a flight of fancy.

Re:People won't use your program because its porta (1)

Shaleh (1050) | more than 11 years ago | (#4954726)

actually, Blender required very little porting effort because its GUI was written in openGL. All they had to do was deal with was reading and writing data basically.

Of course, you make it work on one platform and then start testing elsewhere. That is simple 1st year CS. But you must design from the begining to be cross platform.

Personally, I would love to hear his secret, evil scheme is to write a better Blender front end. The renderer is so damn sweet and fast.

Re:People won't use your program because its porta (0)

Anonymous Coward | more than 11 years ago | (#4954797)

Of course, you make it work on one platform and then start testing elsewhere.

But that wasn't his requirement.

That is simple 1st year CS. But you must design from the begining to be cross platform.

Yes, well. I suppose that's also 1st year CS. What is your point?

Since you actually ARE reinventing the wheel... (2)

Qbertino (265505) | more than 11 years ago | (#4954552) might as well use fresco since it's the only kit you mentioned that for once isn't something like ten years behind (and looking like someone shat on the screen) but more like 5 years ahead of time. When you're app is 1.0 stable and beyond both you're app and fresco will be finished and if all turns out well both projects will have something to brag about.
Bottom line: Use fresco or join the Blender project - they've got their own kit fitted extra for the programm and therefore it runs on more or less everything that runs on electricity.

GLUI (1)

davechen (247143) | more than 11 years ago | (#4954562)

I've used GLUI for a simple modeling program, and I like it. It's simple and easy to use. It's great for grad student/research applications.

On the other hand, it's only really made for simple, toy-ish programs. You couldn't really use it for a complicated or professional program interface.

Also I don't know how much Paul Rademacher (the author) is doing as far as updating/maintaining the code these days. Don't ask him about sliders! (There ain't none)

SDL and PyGame (1)

monopole (44023) | more than 11 years ago | (#4954573)

Being the lead programmer on a 3D monitor, I'd say that SDL is the way to go. It not only provdes widgets but also an excellent game controller interface.
Check out the Python wrapping of SDL PyGame

Re:SDL and PyGame (0)

Anonymous Coward | more than 11 years ago | (#4954885)

Neither SDL or PyGame actually have built-in user interface libraries. You could look at PyUI [] which is a user interface library written in python. It was specifically written to draw on hardware accelerated 3D surfaces - primarily for video games.

Check out the VGL (2)

IamTheRealMike (537420) | more than 11 years ago | (#4954579)

We made the VGL as a skinnable OpenGL widget toolkit as part of the Pythian Project [] , and if you're OK with Delphi it's a fine piece of work (even if I do say so myself :p). Looks good, and very high performance (as it was built for a 3D game). It's been through quite a few generations too.

Obviously if you're not coding in Delphi/Kylix, then it's not much use.

cross platform apps (0)

Anonymous Coward | more than 11 years ago | (#4954597)

If you have the time and are really interested in making your programs work well within each platform (this means following the respective human interface guidlines etc.), I'd advise you to split your application backend from the gui, and use each platform's independent widget set. Hence on windows use MFC, linux use gtk or qt and on mac carbon or cocoa. Cross platform apps tend to be the worst apps to use from a usability standpoint, because they are usually designed for one platform (usually windows) and then poorly ported to others. By explicitly designing the gui for each individual platform you will ensure that your app fits in well with each of them, improving general usability for all users on all platforms.

Togl (also check out ayam3d) (3, Interesting)

BLAG-blast (302533) | more than 11 years ago | (#4954605)


You might want to take a look at Togl []

It's a Tcl/Tk widget, it's pretty friendly and cross platform. There are a couple of 3D modellers using Togl. One of them is called Ayam3d [] (it's kind of like Maya but not, it's also open source). AC3D [] is the other modeller I know using Togl, and it's shareware.

GTK+ with gtkglarea (1, Informative)

Anonymous Coward | more than 11 years ago | (#4954612)

I've been doing exactly this and I've been happy using GTK+ and gtkglarea widgtets to create OpenGL Drawing areas.

It works perfectly OK on any Unix System and also in Win32.

I wrote several CAD/CAM applications for Linux [] using this combination and the port to Windows took only two afternoons.

It was just a question of downloading all the stuff for win32 and I only had to correct some syntax problemas and change some header files in VC++ (some IFDEFs).

I also had one more problem with transient windows, because sometimes the dialog windows would move to the back of the main window and get invisible, but I solved that with a IFDEF _WIN32 and a call to a native WIN32 API function

Even the internationalization stuff works in WIN32.

In this process I always try to use only GTK+ widgets and avoid using Gnome stuff.

On the other hand, the user interface builder glade generates perfectly portable code.

I'm confused. (3, Insightful)

NFW (560362) | more than 11 years ago | (#4954629)

Do you want a GUI toolkit that will let you put windows and dialog boxes and such inside your GL render context, or... Do you want a GUI toolkit that will draw windows and dialog boxes and such on the destop, and which includes support for windows that host GL render contexts?

U the same dude? (1)

ixxologic (594215) | more than 11 years ago | (#4954691)

U the same dude that a while ago asked for input on making a full 3d software suite? If so.. heh when u getting a website up? need somewhere I can go and follow updates.. i/o

Use FLTK (2)

stevarooski (121971) | more than 11 years ago | (#4954760)

Although I'm not sure if any cross-platform windowing package is going to be robust and stable enough for your needs, were I you I'd take a *serious* look at FLTK and FLUID.

The main reason for this is that it sounds like your project will consist more or less of a UI wrapped around a rendering engine. It is really, really easy to use FLTK to create quick GUIs to work with an existing codebase. As an example, all of the skeleton code we've developed and distributed while teaching graphics courses to undergraduates uses this package; its easy for the students to build on, lots of documentation exists, it has a lot of prebuilt functionality, and its pretty flexible. Since the focus is on *graphics* instead of the *applications*, FLTK fit perfectly for what we needed windowing-wise. And yeah, those who want to work on their projects under linux or OS X can do so without a whole lot of fuss.

Just $.02 from someone who's administered projects that are along the lines of what you're doing (on a much smaller scale). Good luck, looking forward to seeing your work! :)

java (0)

Anonymous Coward | more than 11 years ago | (#4954780)


TK/TCL, Visual TCL (2)

phrostie (121428) | more than 11 years ago | (#4954790)

most of my favorite 3D applications use TK/TCL.
Ayam3d and AC3D are both fast and light. they run well even on older hardware(i've tested this time and time again.

Also, someone else pointed out Coin3D. i've always hoped that someone would do something with it. it's just too cool.

QT? (1, Redundant)

punkball (240859) | more than 11 years ago | (#4954858)

I'm not an expert in gui programming, and certainly not an expert in any sort of modeling programming, but I was under the impression QT was cross-platform. Osx should have no problem given its unix roots (I can't confirm though), and windows and the various unix's already support it. Could QT work for this guy? It's certainly a very nice looking widget set too!

PyUI OpenGL User Interface (0)

Anonymous Coward | more than 11 years ago | (#4954871)

Pyui is a user interface library written entirely in the high-level language python. It is targeted primarily as a user interface for games and has a modular rendering interface that can use multiple backends such as OpenGL, SDL or Direct3D
From the PyUI homepage [] . If you are using python or could switch to python, PyUI is light-weight, easy to use and has a surprisingly large amount of functionality.

Use GTK+ 2.x (3, Informative)

MrMeanie (145643) | more than 11 years ago | (#4954878)

I have done some OpenGL work with GTK+.
GTK+ does not support OpenGL out of the box, so to speak, but you can get a package called gtkglarea which adds an OpenGL widget.
If you use GTK+ v1.2, then gtkglarea v1.2.x packages are easy to find and come with many distros (e.g. Redhat).
However, I would recommend that you use GTK+ 2.x, since you are coding a new application, and GTK+ 2.x is much improved. There is no *official* version of gtkglarea for GTK+ 2.0 though. HOWEVER, you can get gtkglarea v1.99.0. Look on I think.

Gnome ftp site []
Gnome ftp mirror []

GTK+'s main advantages are its maturity, its solid design, and its comprehensive selection of widgets. If your application is going to reach an appreciable size, then you will want a good widget set like GTK+.

As a C++ programmer, I find GTK+'s reliance on vanilla C to be a little irritating, however, you can gtk GTK-- which is a C++ wrapper for it. I prefer to use GTK+ directly though, so I interface my C++ code with GTK+ by using static member functions for callbacks.

Hope that helps

Mr. Meanie

I use Qt and the QGLWidget (3, Informative)

MrDog (307202) | more than 11 years ago | (#4954991)

For my scientific visualization project, I use Qt and its QGLWidget for OpenGL vis. It features nice communication to other widgets, easy mouse event interception, and you can share display lists across multiple views. If you intend your app to be free, then they cost you nothing. I have used wxWindows and GTK before, and Qt is vastly superior in my opinion.

Who needs widgets? (2)

Comrade Pikachu (467844) | more than 11 years ago | (#4955016)

Most people using Maya or any 3D modeling application for anything other than dabbling would rather not waste time clicking on buttons. 3D modeling workflow is such that the modeler needs to spend all his time focusing on the model, rather than stopping to hunt-and-peck through menus or to click on some icon that does nothing but waste screen space 99% of the time. Maya uses marking menus to speed up workflow, and all professional 3D apps use keyboard shortcuts for the same reason.

If you really want to be innovative, you will do away with widgets entirely. Oh, wait, it's already been done [] .

wxWindows (0, Redundant)

b1ng0 (7449) | more than 11 years ago | (#4955026)

Take a look at wxWindows [] . It should fit your needs well.

QT (0)

Anonymous Coward | more than 11 years ago | (#4955059)

Qt is the best x-plattform toolkit.

You should also take a look at KPovmodeler.

Experience with OpenGL widget sets (2)

Animats (122034) | more than 11 years ago | (#4955127)

I've been down this road, with some frustration. The basic idea is sound - OpenGL with any 3D graphics board is fast enough today that you can do your 2D work through the 3D engine.

GLOW is a nicely designed widget set, built on top of OpenGL. Written at Caltech. It uses GLUT, which has some problems with multiple windows.

GLUI has some nice widgets, but is badly designed internally - you can't add new widgets without modifying existing code.

GLUT is a big problem. It's widely used, but it's SGI abandonware, with a wierd license that doesn't let you distribute modified versions. So you're stuck with some annoying bugs. To get around this, some people wrote FreeGLUT, put it on SourceForge, and it's in good shape and maintained.

Another vote for wxWindows (1)

dcuny (613699) | more than 11 years ago | (#4955138)

You've already read a ton of people telling how nice wxWindows is to use. It's all true.

I've written a small Basic interpreter [] that uses the wxWindows (unfortunately, too slow to do any real 3D stuff with) and found that it was dead easy to get OpenGL to work with wxWindows.

Basically, you just have to declare a wxGLCanvas and you've got a nice canvas for drawing on. It's nicely integrated into the wx scheme of things - it generates and responds to the same events that a normal wxWindow does.

As people pointed out, you end up with native widgets (use wxSizers to make the layout portable), and wxWindows supports just about every compiler under the sun, which is nice for those of us without infinite budgets.

Plus, there's an excellent group of people on the mailing lists if you get stuck.

Modularity (1)

Unregistered (584479) | more than 11 years ago | (#4955208)

You may want to look in to first creating a giu-less app and then writing a separate gui for it (like mplayer and mldonkey among others). This may make porting adn keeping with interface guidelines easier, in addition others could write the gui (if you let them) which would make your product more enticing.

FLTK (2)

captaineo (87164) | more than 11 years ago | (#4955221)

I can give a good recommendation for FLTK. It is a solid, mature toolkit, and yet remains simple to understand and use. FLTK widgets are written in native 2D code (X11/GDI/etc) for speed, but it is very easy to add OpenGL where necessary. FLTK is good for graphics apps because it understands the special needs of programs where a GUI update is not computationally cheap. (unlike other toolkits, it gives you very detailed control over the event loop if you want it...)

Although FLTK's default widget appearance looks dated, it resembles the SGI inteface that people have come to associate with high-end graphics programs. (virtually no high-end graphics software uses the native widgets on any platform, perhaps because native widgets tend not to offer the kinds of things you need - like good color pickers, configurable slider bars, etc)

Just about the only drawback to FLTK is that the API is C++-only, and it's tied strongly into a C++ "one owner" memory management model, which makes it difficult to use from any other language. (however FLTK is simple and well-designed C++, not like the haphazard hodgepodge of classes and poor event systems in many lesser C++ APIs)...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?