First, thanks to the maintainers for continuing to work on CEGUI and for making it what it is. I first used it a couple of years back and have just started using it again and it has matured significantly in that time... so thanks.
Ok then. So I'm guessing this has probably already been brought to the maintainers attention but in the event that is hasn't, I figured I'd drop a line. I've noticed that the callback mechanism in CEGUI is leaning towards that of a generic signals/slot mechanism (i.e. CEGUI::SubscriberSlot) versus the listener/reporter paradigm (though that is still in there... for instance AnimationInstance::setEventReceiver). When I first started wigh gui programming I learned the listener/reporter paradigm, but for the past two years I've been completely sold on the signals/slots mechanism due to my use of GTKmm (c++ wrapper around gtk).
GTKmm has broken out their signals/slots library into a library call sigc++. If you haven't checked it out before, I highly recommend doing that now. It's a very elegant template library that makes event handling a piece of cake and allows for some very intuitive gui design work. The more I've used CEGUI the more i've wished that the event mechanisms were compatable with sigc++ (it's really, really nice).
Anyway, so my suggestion is actually this: perhaps consider utilizing sigc++ as the native event mechanism for CEGUI. The library is ridiculously generic (I've used it on all of the Big Three) and quite easy to use once you understand the concepts of a signal and slot (so not a significant barrier for the young'uns). More imporantly is how flexible it is. You can package up pretty much any kind of callback and shove it into a sigc::signal with only a couple of lines of code. It has support for building functors by binding specific parameters, and other very nice features for handling high level communication between software components.
I know that it's generally considered a "good thing" to keep the dependency count low for ones library, but at the same time I think it's important to at least consider using well developed tools instead of reinventing the wheel. In this case, I believe it will increase portability of existing code and ease integration with other software.
As a last comment, I've used the boost signals/slots libraries a very little bit. While I think they're a bit harder to understand (and I think boost eats a bit too much of it's own dogfood) perhaps that would be another option worth considering.
Thanks for reading my suggestion!
Suggestion: Consider sigc++ / boost for callback mechanism
Moderators: CEGUI MVP, CEGUI Team
-
- Just popping in
- Posts: 8
- Joined: Tue Apr 03, 2012 21:36
Re: Suggestion: Consider sigc++ / boost for callback mechani
I have also suggested this when I started hacking CEGUI. The reason it hasn't been done is (as you probably suspect) to prevent adding more dependencies.
CEGUI actually used boost::signals for subscribers in early versions, it was rewritten to get rid of that dependency.
CEGUI::SubscriberSlot takes functors so you can use boost::bind or other functor template libraries yourself, so I would say it is "compatible" with most of signal/slot libraries.
CEGUI actually used boost::signals for subscribers in early versions, it was rewritten to get rid of that dependency.
CEGUI::SubscriberSlot takes functors so you can use boost::bind or other functor template libraries yourself, so I would say it is "compatible" with most of signal/slot libraries.
-
- Just popping in
- Posts: 8
- Joined: Tue Apr 03, 2012 21:36
Re: Suggestion: Consider sigc++ / boost for callback mechani
Cool, well if it was a conscious choice I'm sure it was a good one. I am using sigc++ signals in my application so it is "compatible".
Return to “Bug Reports, Suggestions, Feature Requests”
Who is online
Users browsing this forum: No registered users and 3 guests