I too have a (marginally unimpressive) UI system in place, also in my journal (link at bottom of post). I do something akin to hplus' description for layout, and some data binding spots. As he says, it is quite nice once done, and done well.

Some other major controls that I have and have found useful to a certain degree.

1. Timer. Some people's orginization would have this be more appropriate elsewhere, but I've found it useful to be able to tie an arbitrary timed trigger as a child control to another. Makes FPS displays, certain animations, blinking things much easier.

2. Sound. I hate when stuff isn't consistant. Ever see when you close a window playing a sound and the sound continues? Annoying. It's also fairly hackish to fix depending on how you have things designed. I have a UI control that wraps a sound resource and maps open/visible:close/invisible to play:stop. Makes things easier and consistant, and allows for easy expansion into other GUI sound interfaces; often overlooked in games outside of Options.

Non-Basic:

3. Containers (lists). In data heavy games, it's really nice to have a container that can do auto-arrangement/formatting for you. These are really hard to do right, but when they are... a godsend.

4. Canvas. Essentially a RenderToSurface which is constrained to a rectangle. It's not useful at first glance, but having a common class which does it makes things like screenshots, display caching, and thumbnailing consistant, repeatable, and flexible.


And as I touched upon earlier, I find inconsistantcy annoying in GUIs. Usually that includes things that look identical but have different behaviors (usually due to mouse input differences), or obvious keyboard control of the UI not existing. Wether that's a UI failing or the programmer's fault is debatable though...

Quote:Original post by Dave
I am also unsure about whether to try and make this library cross platform, using OpenGL as the alternative rendering API.

Any thoughts on the ease of this?

I've not actually done it, but if you build everything off of the API dependant parts ("image" and "text" mainly) and keep abstraction in mind, I can't imagine it'll be terribly difficult to drop in replacements for image/text which use differing APIs.

IMO, a good way of abstracting out the platform-dependant drawing portions of the GUI would be to follow a sort of device context approach, where the base control class has a drawing context associated with it, and all drawing methods go through the context interface, where the implementation is platform dependant.

I don't know how *nix and X-windows, or Cocoa works, but I know this would make it easier to add support for Win32 and OpenGL (and possibly Direct-X) driven back-ends.

I did an OpenGL GUI Library for a university project a couple of semesters ago as well. I didn't get done with what I wanted to and I'm actually still working on it. If you are interested here are a few of the key features of my gui system;

• Every component such as the window and push button are derived off of a cComponent class.
• The cComponent class contains a singleton class to a texture repository that contains textures for the backgrounds, frames, fonts, etc.
• The cComponent class allows the component to be customized by allowing the user to select up to 9 textures: 4 for the frames, 4 for the corners, and one for the background.
• I use a virtual coordinate system and translate everything during rendering. The Screen is 10000x10000 units. The only thing that doesn’t use the virtual coordinates is the component frame set.
• Child controls don’t contain pointers to the parent, but have coordinates relative to the parent. When rendering, a control is called by its parent which sends the coordinate translation information.
• Everything is handled through the cWindowProcessor class which basically has two main functions: CreateMessages(void *data); ExecuteMessages(void *data);
• CreateMessages() basically takes the input information, find out which window is being targeted by the cursor and then find out which component inside window is being targeted by the cursor and then create the appropriate message to put in the message queue.
• ExecuteMessage() basically calls every message that is in the queue. Each window has a function pointer that the user sets to determine what happens when each control is pressed, dragged, etc.

How does your GUI interact with the rest of an application? For example, if I wanted to have a window pop up, with a text box that allowed me to, say, input a username and password and click a "login" button, how would the GUI communicate to the application that we are ready to allow the player to attempt to log in, and how would the application find out what username and password the player entered was? This is where I keep getting stuck in my GUI design. I can't seem to think of a non-procedural solution to the problem.