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

[Ellis Whitehead]

On Sunday 20 October 2002 10:23, Simon Hausmann wrote:
> On Sun, Oct 20, 2002 at 09:45:43AM +0200, Ellis Whitehead wrote:
> > 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...
>
> I think that is a case that should not be worked around but fixed
> for real by removing the clash in the application :)

This can't always be done, because an application doesn't know what shortcuts 
a KPart will define.  Also Ctrl+U, for example, shouldn't be excluded as an 
application shortcut just because a lineedit widget embedded somewhere in the 
application interface might use it.

> > > 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 :)

Agreed, but in klipper it has a reasonable use, for example.  And some user 
applications define global shortcuts as well, such as noatun.

> 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 wouldn't want to solve it at a global level either, due to the complexity.  
The current idea is that every widget which gets 

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

What about KPart actions?  Some of them should be activatable at any time, but 
only if they aren't overridden by the accels in the focus widget.  QAccel 
can't handle the necessary prioritizing.

> 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 :)

The code I'm working on for 3.2 (and which is largely finished already) 
integrates all three scopes, with no extra code required for handling 
widget-scope shortcuts.  Putting this into KActionCollection would mean 
unnecessary code duplication.

Cheers,
Ellis