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

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to