Bug 365808

Summary: Support for Alt-Tab-like shortcuts
Product: [Frameworks and Libraries] frameworks-kglobalaccel Reporter: Ivan Čukić <ivan.cukic>
Component: generalAssignee: Martin Flöser <mgraesslin>
Status: RESOLVED INTENTIONAL    
Severity: wishlist CC: kdelibs-bugs-null
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Ivan Čukić 2016-07-18 11:07:12 UTC 
There is the need for applications outside KWin to use shortcuts that allow opening some king of browser and allot traversing through that browser by not releasing the modifier keys, and re-pressing the non-modifier key.

Examples for this include:
- Alt+Tab - Press Alt-Tab, the 'window browser' appears, pressing the Tab changes the selected window, depressing Alt switches to thiat window and closes the browser (this one is in KWin)
- Meta-Tab - Press Meta-Tab, the 'activity switcher' appears, pressing the Tab changes the selected activity, depressing the Meta key closes the switcher and switches to selected activity.

Until now, this was done by applications being benign key-listeners in X11, but this is no longer available in wayland. So, another solution needs to be found.

Related:
https://bugs.kde.org/show_bug.cgi?id=364338

Reproducible: Always
Comment 1 Martin Flöser 2016-07-18 11:44:34 UTC 
Sorry, but that's outside the scope of KGlobalAccelD - especially as it's specific to one platform. It cannot be done in a way that would suit KWin. KWin needs more knowledge about the interaction and supports additional keys when Alt+Tab is pressed, which are not registered as global shortcuts. E.g. cursor keys are forwarded to the view, escape is handled, etc. This is all very runtime dependent and cannot be done if KGlobalAccelD grabs the keyboard (as needed for supporting that). Overall that looks to me like these special cases are better handled in the application.
Comment 2 Ivan Čukić 2016-07-18 12:30:48 UTC 
> Overall that looks to me like these special cases are better handled in the application.

How do you propose to do that - if Plasma can not listen to the keyboard? Do it in KWin and communicate it to Plasma via d-bus?
Comment 3 Martin Flöser 2016-07-18 14:40:43 UTC 
(In reply to Ivan Čukić from comment #2)
> > Overall that looks to me like these special cases are better handled in the application.
> 
> How do you propose to do that - if Plasma can not listen to the keyboard? Do
> it in KWin and communicate it to Plasma via d-bus?

if KWin can listen to the keyboard, Plasma can listen to the keyboard. Why should KWin do the interaction for Plasma?
Comment 4 Ivan Čukić 2016-07-18 17:21:33 UTC 
You said that on Wayland only KWin will be able to listen for the keyboard and handle shortucts. Or did I misunderstand you?
Comment 5 Martin Flöser 2016-07-18 19:02:57 UTC 
(In reply to Ivan Čukić from comment #4)
> You said that on Wayland only KWin will be able to listen for the keyboard
> and handle shortucts. Or did I misunderstand you?

I talked about X11, sorry I missed that part. For Plasma it should not matter. What needs to be ensured is that after activating a global shortcut, Plasma needs to have keyboard focus and then all keys are sent to Plasma and Plasma can filter them. All that is needed is to ensure that Plasma has an implicit keyboard grab. Nothing to do with kglobalaccel.