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:
> and have a signal for each. This would mean that you could have hundreds of
What makes this worse is that you often want to synthesise other events eg:
- MouseMove-Left-Down (think 'mouse gestures')
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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk