GUI Design Goals

in

After a close inspection of several GUI projects, I finally set out to create my own managed GUI library. There are some really cool ideas in the libraries out there. My design goals for this project will be:

  • Independence from Renderer - Just like in CeGui, it should be easily possible to switch from the XNA GraphicsDevice to a Tao.OpenGL Context.
  • Usable with a GamePad - The library should allow you to construct GUIs that can be controlled using a gamepad.
  • Themeing - It should be possible to change the look and feel of the GUI in an easy way.
  • Easy control creation - Creating new controls should be as simple as possible. Some existing GUI libraries place the burden of handling graphics device resets on the control developers.
  • Multiple desktops - You should be able to run multiple GUIs at the same time in order to support ingame computers like seen in DooM3 for example.
  • Avoid messaging system - Do not use messages for propagating input events to the controls (bad design: creates garbage and decreases debuggability)
  • Performance - Batch vertices and optimize texture usage so the GUI can handle large numbers of controls and texts.

This is not the first GUI I'm writing, I've done a similar system before in C++ which can be seen in the Nuclex Engine Demo I posted some time ago when I released the sources to my Nuclex Engine.

Allan's picture

Messaging?

Submitted by Allan (not verified) on Thu, 2007-10-25 01:03.

I'm afraid I don't understand the "avoiding messaging". What do you mean by this and what are the options in this respect?

I'm very intersted to see this, having recently embarked on an interface in XNA. Its become a trick to me to link events (mouse clicks, et. al.) with actions and code.

I'll be looking forward to learning from someone who's been there before. :)

Cygon's picture

Systems that Propagate Messages

Submitted by Cygon on Mon, 2007-10-29 09:01.

Most GUI systems are centered around message objects. For example, when the user presses a key, a message with the keycode is generated and handed to the topmost control. This control can then either process the message or hand it over to its active child control, and so on. That's what I meant with messaging system.

The problems with this approach are:

  • Who sent me that message? The debugger will just show you the message processor at the root of the call stack, and even if you figure out where the message originated from, it might have been queued the previous frame, at least, the originator's state has changed since the message was sent.
  • Downcasts and variants. Messages have to be generic, so they provide an ID which has to be correctly interpreted by each control plus one or more variant fields - typeless general-purpose variables the message receiver has to unsafely downcast to what it thinks they are based on the ID.
  • Garbage. Each message will become garbage after it has been sent. Might be negligible on desktop machines, but will clearly not be optimal for the XBox 360.
  • Error handling. What is a control to do when it receives a message with a command it cannot process? The control has to disregard the message or even try at getting an error notification message to the sender, which will take three frames during which the control keeps its invalid state.

That's why I'm avoiding such messaging systems like the plague :)

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <br> <a> <em> <strong> <u> <i> <b> <cite> <blockcode> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <pre> <span>
  • You can highlight code with any of the following tags: <blockcode>

More information about formatting options