Re: [UFO-devel] Accelerators

[Andreas B. <b_...@gm...>]

On Wednesday 08 June 2005 09:30, Johannes Schmidt wrote:
> Am Mittwoch 08 Juni 2005 00:12 schrieb Andreas Beckermann:
> > Hi
> > there is a pretty huge problem with the accelerator implementation:
> > 1. create a button "button" and assign some action to it
> > 2. button->setText("&Foobar");
> > 3. button->setVisible(false);
> > 4. press ALT+F
> > -> the action is executed, although the button is not visible anymore.
> >
> > This could be fixed e.g. by using a more object oriented design for the
> > accelerators: simply use the key events in the corresponding widgets,
> > instead of the input map of the root widget.
>
> Hmm, I have to admit that I didn't understand your suggestion.
>
> Only the focused widget gets key events, but the accelerators/shortcuts
> should work no matter which widget is focused.

Hmm, yeah I did not think about that.

What about this: when a KeyPressed event occurs:
1. Send an Accel event down the whole hierarchy (starting at root)
2. A widget that receives an Accel event checks whether it 
3. If the Accel event is not consumed: send a KeyPressed event just like 
before
4. If the Accel event is consumed: stop (do not send KeyPressed event)

And while we're on it this could be slightly extended similar to the way it 
works in Qt: before sending an Accel event, send an AccelOverride event. If 
that one is consumed, skip the Accel event and send a KeyPressed event 
directly. Otherwise continue as described above.
-> This way it could be avoided that Accels take the key press instead of it 
being delivered to the correct widget (e.g. a lineedit which has the focus).


An alternative to this procedure would be to continue using a global 
Accelerator cellection, but also storing the associated widget, so that 
widget->isVisible() and widget->isEnabled() can be checked. Doing that in 
keybindingSlot() is indeed a temporary solution only, as this would have to 
be done for every class that may provide accelerators.
With this global solution (which is what is used by Qt, btw) the previously 
described event algorithm can still be applied (just modify "1." accordingly) 
and would still be advantageous.

CU
Andi