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

[Simon Hausmann]

On Sun, Oct 20, 2002 at 09:45:43AM +0200, Ellis Whitehead wrote:
> 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 

Ah, I see. What navigation shortcuts would that be?

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

I think that is a case that should not be worked around but fixed
for real by removing the clash in the application :)

> > About the scopes: What is the difference between application scope
> > and global?
> 
> Global as in KGlobalAccel.

Ah, I see. (sounds like something that shouldn't be used in regular
apps IMHO :)

I see now the point about your idea of scopes and I agree that this
is something that needs to be taken care of.

Another classic example for the problem is KFileDialog's file
selector embedded in kate. It uses accels for navigation. They used
to be handled even when the fileselector did not have the focus but
the edit widget right beside it. Ok, that's fixed fortunately :) ,
but now the shortcuts don't work anymore at all, i.e. not even when
the fileselector (or any of its child widgets) has the focus.

It sounds awfully complex to me to solve this problem at a global
level (need to keep a list of possible focus widgets, check their
activity, etc.) . But it would be terribly easy to do when just
making KActionCollection install an eventfilter on the fileselector
widget and listen for regular key press/release events. Qt would do
the rest for us.

I see accels as actions that can be activated anytime. This is what
QAccel provides and implements. In the above described case though I
think they would simply the wrong choice.

I think it would be great if KActionCollection would have the
ability to transparently either use accels or an event filter for
regular key events to handle the keyboard activation of actions.
I think that should allow implementing scopes for keyboard
activation fairly easy, keeping away complexity from KAccel.

(I'd be happy to work on this, in case I manage to convince you of
the idea, i.e. you agree :)

Simon