Review Request 124954: Add support for modifier only shortcuts on Wayland

Fri Sep 4 11:56:07 UTC 2015

> On Aug. 27, 2015, 7:04 p.m., Thomas Pfeiffer wrote:
> > Since this is indeed a very often required feature, why do we keep it hidden? If it can have negative side-effects, it we should warn users about them, not hide the whole feature from them.
> 
> Thomas Lübking wrote:
>     or restricte to wayland? same process would work for kglobalaccel on X11.
>     Afaiu the restriction has always been the shortcut editor widget?
> 
> Martin Gräßlin wrote:
>     > why do we keep it hidden?
>     
>     Because it's extremely technical the way it's implemented. I don't want to have a UI which exposes internal, technical functionality to setup DBus calls.
>     
>     The question is what do people want to do with it? Open the launcher with meta. What else? Nothing? Anybody who wants shift to act as a launcher? unlikely or Alt on a German keyboard? Unlikely.
>     
>     If we want to have Meta to trigger opening the launcher, Plasma should provide a default config for KWin. It's nothing KWin cares about, we support multiple desktop shells and won't add it directly to KWin. The feature is implemented in a generic way, but that also means it's very technical to configure. Thus nothing to be exposed in a config.
>     
>     After all isn't it you guys who tell me that our config dialogs are too complex? ;-)
> 
> Thomas Lübking wrote:
>     which launcher?
>     kickoff?
>     homerun?
>     krunner?
>     
>     while at it: should we allow modifier combinations? (eg. Meta: kickoff, Shift+Meta: homerun, ctrl+Meta: krunner)
> 
> Martin Gräßlin wrote:
>     > which launcher?
>     
>     I'd say that's up to Plasma to come up with a solution for that. E.g. a DBus call to open the currently used launcher (assuming that users don't put multiple launchers in their panel).
>     
>     > should we allow modifier combinations?
>     
>     nah that just complicates it ;-)
> 
> Thomas Lübking wrote:
>     would one rather emit a dbus signal then?
>     st. like "modifierHit(int/qstring modifier)"
>     
>     This allows interested clients to hook onto it and/or provide a checkbox/combobox whether they should (on what modifier)
>     
>     Complexity shouldn't be too much, ignore other modifier presses and check modifiers on first modifier release.
> 
> Martin Gräßlin wrote:
>     Brings the disadvantage of:
>     * all (connected) apps wake up whenever someone presses shift (I do that a lot and then don't type)
>     * multiple actions can get triggered - there are no checks
>     
>     If we would want that we would rather have to make it part of KGlobalaccel.
> 
> Thomas Lübking wrote:
>     shiftModiferHit(int modifiers)
>     ctrlModiferHit(int modifiers)
>     altModiferHit(int modifiers)
>     metaModiferHit(int modifiers)
>     
>     (why do you press shift w/o typing btw.?)
>     
>     
>     About the multiple invocation: either we
>     - accept that
>     - utilize kglobalaccel (collision check mechanism)
>     - leave the entire thing unconfigurable (where the user cannot control which runner he gets for the shortcut)
>     
>     => are multiple bindings really an expectable problem?
>     And if they are, doesn't that imply so widespread usage so that user configuration becomes "mandatory"?
> 
> Hans Chen wrote:
>     Two questions:
>     
>     1. From a non-technical point of view, does it make sense to make this part of KWin? For example, if I choose a different window manager with Plasma, why should I lose this feature that has little to do with window management?
>     Having this to be part of KGlobalaccel seems much more reasonable from a user's perspective (since it has to do with shortcuts).
>     
>     2. Will there be a timeout, i.e., holding down a modifier for long enough will make it not trigger the DBus call, for example if you want to press a Super+<something> shortcut but then change your mind.
>     (Maybe it's already there and I'm just blind.)
>     
>     About use cases other than Super to show the application menu, some Vim users may want to map e.g. Ctrl to Escape. Personally I also map Alt to my Tmux key.
>     With that said, you could argue that such users know how to archieve this without a GUI. The large majority probably just wants the "Windows key to launch application menu" functionality.
>     
>     Thanks for CC:ing me by the way, much appreciated.
> 
> Martin Gräßlin wrote:
>     > From a non-technical point of view, does it make sense to make this part of KWin?
>     
>     This is for Wayland. An application like KSuperKey cannot work on Wayland at all (no global keyloggers). We either make it part of KWin or cannot offer it at all.
>     
>     > For example, if I choose a different window manager with Plasma, why should I lose this feature that has little to do with window management?
>     
>     Wayland :-) If you choose a different compositor for Plasma you will lose more than just this feature.
>     
>     > Will there be a timeout, i.e., holding down a modifier for long enough will make it not trigger the DBus call, for example if you want to press a Super+<something> shortcut but then change your mind.
>     
>     The shortcut triggers on key release and not on key press. Given that a timeout is not needed. That is also why it's not (yet) in KGlobalAccel as KGlobalAccel operates on presses.
>     
>     > some Vim users may want to map e.g. Ctrl to Escape
>     
>     That's what keymaps are for.
> 
> Hans Chen wrote:
>     > Wayland :-) If you choose a different compositor for Plasma you will lose more than just this feature.
>     
>     I understand the connection to Wayland, I was just questioning whether it makes sense to make this part of what traditionally was "just a window manager".
>     But given KWin's role as a compositor for Plasma, I guess that's just the way it is.
>     
>     > The shortcut triggers on key release and not on key press. Given that a timeout is not needed. That is also why it's not (yet) in KGlobalAccel as KGlobalAccel operates on presses.
>     
>     Yes I know :) ksuperkey does have a timeout though, if you hold the modifier long enough it won't trigger the action (default timeout is 500 ms).
>     This is nice for "destructive" actions like generating Escape. However, for something like opening the application launcher it might not be needed; as far as I know Windows doesn't have a timeout.
>     
>     > That's what keymaps are for.
>     
>     I meant a similar mechanism as ksuperkey where Ctrl acts both as a modifier and Escape (typically you map Caps Lock to Ctrl).
>     But this isn't really important for the current discussion, I just wanted to give another use case for a mechanism like ksuperkey.
> 
> Martin Gräßlin wrote:
>     > I was just questioning whether it makes sense to make this part of what traditionally was "just a window manager".
>     
>     we need to get over that: KWin is a compositor (and also a window manager) and yes for a compositor it makes sense to handle input as otherwise input redirection is not possible. It's just that on X11 the input redirection never matured. And on Wayland we need to consider the constraints of Wayland. Features like ksuperkey are impossible as nobody except the compositor has access to all key events. That's also the reason why kglobalaccel is merged into kwin on Wayland (but not on X11).
>     
>     > I meant a similar mechanism as ksuperkey where Ctrl acts both as a modifier and Escape
>     
>     allthough a little bit offtopic: I really think that's not what ksuperkey or this functionality is for, but that is what keymaps are for. If users want to have the key act as Escape: modmap it

