Why not use boost::signals for your event interface. It is much better than hand-coded actions and listeners, since any type of function can handle an event. The technology is already in Boost so why re-invent the wheel.
The signals library looks very good, but it solves half the problem. You need to work out what types of signals are raised: MouseUp MouseDown MouseDoubleClick MouseMove and have a signal for each. This would mean that you could have hundreds of signals!
What makes this worse is that you often want to synthesise other events eg:
- MouseClick+LeftAlt - MouseMove-Left-Down (think 'mouse gestures') - etc
Just create a boost::signal<> for the mouse click and pass along all the information about the keyboard with it to the handler.
Possibly - except that the keyboard event will have generated its own event, which would have been passed to the widget in a previous signal. You could pass the key event in the same wrapper as the mouse event (or vice-versa), but then you are saying something about how the dispatcher handles events, which would limit you ability to do some things (eg for drag'n'drop situations, keyboard/mouse handling gets 'interesting' as you need to forward the events to the correct target window). In this case, you would want your 'gesture capable widget sub-class' (or something similar), to synthesise a MouseGesture event (or LeftAltClick event), so that your child widget implementations need only handle the single MouseGesture event, rather than, MouseMove, MouseMoveLeft, MouseMoveDown, etc.
Let the handler decide what should then be done with it. The handler could also be you, internally, ready to trigger a new event for some special situation. The point being that if you decide to have X number of events for a particular class, and you decide that some subset of X can be handled by the user, you are going to have to trigger those events anyway, so having subset-X boost::signals to do it by is no less of a cost than any other way. Remember also that boost::signal<> are just variabales like anything else and can be inherited like anything else by a specific derived class over a broader base class. There is no reason, if you have a particular mouse event as a boost::signal<> for a base class type of "window" to have to create another mouse event of the exact same type, as a boost::signal<>, for the derived class.
Certainly... I dont have a specific aversion to using boost::signal<>... just that most of the examples / suggestions that have been preented so far, have some specific limitations. All I am trying to do is to highlight those limitations, specifically a) N+M event-to-action handling, b) bi-directional event information, c) run-time unknown-event dispatch capability regards, Mathew