Holy crap! I too am working on one for uni, although mine was just meant to be very lightweight, so I didn't have to worry about my Real-Time Rendering course when it came from going from Windows to Linux. I've got a very flexible event-handling system up and running, windows and basic controls buttons working. I wanted to make it a pretty interface, like OSX, but cross-platform.

I'm going to go read your journal now.


However, I'll say this: If you design it like Java, I'll come to your house, strangle you in your sleep, and then urinate in each of your eyeballs. It will not be pretty.

Edit: I see you meant for DX/OGL - mine's for OSes. Still, we can talk about design, right?

I did a GUI system a few months ago. They're quite interesting as they basics are pretty much well known, but it's still really hard to get a good overall system. Some screenshots of my GUI system in my journal.

IMHO the most important thing initially is to decide on what you're actually going to use it for, and in particular whether it needs to be an 'arcade-y' GUI or a 'windows' GUI. In other words, do you want it for a game like Quake (where you only really need buttons, images and some stuff for an options screen) or for a game like WoW where you have lots of draggable windows, and complicated controls.

The 'arcade' GUI doesn't need lots of the fancier features - no layout managers, no draggable windows and a much simpler set of widgets. On the other hand it must be highly visually customisable, as every menu tends to be skinned differently. You also tend to want lots of feedback - button highlight, press and click animations/sound, etc.

The 'windows' GUI is more spartan in looks but needs to be much more flexible in terms of widgets. Plus you need to deal with draggable windows, resizing windows, multiple popups and modal popups. And possible make it resolution independant too rather than fixed res. On the plus side skinning is easier, as it's usually more restricted to "set background colour", "draw border style", in an attempt to keep the whole thing looking consistant.

Personally I'd say pick one and stick with it. Trying to do both tends to mean you end up doing a windows-y GUI, which can be totally the wrong feel for a game that needs simpler menus.

In my case I went for arcade-y; which means I'm aiming for menus that are really quick and easy to create, easy to layout, and easy to add in custom widgets and visual styles for each control. The core does little more than collecting input, generating events and dispatching them to the controls. Theres a method for user created controls to be added, and user created 'styles' which register which widgets they're capable of drawing so they can be used.

One neat touch is the in-game layout editor. I can actually position, resize and reskin the controls while the game is running so I get WYSIWYG. During development this layout is saved and loaded everytime a menu is closed/opened, for the final game it'll just load the layout and the editing will be disabled.

Our GUI system (at work) is based on a lazy invalidation method.

Every property (and I mean EVERY property) of the GUI components is observable, and can be set to subscribe to other observable properties.

The entire GUI is described using XML, and in the end, property values come from static XML values. However, the XML data that the GUI derives from is also observable, so when the XML file changes, the GUI re-layouts itself (adding/removing components as appropriate).

The data flow does allow for simple formulas, so the "width" of a text control might be set as the "width" of its parent container minus 10, and the "left" of that control might be set to 5, to get some borders. There are also layout controls that take width/height as input, and publish various sub-control properties as output; children will then bind to these to get the appropriate layout behavior.

It is really powerful to have a fully data driven, fully reactive data flow graph for your entire GUI system (this includes the values within the controls, too, like the actual "text" and actual "value" of a control). However, writing the system so that everything is actually reactive, observable, and bindable, is quite a large task. We've spent many man-years on it.

I would recommend thinking in this direction, though. It's quite nice.