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 I mentioned previously the problem that most toolkits have -> they require N x M code paths to be implemented, when N is the number of events/signals/whatever-the-metaphore, and M is the number of widgets. Ideally you want to make the problem domain become an N + M problem... there are toolkits that already do this -> most of them implement message maps.
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 );
this suffers the same problem as I am describing above, eg: a button widget that needs to handle a button press event, will need two seperate code paths, just to execute the same functionaly (ie the button press). Mathew Robertson