It might be easier to group events by type, use signals to dispatch them and an event handler like I suggested to deal with them, e.g. MouseEvent( unsigned int event, const MouseEvent & info ); KeyEvent( unsigned int event, const KeyEvent & info );
Why do you have to create event handlers for people to use. Just create boost::signal<> which encapsulates the parameters you want to pass when the event occurs. Give it a name which relates to the event that is happening, and let anyone simply add their slot to the signal. When your code determines that the event has occurred, just trigger the signal and allow anyone, including your own internal code if necessary, to handle the event. Why do I like this ? Because systems that determine that one must be this-or-that to handle an event are always unnecessarily limiting in one way or another.
The problem with the "registering your self in a slot" approach, is that most events generate actions -> ie they application flow is bi-directional. The signal/slot approach (usually) suffers from not being able to send a response back to the event sender.
The boost::signal<> is fully capable of returning a response. Take a look at it. Furthermore even if it weren't, it is child's play to pass a reference or pointer to something in which a response is put. Finally any handler of a boost::signal<> can generate their own event in response themselves.
Exactly - but how many GUI toolkits actually make the API for the sender of the event, pass a reference to itself? Having myself had a look a little while ago, there arn't many. ... which was the point I was trying to highlight -> I must articulated myself correctly. Mathew