https://bugs.kde.org/show_bug.cgi?id=480304
Duncan <1i5t5.dun...@cox.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |1i5t5.dun...@cox.net
--- Comment #9 from Duncan <1i5t5.dun...@cox.net> ---
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).
--
You are receiving this mail because:
You are watching all bug changes.
