Today I’m happy to announce that for the first time we were able to backport a new feature from our Wayland offerings to X11: modifier only shortcut support. This is one of the most often requested features in Plasma and I’m very happy that we finally have an implementation for it.
Modifier only shortcuts mean that an action is triggered if one clicks a modifier key without any other key. By default the Meta (also known as super and windows) key triggers the main application launcher of your Plasma session. But the implementation is way more flexible and allows to use any modifier (ctrl, alt or shift) as a trigger for an action (currently configuration is only possible through manual modification of kwinrc).
The feature was initially implemented for Wayland inside KWin and has been available for a year already. The tricky part is to recognize when only a modifier is pressed. On Wayland KWin gets all key events and passes them through xkbcommon. Given that KWin knows when a key is pressed and knows when only the modifier is pressed. Thus it was possible to implement modifier only shortcuts.
On X11 our global shortcut system does not have such a deep knowledge about all key states. It only registers to the shortcuts one has configured and in general it triggers on the press event, for modifier only we need trigger on the release event. As our X11 shortcut system relies on key grabbing we couldn’t use it for modifier only support: the chances to break applications are too high.
The implementation we have now on X11 reuses the infrastructure setup for Wayland. It uses XInput 2 to listen to all raw key events (which are also delivered if an application grabs the device) and sends those events through our xkbcommon infrastructure just like on Wayland to recognize the pressed keys.
In the past my main concern was that we mis-detect the state and that we trigger the shortcut when that is not wanted, for the wrong key, etc. etc. Also with the new implementation I have these concerns, although I’m very confident that it works correctly. Nevertheless I want to ask you to give a try to this feature and report if you notice any problems. I’m especially interested in setups which change the meta-modifier position through xmodmap and layout changes. If anything is not working as expected please tell us so that we can have an awesome modifier only experience in Plasma 5.8.
In case you use KSuperKey I recommend to disable that. Otherwise it might happen that shortcuts are triggered twice. At that point I want to thank KSuperKey for having filled this gap in our default feature set and providing a solution for our users who wanted to use this feature.
That is just great Martin. Thanks a lot for pushing KWin. Its fantastic.
Thank you, KSuperKey was always the first thing i installed on Plasma.
Now this is built in which is awesome!
Great news, I will gladly switch from KSuperKey to something built-in.
I was actually surprised that standalone Meta didn’t activate the Launcher on my new Plasma 5.6 desktop as I was used to in Mint Cinnamon + Windows.
KDE is making great progress lately (new KDE convert here). I can’t wait to a see a Wayland implementation similarly sophisticated and stable as Plasma 5.6 on X.
Keep up the good work !!!
I have been hoping for this for a long time. Thank you so much!
Does using this framework also mean that the numpad keys will work for shortcuts too?
I don’t understand. This is about modifier only shortcuts not about numpad shortcuts
Martin, thank you for implementing this feature in Wayland and backporting it to X11, I’m sure many people will appreciate it. I have added a note to the ksuperkey README that this feature is available by default in Plasma 5.8 and upwards.
Hi,
I am using openSUSE Plasma unstable packages ( git packages ) that seem to have this enabled. Everytime I press the meta key ( superkey ), it opens the plasma launcher.
How do I disable this ? Meta is my window modifier key ( I switched alt to meta ).
Thanks
Hi,
In current Neon developers unstable when I press Meta once, the Kickoff menu appears, but when I press Meta again the menu does not disappear. So, Meta works not as a menu trigger, but just as irreversible menu caller. I have to press Esc or click somewhwere to hide the menu. Such behaviour seems to be quite unnatural and irritating. When I use hotkey set in Kickoff settings (in my case it is Meta-Z) it works perfectly (opens hidden menu and closes opened menu).
That’s already reported as https://bugs.kde.org/show_bug.cgi?id=367685
Hello Martin, could you please explain in a few word how to disable that? I mean I’d like to not show kickoff menu when pressing Meta key
Oh, nevermind, I found the intructions below, sorry
moi,
could you include a short example on what to set in kwinrc?
i want to make dual-role keys out of my shift keys, e.g. left shift triggers ” and right shift ‘end’. is that possible with that change?
see also https://superuser.com/questions/1127959/dual-role-keys-on-linux
no, that’s not possible with this change.
How can I disable this feature in kwinrc ? Is it documented somewhere ?
Thanks foe the awesome work !!!
see https://www.reddit.com/r/kde/comments/55udc1/how_do_i_stop_the_meta_key_from_opening_the/d8epzzj
Thanks Martin for the info.
I am using left windows key as compose key, and the recent update to plasma 5.8 was driving me nuts : showing the application launcher menu, as you explained.
So, I added:
—
[ModifierOnlyShortcuts]
Meta=
—
in my ~/.config/kwinrc, and all was back to normal.
Now, everything is fixed… except in libreoffice when started from the application launcher.
Starting libreoffice from the command line makes it react correctly to the compose key.
Please report a bug about it.
Hi again,
I was waiting for my plasma 5.8.2 install to finish before reporting the issue, but 5.8.2 did not solve the problem. So I investigated ; I created a fake application from kmenuedit, with the following command:
“env | sort > ~/plasma_env.log”
Then I compared with my standard environment, such as the one in a freshly started xterm.
I discovered that the LANG variable was set to fr_CH.UTF8 in plasma (from System Settings -> Regional Settings -> Formats -> Region) which was a mistake since I do not have this locale installed, as shown by “locale -a”.
I set the region setting back to to “No change”, restarted my plasma session, and then: the compose key was back in all libreoffice components!
Where do you think the problem lies ?
1) systemsettings5 should only allow the user to choose within the installed locales?
2) libreoffice should handle this mistake correctly and default to an installed locale ?
both. Systemsettings should validate and libreoffice should validate. Both should be fault tolerant IMHO.
Huge thanks for that workaround =)