global shortcuts and drop-down active

[Andreas Hartmetz]

Am Mittwoch, 7. November 2007 16:39:53 schrieb Lubos Lunak:
> On Wednesday 07 of November 2007, Andriy Rysin wrote:
> > Hi,
> >
> > global shortcuts in KDE4 (as well as in KDE3) don't work when drop-down
> > (menu or combobox) is active.
>
>  http://bugs.kde.org/show_bug.cgi?id=70063
>
> > E.g. if I start typing something in Dolhpin address bar (or firefox) the
> > drop down with choices appear and I try to e.g. switch keyboard layout
> > with Ctrl+Alt+K or  enable/disable actions in klipper with Ctrl+Alt+X it
> > does not work.
> > Is this working "as designed" because of some limitations or it's a bug
> > in shortcut handling?
>
>  It is definitely not a bug. When you have a popup, that popup needs to
> receive keyboard events. There are two ways to receive keyboard events,
> either have the focus or grab the keyboard. Since application showing the
> popup not always has focus at the moment (e.g. Klipper and its popup), the
> solution is to grab the keyboard while the popup is visible. Now, since the
> application has the keyboard grabbed, other applications don't get any
> keyboard events, therefore their shortcuts don't work.
>
>  I'm not aware of any other alternatives other than these two. X doesn't
> seem to provide any usable mechanism to somehow handle shortcuts during
> keyboard grab. Which means that even if we find another way, that another
> way would be changing how keyboard handling for popups works, which would
> require cooperation from the application showing the popup and as such it
> cannot work for all apps.
>
>  Even then, I'm not quite sure about how to solve it. If the application
> already has focus (which I assume represents most of the cases), then the
> application itself (toolkit, actually) could just avoid the grab and handle
> routing the input event from the focused toplevel window to the popup
> itself. If you run some application with --nograb then you will get more or
> less this (note, --nograb works only with debug-enabled Qt). It would need
> few tweaks, but this could be a relatively simple solution for most cases
> including dropdowns, although not for all popups.
>
>  Better solution would however require much more work. Regardless whether
> the solution would be making the popup's application somehow forward
> shortcuts to other apps or setting focus to the popup, there would be
> problems and their solving would require creating a widely used spec.
> Forwarding shortcuts would be probably practically unfeasible anyway, with
> focus setting there would be undesired focus changes (indeed) that I don't
> know how would be difficult to handle.

From the side of the global shortcuts infrastructure I see no problem. It's a 
kded module that is already connected to DBus anyway. It would probably be 
simple enough to to make it treat key events injected via DBus like key 
events it received from the X server directly.
The interesting part would be to implement key event forwarding in the right 
widgets on the application side. Ugh.
Actually, maybe we should ask the trolls about implementing something like 
QApplication::setKeyboardGrabEnabled()? Something to that effect might be 
already available but you need some black magic to enable it. Think of event 
filters on the application and things like that.
Lubos, you know how to handle keyboard focus better than me - would having a 
programmable "--nograb" even cause less problems than it fixes?

Cheers,
Andreas