-
Gui
I'm looking into creating a GUI system for OpenGL, or whatever you want to render it with (it doesn't really matter for the question).
I have a fundamental problem with the way to store widgets.
Do I- A) Store the child widgets in the parent as an array or-
B) Store all of the children in one array and store references to them in the parent widget
I don't know if that makes sense, hopefully it will.
Perhaps I can illustrate with code.
Code:
class CWidget{
int* childNodeRef;
};
CWidget* WidgetArray;
Wherein each widget is actually in the WidgetArray and childNodeRef[i] refers to an index into that array.
OR
Code:
class CWidget{
CWidget* childNodes;
};
Each parent actually contains it's children. It seems like the same amount of work to implement either method, and both have their benefits- like being able to just do a linear search rather than having to recursively traverse the whole tree to find something.
-
> It seems like the same amount of work to implement either method
That is in essence why there is no actual answer to your question "which is best".
Once your programs get beyond the tutorial level, you'll find yourself making design decisions which will have impact on the rest of the system (some bits will be made easier, other bits harder).
The only real teacher for this stuff is experience, which is why I'd suggest you experiment with both your ideas and see where they take you.
Personally, I'd look at option A with a list, rather than an array.
-
Yeah, that's a fair enough point.
-
Hmm, I think better would not be to look at ease of implementation but, ease of use for the programmer that will be using the class. It's hard to say with the limited info given, but I would guess contained children would be less flexible and limit the programmer to what your system implements, but using references, allows more flexibility in the creation of children because they would be able to do "owner drawn"-inherited children and still pass them in as references.
-
Well, I've tried to obfuscate the programmer as much as possible from the core of the system, for simplicity sake. They should never really have the need to actually modify the way that widgets are managed..just the widgets themselves.
I have a class to manage widgets, it keeps a list of them and passes references to them as well as storing references to children in widget in the list. Doing it this way means you can think of it as linear or a tree. But I might try another method soon.
I have another problem though. I've adopted the windows design, well my interpretation of it, for widgets. That is a callback for messages and rendering. I have seen that many other systems are using polymorphism though. I can't understand why though? Perhaps I'm wrong but doesn't it make the said system less flexible in terms of custom widgets? You have to actually play with the source of the system itself to add a new widget. Whereas with my approach you do it programmatically by registering a widget type and with function pointers you can set the message callback.
I just don't get it, I read a lot of people proclaiming how great polymorphism is. And I can see the benefits of it but in this situation it really seems overkill, but only because the system is more complex. I guess what I'm trying to say that is how I view it, polymorphism may be a complex and great ability of c++ but it really only seems to have it uses in simpler systems.
[edit:] On second thought, perhaps maybe it could actually be of benefit for this. I have never actually, used, polymorphism beyond tutorials...mainly because I've not found a use. If I were to declare the message and render callbacks (function pointers) instead as virtual, would that allow me to say do the following:
Code:
//Just so you know what I'm on about, the widget class-
class _WIDGET{
...
virtual int callback();
virtual void render();
...
};
typedef _WIDGET* WIDGET;
//Can I do this??
WIDGET button;
_WIDGET custom = *button;
virtual int custom::callback(){
...
return 0;
}
virtual void custom::render(){
...
}
Perhaps that would be a better, or indeed another alternative, to using a function pointer for subclassing those particular functions. Which would add either a better or another degree of flexibility in creating & customizing widgets.