openstenoproject
[wayland]: KDE on Wayland
There are many users of plover on KDE. With KDE 6 headed in a Wayland-by-default direction, it would be nice to also be able to use plover without many of the hurdles and hoops to jump through.
Is your feature request related to a problem? Please describe.
Plover on KDE Wayland doesn't work.
To fix this issue, there may be different approaches. It's quite possible that KDE devs adopt the same protocol that is used in #1461, but that solution will not cover Gnome.
The preferred solution is through a portal, and I think that KDE is going to adopt that too at some point.
Describe the solution you'd like
I'd like there to be follow-up work to support Wayland compositors: Kwin and Mutter. I'd also suspect that Smithay-based compositors don't support the same protocols so would support that via portal instead.
Describe alternatives you've considered
Not using plover. There's nothing else remotely similar, and plover seems to rely on protocols that don't seem to be implemented.
Additional context
Add any other context or screenshots about the feature request here.
KDE 6 has been released https://blog.neon.kde.org/2024/02/28/kde-neon-6-available-now/
This is for Gnome. Gnome tends not to do things the way everyone else does, and I think this issue will be fixed years before #1050
xwayland programs accept Plover input, but Wayland native programs don't. For example, Emacs-pgtk doesn't, while e.g. Chromium-based browsers, electron apps and the regular X11 Emacs -- do
Ironically, the plover GUI itself always defaults to fingerspelling with it being a native Qt6 window
xwayland programs accept Plover input, but Wayland native programs don't
this sounds like plover is using the x11 interface for output right? (it's what i would expect, i was positively surprised when you announced everything was working ^^)
KWin is currently still on input-method-v1, while sway is on v2. it's theoretically possible to implement v1 as well, but i've seen some movement in KDE recently and am hoping that improvements will come soon (as in: in the next year maybe?) so it may be wise to wait, especially considering that we seem to be strapped for resources on this front anyways.
i agree though that it's unlikely we're gonna see gnome converge on the same solution, but for KDE and everyone else i still have hope
this sounds like plover is using the x11 interface for output right? (it's what i would expect, i was positively surprised when you announced everything was working ^^)
I was running Emacs with the lucid toolkit.
It isn't Wayland native, so it took me a while to figure that none of the native programs worked.
it's theoretically possible to implement v1 as well,
I think it's probably wise. There's also some chance that kwinft might work, since IIRC it's based on wlroots... But I doubt it's worth it for most KDE users.
So should we close as not planned, given that it's unlikely to be resolved in plover? Or keep it open and then close?
i think we can keep it open, as i said, i still have some hope for kde and wlroots to agree on something that we can then implement. this is less a "it's never gonna happen" and more a "we don't have the manpower currently to do it"
(i'm not a maintainer here so this is not the last word, but for the time being i think it's okay)
ooh, also, since you mentioned portals in your first post: if you have connections to kde or freedesktop and know of new developments in this space do let us know! the RemoteDesktop portal in particular allows keyboard emulation, so it gets us close for at least outputting text, but it currently lacks the crucial ability to (dynamically) set the keymap.
ooh, also, since you mentioned portals in your first post: if you have connections to kde or freedesktop and know of new developments in this space do let us know!
Not anymore I'm afraid. I worked with the Linux foundation at my previous job, but even then not the desktop part...
The crux of the issue is that there are good reasons to have a homogeneous protocol, but they are ironing out details that might not impact projects like plover yet, but might eventually become a huge headache for kwin. There are good reasons for optimism, and I think that if push comes to shove, I could sit down and implement something...
I just haven't done Python in years
I would definitely look at input remapper's code, as it works with Wayland. All it does is create a virtual keyboard for its input
