Re: [UFO-devel] Accelerators

[Johannes S. <sch...@us...>]

Am Mittwoch 08 Juni 2005 13:32 schrieb Andreas Beckermann:
> 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.

Yet another non-trivial problem.

Using something like the shortcut event like in QT seems to make sense.
I am not yet sure about implementation details, but there should be some 
function within UWidget to add/remove shortcuts.
And you should be able to add several sortcuts for one key stroke.

Perhaps using some sort of shortcut manager.

Secondly, I am pondering about a changing the behaviour of
setVisible and setEnabled.
A visible widget as child of an invisible widget doesn't really make sense.

IMHO, hiding all child widgets when calling setVisible(false) is reasonable.

I'd like to change it similar to this approach:
http://doc.trolltech.com/4.0/qwidget.html#enabled-prop
http://doc.trolltech.com/4.0/qwidget.html#visible-prop

Regards,
Johannes