GUI API Design

[NGen]

I've been assigned with the task of writing a GUI framework for a game, but I'm not entirely sure on which way to go for designing the API. Does anyone have any personal opinion on what design is best, or does anybody know of a pre-existing UI framework that has an easy-to-use API?

[Computergeek01]

Are you designing the API or the GUI? There's no reason for you to design an API for the GUI but that seems to be what you are implying.

[Veltas]

@Computergeek01: If you want a consistent interface making a GUI API would be appropriate, wouldn't it?

[NGen]

"Making a GUI framework" should imply that I'm coding, so I'm designing the API as well as implementing it. I'm asking for advice on what the API should be like, since many APIs that I've seen have provided limited flexibility or have required long, redundant pieces of code to either create or manage a GUI at runtime.

[chrisname]

The way I would do it (and was, before I accidentally deleted the project) is to have a WidgetManager class, a Widget base class, and a bunch of classes for other widgets (Button, TextEntry, etc.). Each widget has a set of default event handlers (DefaultOnMouseOver for example) and some function pointers (typedef int(* WidgetEvent)(Widget& sender);) so that they can be overridden. Each widget then has a Update method and a few Set/Get methods to change things. The WidgetManager class stores a vector of Widgets. It finds out which one is active (the active widget is the most recently clicked one, although IIRC each one had a public MouseOver method so that they could change colour when you mouse-overed) and then calls its Update method. Then the widget handles events and draws itself on the window.

As an example, the Button class might look a bit like this:

class Button : public Widget {
	private:
		sf::Shape	Shape;
		sf::Color	Foreground[2];
		sf::Color	Background[2];
		bool		Active;
		bool		Visible;
	public:
		WidgetCallback	Clicked;
		WidgetCallback	MouseOvered;
	private:
		void DefaultClicked();
		void DefaultMouseOvered();
	public:
		Button();
		Button(sf::Color foreground[2], sf::Color background[2],
										bool visible);

		bool		Update(sf::RenderWindow& Window);
		bool		MouseOver();

		bool		IsActive();
		void		SetActive(bool active);

		bool		IsVisible();
		bool		SetVisible(bool visible);

		void		SetForeground(int which, sf::Color color);
		sf::Color	GetForeground(int which);

		void		SetBackground(int which, sf::Color color);
		sf::Color	GetBackground(int which);

};

[NGen]

So you find that having an individual function for each event is a better method than having a WndProc-style, general-purpose method that would handle events?

[chrisname]

It seemed to be the easiest way to let the user handle events themselves. The Update function contained a switch statement like this:

switch (event.Type) {
	case sf::Event::KeyPressed:
		if (KeyPressed == NULL)
			DefaultKeyPressed();
		else
			KeyPressed();
		break;
	...
}

so that if the user did not want to handle the event the widget would take a default action (the button didn't do anything if it was clicked and there was no user-defined handler, though).

[Computergeek01]

There are A LOT of advatages to the person using the API with a Callback function. I personally like how if I don't intercept a message in Win32, it takes care of it for me with a familiar default action.

EDIT: I get what you guys mean by API now. For some reason I thought that you were building an engine like Hammer or something to make a one off game.

[NGen]

I think I'll use an abstract class with a pure virtual method that's just passed some event, which the derived class will inherit. For the sake of a barebones engine, that should work well and allow for us to decide if further inheritable classes will also use this method or if they'll do what chrisname suggested.

Thanks for your input, wish me luck.

[writetonsharma]

Have a look at the design of QT at:

www.qt.nokia.com

There is a lot to designing a GUI API. May be you can have a look at MFC code also. But QT is far better and strong than MFC.