accel problems: might be qt-copt, might be kdelibs

[Ellis Whitehead]

On Sunday 20 October 2002 00:25, Simon Hausmann wrote:
> > > If this is about actions then I think the actioncollection should
> > > simply listen for key events on the part's widget and catch action
> > > shortcuts appropriately.
> > >
> > > Or does that miss any case?
> >
> > Yes, the problem is that KeyPress event is set to 'accept()' be default,
> > so if the focus is in a subwidget (say the edit widget of a dialog), then
> > the dialog doesn't ever get the KeyPress event to filter.
>
> I'm not sure I understand...
>
> Say if I bring up the find dialog in khtml, CTRL+P for example
> shouldn't fire up the print dialog.
>
> In case of regular key event handling the key event is first sent to
> say the lineedit inside the find dialog and (in this case as it is
> unhandled) then upwards to the dialog object. Then it is discarded.
> Correct handling I'd say, the event filter wouldn't receive the key
> event at all, as the part's widget never receives the key event, no
> problem.

My statement above was the product of a mis-thought. *grin*  However, there 
are a couple problems with doing the processing in keyPressEvent.  The 
biggest one is that all QAccels would have priority over KDE accels: i.e., 
navigation shortcuts would be activated instead of accelerators.  The other 
possible problem (which might actually be a good thing) is that KeyPress 
processing would have priority over accelerators.  If an edit widget 
processes Ctrl+U, for example, then a Ctrl+U application accelerator can't be 
used while in the widget.  Like I said, this might be a good thing, but it 
would be a significant UI change that would surely bring in bug reports...

> About the scopes: What is the difference between application scope
> and global?

Global as in KGlobalAccel.

Cheers,
Ellis