Re: [boost] Re: Re: Java style GUI in C++

From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2004-08-22 17:58:27

> >>> 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