Archived

This topic is now archived and is closed to further replies.

Gui Component Hierarchy

This topic is 5309 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Let''s say I have a some gui components: Component, FrameWindow, Button. The Component is the base class of FrameWindow and Button. The Component class is responsible for handing the hierarchy for the gui objects. However, I run into a snag. The Component class has methods for adding child components and setting the parent component. But I shouldn''t be able to add a FrameWindow object to a Button object, because that doesn''t make any sense. Is this a problem with the design of the hierachy? Or should I add special code for handling these cases? Any help greatly appreciated. Kory

Share this post


Link to post
Share on other sites
quote:
Original post by kspansel
Let''s say I have a some gui components: Component, FrameWindow, Button.

The Component is the base class of FrameWindow and Button. The Component class is responsible for handing the hierarchy for the gui objects. However, I run into a snag.

The Component class has methods for adding child components and setting the parent component. But I shouldn''t be able to add a FrameWindow object to a Button object, because that doesn''t make any sense. Is this a problem with the design of the hierachy? Or should I add special code for handling these cases?

Any help greatly appreciated.

Kory


easy.. make a parent object and a child object.

a dialog frame would be a parent object, all the objects inside are child types.

-eldee
;another space monkey;
[ Forced Evolution Studios ]


::evolve::

Do NOT let Dr. Mario touch your genitals. He is not a real doctor!

Share this post


Link to post
Share on other sites
Taharez: i think that your design is a good one, but it doesnt solve his initial problem (that i can see initially); because CGuiContainer derives from the same class that CGuiButton derives from.. which means that you can have buttons floating out in space (without a container), and containers "inside" buttons or whatnot... hard to explain but thats what i picture when i look at your diagram

-eldee
;another space monkey;
[ Forced Evolution Studios ]


::evolve::

Do NOT let Dr. Mario touch your genitals. He is not a real doctor!

Share this post


Link to post
Share on other sites
eldee: I guess my image isn''t entirely correct, and should probably have explained my approach a little better

The GUI class is the central class, it handles all objects in the GUI, passes messages and render calls. It contains a pointer to a CGUIContainer called desktop, which is the only pre-defined component. All other objects are added as children to desktop. As you can see from the diagram, I separate container objects and other objects, the CGUIObject class doesn''t contain methods for operating on children, neither can it store any. Both CGUIObject and CGUIContainer are virtual, only their child-classes are instantiated. The IGUIRenderer is a recent addition to easily allow for API-independent rendering.

I haven''t worked on this in a while, it''s still a work in progress, I''ll probably resume work when I have my new engine framework done though.

Share this post


Link to post
Share on other sites
Taharez:

I like your approach, this is basically how I initially thought about doing it. I guess I sidetracked a bit in my design.

Is there any specific reason for having the CGUI class?

I was thinking that I could remove the CGUI class and move any event handling code to the CGUIObject class.

I think this would work well for my event model (Dispatcher/Listener)

Any comments?

Thanks,
Kory

Share this post


Link to post
Share on other sites
I''ve been doing a GUI in OpenGL for this week, and here are some of my considerations:

An elementary object - element. In OpenGL it will represent a simple textured quad (or something else).
A window consists of 3 major elements - window working area, border and titlebar.

A titlebar, in step, consists of N elements (buttons) and a text and probably an icon.
A border consists of 8 elements - top, bottom, left, right, top left, top right, bottom left and bottom right rectangles.

Other elements such as buttons, static controls etc are derived from element class because they are simply an animated textured quad.

An element has also a linked list of sub-elements that can be added and removed dynamically at run-time.
It has some virtual functions (e.g OnMouseDown, OnMouseMove etc).

Above all stands a Window manager, that controls ALL windows and their sub-sub-(etc) elements.

That''s about it. I''m going to release my source on my webpage (link below) so everybody can take a look.


Good luck.

" Do we need us? "


Ionware Productions - Games and Game Tools Development

Share this post


Link to post
Share on other sites
Kory: Well, it would be doable that way too I guess, it''s just that I have some stuff that I think is unecessary to keep in CGUIObject. For example, I handle the cursor, and it is easy to initialize stuff, it''s easy to disable or hide it, and then it also makes it very easy to switch between GUIs ( don''t know why anyone would want to, but you can =D ).

Share this post


Link to post
Share on other sites