From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2004-08-20 01:51:07
> >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