CEGUI (Crazy Eddie's GUI) Forums

I've been using CEGUI for a while, and I quite love it. I am nearing the phase where I need to refactor my current application that I've been working on (as soon as I find a good exorcist) and I really want to do a few things the "right" way that I've been working around.

I am not yet on the 0.4 release, but plan to upgrade in the near future.

My problem is, I don't really understand how I am supposed to extend widgets on a behavior level without having to extend the look and feel.

An example is, I have a "toggle button" which when clicked once, stays down, and when clicked again, pops up. Its just a push button, with a state boolean, and a variable. I also have a group of toggle buttons, that are a lot like radios.

Since I can't subclass the Pushbutton, I've had to do it this way:

Built a general property helper class, that takes an object's memory address, plus a key, to return a value, or takes an object's address, plus a key and value to set a property. (Thats not a CEGUI property, but a property I've added)

To handle the behavoir, I write handleToggleButton... methods into my class that get wired into the events for the PushButton, then they use the general property manager and pass the handle of the button that triggered the event to get/set data for that button.


I am pretty sure there is an easier way to do this sort of thing. I would really like to create a PushButton, but instead of creating a literal PushButton, just create a subclass, that I can cast to in its event handlers, which can be in its own class code - leaving it in every other way a normal Push Button. The prob is I don't know how to do this when I call a function in the window manager to create all my PushButtons.

What is the correct way to extend functionality like this without breaking into a derivation of the Look and Feel? Is there a different way in 0.4?


Thanks
- Paddy

Hi,

Your question is indeed a good one; and it's something I touched on in a discussion about future directions on IRC a week or two ago.

As you have found, due to the arrangement of things at the moment, it's not the easiest thing in the world to customise the actual behaviour of a widget, since the normal subclassing approach is encumbered by the use of a rendering/look class for which direct access is largely discouraged.

Nothing much has changed in this area for 0.4.0, although Falagard can allow some things to be done much easier. For example, your "toggle button" has effectively the same behaviour as a checkbox, just with totally different appearance; this can be fully customised via Falagard skinning and so a toggle-button is easily achieved, though obviously, and unfortunately, the core behaviour is still fixed for all the widget types provided.

The next release, 0.5.0, will generally suffer the same short-fall, although it will contain the beginnings of our move over to a more OO approach to behaviour. This transition will be complete in time for the 1.0.0 release some time in the first half of 2006. What we aim to provide with this approach is to allow objects to be passed to windows and widgets that customises the behavior.

To conclude; customising the behaviour of widgets without modifying the core cegui code, or subclassing rendering classes, is something of a weak point at the moment; we are aware of this being an issue, and have plans for big improvements in this area over the coming months.

CE.

Ok, thats good to know - thanks for the info Eddie, I'll keep an eye out for those upgrades.

My thinking about my current approach, is instead of a special property manager that uses a "pointer, a string property name key, and a string return value", I should move to a "pointer, pointer" system where the 2nd object is an instance of a class that holds my extension information, the first (real key) still being a pointer to the instance I am trying to extend.

That way, I can make an ExtendedPushButtonDeally class, with the extra members, and give it methods to handle the events, and let it update the button as needed, and anything else it needs to touch.

What sort of solutions have people been using to date regarding extended behavior? My experience with design patterns is pretty limited, so I am curious what other people have come up with.

Thanks
Pad