Thanks for the clarifications Martin. I feel that I've derailed the conversation somewhat, so I'll just leave a final thought before leaving the discussion:

Personally I would've liked the more flexible solution of letting the user use the modifier keys in the standard shortcut dialogs (with an option to disable this behavior in System Settings, e.g., "[x] Super modifier can be used as a stand-alone key in keyboard shortcuts" <- needs to be worded better).
In that case there would be no need to e.g. implement a method to open the "current/default/preferred" launcher in Plasma.
However, this would likely take much more work, and if the goal is to mainly support showing the application menu when pressing Super, then the current solution seems fine to me.
(Some people like to show KRunner instead of a menu, which should be easy to support with the current implementation.)

Off topic:

> I really think that's not what ksuperkey or this functionality is for, but that is what keymaps are for. If users want to have the key act as Escape: modmap it

This functionality is actually the reason why the precursor to ksuperkey (and thus ksuperkey itself) exists. ;)

> xcape runs as a daemon and intercepts left control key events. If the left
> control key is pressed and released on its own, it generates Esc key
> events. Thats it! Other than that it does nothing!
> This makes more sense if you have remapped your Caps Lock key to Control.
> Future versions of this program might do that mapping for you, but for now
> this is something that you have to do yourself.
> If you don't understand why anybody would want this, I'm guessing that Vim
> is not your favourite text editor ;)

- Hans

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124954/#review84486
-----------------------------------------------------------

On Aug. 27, 2015, 4:04 p.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124954/
> -----------------------------------------------------------
> 
> (Updated Aug. 27, 2015, 4:04 p.m.)
> 
> 
> Review request for kwin, Plasma and Hans Chen.
> 
> 
> Repository: kwin
> 
> 
> Description
> -------
> 
> On popular demand!
> 
> This change tracks how modifiers are used and detects a modifier only
> key press/release. That is:
> * no other key is pressed when the modifier gets pressed
> * no other key gets pressed before the modifier gets released
> 
> If such a press/release is detected, we call a configurable dbus call.
> The possible shortcuts can be configured in kwinrc, group
> "ModifierOnlyShortcuts". The following keys are supported:
> * Shift
> * Control
> * Alt
> * Meta
> 
> As value it takes a QStringList (comma seperated string) with
> service,path,interface,method,additionalargs
> 
> E.g. to invoke Desktop Grid effect on Meta key:
> 
> [ModifierOnlyShortcuts]
> Meta=org.kde.kglobalaccel,/component/kwin/,org.kde.kglobalaccel.Component,invokeShortcut,ShowDesktopGrid
> 
> I do not intend to add a config interface for it. Let's keep it a hidden
> way.
> 
> 
> Diffs
> -----
> 
>   input.h cfb693dc06a18ea9ca7cffb99b9a1318ee443e3a 
>   input.cpp 92724d7b7559dd460a8f5fbe17deb3c72024eed6 
>   options.h 07c5193e3bd205c5c8c22a305f4c1d87e16d175f 
>   options.cpp 64269d64bc49640bf2e4e925ce1969f2a5d6b96b 
> 
> Diff: https://git.reviewboard.kde.org/r/124954/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150904/ce65b853/attachment-0001.html>