| Summary: | Add support for second stroke shortcuts (feature request) | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kglobalaccel | Reporter: | Andrew Shark <ashark> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | 1i5t5.duncan, boredsquirrel, BulletproofBears, fanzhuyifan, mrudolf, nate, riiiis, vedran.furac, xpusostomos |
| Priority: | HI | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Andrew Shark
2024-01-25 06:58:51 UTC
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 *** Bug 488383 has been marked as a duplicate of this bug. *** *** Bug 488271 has been marked as a duplicate of this bug. *** *** Bug 477076 has been marked as a duplicate of this bug. *** As I recall, on the Mac, any menu item can have it configured as a hot key in a global app. But it's hard to imagine the Linux community agreeing on something to that level, the way Apple can bring order. So until Wayland has a global hot keys solution, it's a steaming pile of waste of time, IMO. I'd also like to point out that while KDE has in many places double keys (emacs style bindings), the most important place.. kwin window manager (or is it compositor for wayland, I don't know), doesn't. |