global shortcuts and drop-down active

[Lubos Lunak]

On Thursday 08 of November 2007, Andreas Hartmetz wrote:
> 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.
...
> >  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.

 Hmm. Ok, I take back that part about practically unfeasible, but it's still 
more work. I'll refrain from guessing the second time how much it would 
be :).

> The interesting part would be to implement key event forwarding in the
> right widgets on the application side. Ugh.

 Actually this part would be no problem, I think. Qt doesn't give a damn about 
the X focus that X uses for sending events - it's only set to the toplevel 
widget and Qt uses its own logic to route it to the (Qt-)focused widget or 
active popup, if any.

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

 I don't think would be needed at all. With the simple solution that'd work 
only if the application has focus, Qt could already itself handle the logic 
of "do I have X focus?" -> "don't grab keyboard for popups", otherwise it'd 
grab. Plus it would have to handle better the few new resulting cases (e.g. 
if you now show a popup with -nograb and then switch virtual desktops, the 
popup will stay).

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz