Bug 365808 - Support for Alt-Tab-like shortcuts
Summary: Support for Alt-Tab-like shortcuts
Status: RESOLVED INTENTIONAL
Alias: None
Product: frameworks-kglobalaccel
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Martin Flöser
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-18 11:07 UTC by Ivan Čukić
Modified: 2016-07-18 19:02 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.