It would be very convenient if KDE supports a "second stroke shortcuts". For example: Meta, Meta. This concept is widely used in Jetbrains IDEs, for example, in PyCharm. You can quickly press "Shift, Shift" for "Search Everywhere" action. You can assign your own shortcuts with adding a second stroke shortcut. It may be any other shortcut, not exactly double pressing the same button. For now my main ache is a Meta-only shortcut. By default, when it is pressed and released alone, it opens the Start menu. But I invoke it by accident very often. This is mostly when I actually wanted to press a normal shortcut with Meta (say, Meta + E for Dolphin), partly entered shortcut (pressed Meta), and decided that I actually do not want to open Dolphin. Now I release Meta, and unfortunately Start menu is opened. There was a bug report on that (I will add its number later). Because of this problem, I disabled the Meta (modifier only) shortcut by this instruction: https://superuser.com/a/1158462/873855. But I would very like to be able to open Start menu by double hitting Meta button. I saw KDE has some "unusual" shortcuts such as "Alt + D, E", documented here: https://docs.kde.org/stable5/en/plasma-desktop/plasma-desktop/shortcuts.html But they are probably hardcoded (you cannot specify such from UI), and they are not actually "second stroke" shortcuts in its full meaning. I.e., the timeout after Alt + D is not going. I can press Alt + D, then wait many seconds, then press E. And that shortcut will work. While the second stroke should be awaited only for a short period after first stroke. I have also seen requests for this. For example: https://www.reddit.com/r/kde/comments/qvwp08/double_press_shortcuts_in_kde/
This bug I mentioned in the previous message is - https://bugs.kde.org/show_bug.cgi?id=371560#c0
*** This bug has been marked as a duplicate of bug 217833 ***
*** Bug 217833 has been marked as a duplicate of this bug. ***
*** Bug 161009 has been marked as a duplicate of this bug. ***
*** Bug 210618 has been marked as a duplicate of this bug. ***
*** Bug 481365 has been marked as a duplicate of this bug. ***
It would be nice if there is some sort of visual feedback (like a OSD popping up) when the user presses the first stroke in a multi-stroke shortcut. The OSD could contain options for all possible next strokes.
In some places it is already possible to assign second stroke shortcuts. For example, in Kate (or other KDE application) in Configure Global Shortcuts in the Alternate column (but not in the Shortcut column).
TLDR summary: Brief kde multi-key global hotkeys history and current status, discussion of available user workarounds. FWIW this remains a long-term regression from the kde3 era where multi-key hotkeys worked fine, including even a popup menu after the first one showing configured second-key choices. Only now it's worse, at least on wayland, because unlike X where every app could see the keys entered (including passwords!!) entered on any other app, thereby allowing third-party global hotkey apps, that choice is gone on wayland (where apps other than the compositor only see keys entered while they are in focus) due to its higher security, so a standardized the third-party solution is out (but see option #3 below... and out at least until a wayland protocol extension is agreed that makes it possible, the mechanism by which third-party screenshotting apps can arrange for access to the visual contents of windows of other wayland apps, for instance). Available workarounds: 1) Stick to X and (continue to) use third-party X-based global hotkey solutions. Biggest downside is that X platform support is now second-class and gets less testing, with the problem only getting worse as time progresses, but if you already have other things keeping you on X and already have a third-party X hotkey app setup, this should work reasonably for awhile, anyway. But I'd *not* recommend this to people who haven't setup such an app yet as the timeframe it'll be viable is limited. Upgrade path would presumably be thru #2, below. 2) On wayland, configure "Legacy X11 App Support" (plasma system settings > security & privacy > application permissions) to "Allow legacy X11 apps to read keystrokes in all apps" to "always". Again, use a third-party X-based global hotkeys solution. This should continue to be supported much longer than #1 and is the likely upgrade path thru which people on #1 will move. As such it's much more viable. There's still a security tradeoff in that all X apps will be seeing your wayland keys as well, but security-wise, it's not worse than the X we used for decades, and is at least a step on the way, since wayland apps will at least not see each others keys even if X apps still do. The upgrade path from this will presumably be through #3, once a wayland protocol extension is standardized to make third-party wayland hotkey apps more viable. Meanwhile, this is likely the simplest solution, even if it is someone time-limited (but less than #1). 3) There is apparently at least one wayland third-party hotkey app, but I don't remember the name ATM (egg-something maybe?) and due to wayland's security which would normally break it, I believe it actually hooks into the input stream below wayland (at the /dev/input/* device-file level), which likely requires fiddling with device-file permissions. I've not looked into it further but have been meaning to as in theory that would have many of the same upsides as the #4 choice I took before I knew about this one, with less of the major downside, complexity, tho there'd still be some in getting the permissions correct and just learning its config. Eventually, wayland/XDG will likely standardize a protocol extension to make third-party global hotkey apps work without the degree of permission-changes, etc, now necessary, and there will be more of these third-party wayland-based apps, enough so as long as the compositor implements the extension, much like the existing situation on X, users won't be locked into whatever the desktop natively provides -- or fails to provide. This is thus the eventual ideal target. 4) Take advantage of the insight that multi-key can be seen as sequential keys, not all of which must be processed by the same app-instance, to cobble together a solution out of available components, with plasma only processing the initial hotkey to launch the cobbled-together solution to handle the second and further keys. This is in fact what I did back when the regression first hit with kde4, and what I still do today, altho I've changed the primary component I use since then. (I initially rolled my own bash script for the menu, but eventually switched to pdmenu...) Ideally, this would work like so: Configure a single plasma/kwin hotkey to launch a third-party menu app, which would then see and process the second and subsequent keys as it would then be the in-focus app. If more than one initial launcher keys are configured, each would conceptually launch the third party app as if it were a submenu, since the choice of initial launching key would effectively be the main menu. Unfortunately I didn't find an X/wayland based app that could be directly launched this way to function as the (sub)menu. Maybe there is one I couldn't find... What I *did* find was a TUI-menu app called pdmenu. Check your distro repo (Gentoo has it as does Debian apparently... there appear to be SuSE etc packages listed as well but it's not clear from here whether they're main repo or third-party repo) or find it at https://joeyh.name/code/pdmenu/ Since it's a TUI I launch it in a konsole window. I have my own config for it that's too complex to detail in this comment, but if anyone's interested in doing similar, ask, thereby allowing you to take advantage of the stuff I had to figure out on my own. The end result is that in practice I have a multi-key hotkey solution, even if in practice, the initial key is handled by plasma, launching (a konsole window running) pdmenu, which handles the second and subsequent keys. The biggest downside to this solution is the complexity of getting all the components configured to work together as you want. For some people that'll be a blocker as they simply don't have the time/motivation to master that complexity and get it working for them. The biggest upside is that once setup, you have a much longer term solution that's immune to kde/plasma/whatever regressions, as long as you can configure at least one single global hotkey (or worst-case, run it from the run dialog) to launch your menu. Once I set this up during my kde4 upgrade the 4>5 and 5>6 upgrades as well as X>wayland were no problem in this regard, it should work for other desktops (if you run them) too, and I can even run it from my bare-bones backup weston compositor (launching from wayland-terminal or its run dialog, since last I checked it's too bare-bones to let me configure even a single launcher hotkey).
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2060
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/105