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

[Simon Hausmann]

On Sun, Oct 20, 2002 at 12:16:31AM +0200, Ellis Whitehead wrote:
> > > > This event filter make me wonder: What is it that is so broken in Qt
> > > > that KDE has to re-invent the whole wheel and handle X11 key events?
> > >
> > > It's not that Qt is broken, but rather that it wasn't designed to support
> > > the KPart paradigm.  An accel is global within a Qt application, and we
> > > can't give certain accels more priority over others (such as giving the
> > > KPart with focus priority over a second visible KPart that doesn't have
> > > the focus).
> >
> > I wonder why an accelerator is used then. If the activation depends
> > on whether the part has the focus or not (and I agree with that
> > behaviour) then I think the right thing is to listen for regular key
> > events. Isn't that what the idea behind key events and focus
> > handling?
> 
> A couple of the biggest reason for having actions is for the configurability 
> and sparing the programmer the processing of KeyEvents.  The most significant 
> conflicts come up when multiple unrelated KParts are embedded at one time.  
> Each KPart want's to let its actions have configurable shortcuts, so they use 
> KAction (and thus KAccel).

Yes, no doubt that actions make sense and are much nicer than
writing keyPressEvent handlers.

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

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

Simon