-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wayland]: KDE on Wayland #1655
Comments
KDE 6 has been released https://blog.neon.kde.org/2024/02/28/kde-neon-6-available-now/ |
Yep. First official release. |
Relevant related issue: #1050 |
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 |
|
so the new version of Plover doesn't work |
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 |
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 |
I was running Emacs with the It isn't Wayland native, so it took me a while to figure that none of the native programs worked.
I think it's probably wise. There's also some chance that |
So should we close as not planned, given that it's unlikely to be resolved in |
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. |
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 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 |
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.
The text was updated successfully, but these errors were encountered: