Sign in to follow this  
silverphyre673

Which of these seems easier to use, or more intuitive?

Recommended Posts

I'm reworking my GUI system and implementing some ideas I think are cool. One of the things I want it built around is the idea of making it skinnable for the developer, so the developer can change how all the elements are drawn. This is coded in C++. Which of these systems for choosing how it is drawn would you find more intuitive to use? The first idea is to make each type of GUI object store a function pointer to the drawing function it should use. This seems elegant, in concept, and it would avoid having to use a v-table, which consumes processor power and memory, but I honestly think there is a reason why I don't see or use function pointers almost at all. Curious syntax, to say the least. The problem wouldn't be so bad with the controls that are pre-made, but if the developer wanted to add in a new control, he would have to know how to use them, and I don't think that many really want to. The second idea would be to have a base GUI rendering class, and having all the controls store pointers to different rendering classes derived from this one. The base class would have a pure virtual Draw() function, and the developer could derive his own classes from this one. I'm thinking of going with the second one right now, because, being a GUI, it will not consume too much processing power. If you all think that the first idea is better, though, let me know. Thanks!

Share this post


Link to post
Share on other sites
I like the second way better. Anytime that you have to rely on the user to do their own rendering, you're going to run into usability issues.

[Edit] Would it be possible to have all the controls sit on a containing control that stores the pointer to the renderer and when they want to be draw, the containing control calls their draw function. That way you have less pointers floating around.

Share this post


Link to post
Share on other sites
IMHO the second way is the right. Going the first way means to paraphraze polymorphism. However I prefered the second way already in my own solution:

A Gadget class is able to handle user input in form of pointer device motion, pointer device clicks, keyboard presses and releases, and so on. Gadget is in fact an interface. Besides interactive tools, also Widget is derived from Gadget. A Widget adds a kind of visual representation to Gadget, but only in form of a delegate, similarly as you described it. Those delegates are called cells, and are derived from a View (also the 3D view is in fact derived from that class). So, an effective Widget (e.g. a SliderWidget) defines the functionality (e.g. min and max value, current value, stepping, dragging), and its SliderWidget::Cell (obviously a specialization) is able to render a container and a knob. The functionality is totally separated from the visual representation. So, for example, in the editor (which must be understand as a plug-in running inside the game engine) I could have a theme totally different of the theme of a game running in my engine.

Share this post


Link to post
Share on other sites
Quote:
Original post by silverphyre673
... it would avoid having to use a v-table, which consumes processor power and memory...

A v-table *is* a function pointer. So in terms of performance, there's no reason to prefer this method over inheritance.

CM

Share this post


Link to post
Share on other sites
ClanLib has an extremely flexible GUI system. Here is a link to the docs on its GUI framework. You might have a look at that before you finalize anything.

Here are the basic premises of the ClanGUI design.

Firstly, notice that they use a slot/signal framework for interaction between the GUI system and the host, which is essentially a generalization of the function pointer concept to allow multiple targets (i.e., a function pointer which points to multiple target functions and therefore, when invoked, dispatches the call to multiple receivers). Writing such a system is somewhat tedious, and fairly difficult if you want a large degree of flexibility, so I therefore refer you to Boost.Signals if you are interested in utilizing such a framework.

As for their take on your design problem, they have approached it very similarly to your second proposed method. Essentially, the GUI "style" functionality is broken off from the main GUI controller and placed into a style manager class. In actuality, this is quite an involved approach.

Basically what it does is it has an abstract interface for styles for particular component/control types, and when a component is created, it contacts the ruling style manager which then becomes analogous to an object factory taking as input a string specifying the component type and returning an object which handles the rendering of that particular type of component. I think reading through their tutorial on how to create custom style managers here will explain the structure and dynamics of the system better than I can here. [smile]

Edit: Also, you mentioned the nasty native function pointer syntax. Behold Boost.Function.

HTH,
nilkn

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this