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

Hans Chen hans.chen at kde.org
Mon Aug 31 02:13:58 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"?

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.


- 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/20150831/23fc7465/attachment.html>


More information about the Plasma-devel mailing list