More gui feature requests
Posted: Mon May 10, 2004 10:03 am
I've been having some fun with the gui, but here's a few ideas that would make it easier to extend it.
1.) virtual bool IGUIElement::isBuiltinType()
Would return true by default, but could be overriden by app side classes.
This would allow app side handlers to safely downcast the IGUIElement* to the app side class (assuming app elements derive from a common root).
2.) virtual void IGUIElement::update(float)
Preferably by calling IGUIEnvironment->update(time). Would allow for elements that animate over time. Would be pretty simple, just an iterate in the IGUIElement base class.
3.) currently hovered element from IGUIEnvironment
Saves users from having to glean that info by listening in on store/left events.
4.) irr::gui::EGET_USER_EVENT (at end of built-in enums)
To extend the capability of thrown gui events, the app side can have its own enums. The way I'm doing that at the moment is starting them at first_element = 100 (hence no overlap with the built-in ones), but this would make that somewhat cleaner.
1.) virtual bool IGUIElement::isBuiltinType()
Would return true by default, but could be overriden by app side classes.
This would allow app side handlers to safely downcast the IGUIElement* to the app side class (assuming app elements derive from a common root).
2.) virtual void IGUIElement::update(float)
Preferably by calling IGUIEnvironment->update(time). Would allow for elements that animate over time. Would be pretty simple, just an iterate in the IGUIElement base class.
3.) currently hovered element from IGUIEnvironment
Saves users from having to glean that info by listening in on store/left events.
4.) irr::gui::EGET_USER_EVENT (at end of built-in enums)
To extend the capability of thrown gui events, the app side can have its own enums. The way I'm doing that at the moment is starting them at first_element = 100 (hence no overlap with the built-in ones), but this would make that somewhat cleaner.