v3 unusable for me
v3 unusable for me
Posted Dec 2, 2024 4:15 UTC (Mon) by pizza (subscriber, #46)In reply to: v3 unusable for me by NYKevin
Parent article: GIMP 3.0 — a milestone for open-source image editing
> 2. Edit a file with vim.
So... you're complaining that a *console* application that has special X11 clipboard integration doesn't work when not running it under X11?
And how is vim and gnome-terminal not implementing OSC-52 a deficiency of _Wayland_?
> If Wayland is going to go around proclaiming itself to be the Way Of The Future, and claiming that all use cases have been solved, then I should not have to put up with all of the above. It should Just Work, the way that X11 Just Works.
There's no technical reason vim in a terminal window couldn't interact with your local wayland session over an SSH tunnel. But just like someone had to write that code for console-vim to integrate with X11's clipboard, someone has to write something similar for wayland.
(I use wayland-forwarded-over-ssh on a daily basis, clipboard and all. Granted, not with console vim or gnome-terminal)
Posted Dec 2, 2024 4:23 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (8 responses)
You seem to be misunderstanding. I am not interested in litigating the details of whose fault it is. I was asked for a use case that works under X and not under Wayland, and I provided all of the relevant details. If Wayland, GNOME, and Vim want to play the blame game over it, rather than actually solving my problem, that makes me even less interested in switching from X.
Posted Dec 2, 2024 12:15 UTC (Mon)
by pizza (subscriber, #46)
[Link] (7 responses)
I suppose the more relevant question is -- why doesn't this JustWork(tm) thanks to xwayland?
Does it work when not using gnome-terminal? (personally I've _never_ liked gnome-terminal, but the nice thing about terminal emulators is that there's a _lot_ of options to choose from)
Filed a bug report?
> If Wayland, GNOME, and Vim want to play the blame game over it, rather than actually solving my problem, that makes me even less interested in switching from X.
It _should_ work based on your description. So yes, the "blame game" is absolutely appropriate here, because the rest can't fix something that's not broken with their own codebases (or specifications, in the case of Wayland).
It's not like software magically writes (or fixes) itself. Especially for your very niche use case. (I'm glad you acknowledge that, because the userbase of vim, much like my preferred emacs, is pretty much a rounding error on top of desktop linux's overall rounding error...)
Posted Dec 3, 2024 4:00 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
I believe it does, actually. But it rather defeats the point if you're going to (to the best of my understanding) run a full X server on top of your Wayland server. You might as well just go back to X - that way, you're running less code.
> Filed a bug report?
I gave you a link to a bug report filed in 2018 for the gnome-terminal problem, which remains open to this day. I would not know where to begin with any other part of it - it is not a "bug" that Vim prefers to integrate with the system that works (X11) over the system that isn't universally supported (OSC-52, incompatible with gnome-terminal).
Posted Dec 3, 2024 11:03 UTC (Tue)
by paulj (subscriber, #341)
[Link] (3 responses)
One way to view it is that Wayland is then providing a much nicer, modern code-base for graphics development. Given the people who worked on the graphics backends for X11 servers are largely the same people who developed Wayland and work on it now, it seems safe to conclude these people much prefer their own modern code for that work than the many decades old Xorg/XFree/X etc code-base. And then the X11 support is entirely in user-space, doesn't touch hardware, and can even be isolated - a step forward.
I'd be happy-ish with a rootless XWayland that gave a seamless X11 experience on top of a Wayland graphics server. I'd be happier still if Wayland had support for bridging clipboard, etc. between different XWayland servers and Wayland clients (as XPRA does between a remote X11 server and the local display server).
We don't have that though, and there doesn't seem to be anyone working on creating a seamless transition solution. (Also, there doesn't seem to be an xpra equivalent for Wayland - xpra is so useful and important to me).
Posted Jan 4, 2025 10:04 UTC (Sat)
by daenzer (subscriber, #7050)
[Link] (2 responses)
You raise good points, I'd just like to add a bit to this last one. Wayland compositors can survive a crash of the rootless Xwayland server, and start a new one the next time an X client tries to connect. If the same crash happens in Xorg (the majority of code in Xwayland is DIX code shared with Xorg and other DDXen), the session is gone.
> I'd be happy-ish with a rootless XWayland that gave a seamless X11 experience on top of a Wayland graphics server. I'd be happier still if Wayland had support for bridging clipboard, etc. between different XWayland servers and Wayland clients
Since you write "different XWayland servers", I suspect you actually mean non-rootless Xwayland[0]. My colleague Olivier Fourdan has put quite a bit of work into making non-rootless Xwayland usable for running X desktop environments, e.g. the -fullscreen / -decorate command line switches. However, there is indeed no clipboard / primary selection integration yet. There's https://gitlab.freedesktop.org/xorg/xserver/-/issues/1640 about this, per Olivier's comment it might be trickier than we think though. Maybe you want to chime in there.
Anyway, I doubt there are any Wayland protocol limitations for this, it's mostly a matter of Xwayland propagating the clipboard / primary selection contents between the Wayland and X sides. Olivier's comment sounds like the challenges are rather on the latter side.
If you really mean rootless Xwayland, you'd have to clarify what you mean by "seamless". Note that rootless Xwayland can't behave 100% the same as Xorg in all cases by design. E.g. it can't get any mouse input while the cursor isn't over any X client window, or any keyboard input while no X client window has keyboard focus, just like any other Wayland client.
[0] Although in theory a Wayland compositor could launch multiple rootless Xwayland servers, in practice this would be tricky, I don't know of any attempt at this yet.
Posted Jan 6, 2025 17:21 UTC (Mon)
by paulj (subscriber, #341)
[Link] (1 responses)
Maybe I have the terminology wrong, but by "between different XWayland servers" I meant between different rootless XWayland servers. Given that XWayland is the decades old X11 code-base, and likely not that great security wise PLUS the fact that X11 has effectively no security betweeen clients (keyboard snooping particularly) what I would _like_ to have for the bold new Wayland future is the ability to have the following, for backward compatibility of X11:
- Run m:n Xwayland servers for X clients
I.e., given the security issues of X11, I'd like to be able to have clients isolated to their own Xserver, or otherwise have "groups" of applications of equivalent security sensitivity share the same XWayland rootless server. And then:
- Have some kind of bridging agent that forwards events (clipboard, mouse, etc.) between these rootless servers, as required/desired.
I should be able to disallow the forwarding of certain kinds of security-sensitive events from certain XWayland servers, e.g. getting the clipboard contents, or capturing the keyboard, or other client data capture.
Maybe this isn't a practical security model, I don't know. If it's not, I still want that seamless Wayland <-> rootless XWayland bridging agent though! :)
Posted Jan 6, 2025 17:35 UTC (Mon)
by daenzer (subscriber, #7050)
[Link]
> I still want that seamless Wayland <-> rootless XWayland bridging agent though! :)
If a Wayland compositor launches multiple rootless Xwayland instances, it's the responsibility of the compositor to propagate stuff between them as needed. With a single instance, compositors should already be doing what can be done.
Posted Dec 3, 2024 13:00 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
> I believe it does, actually. But it rather defeats the point if you're going to (to the best of my understanding) run a full X server on top of your Wayland server. You might as well just go back to X - that way, you're running less code.
You might be running less code. But you're running buggy unmaintained code. Running a full X server on top of Wayland is the only SUPPORTED way to run X, nowadays.
AIUI, the X Server is now a full-blown Wayland compositor/client/whatever, and all the X video drivers etc are abandonware. So yep, if you want X, run a full-blown X server. But the only supported server today runs atop Wayland, with no hardware support of its own ...
Cheers,
Posted Jan 4, 2025 9:28 UTC (Sat)
by daenzer (subscriber, #7050)
[Link]
That's not obviously true (though TBF it could be, depending on the specific Xorg drivers and Wayland compositor you compare), Xwayland is significantly smaller than Xorg + drivers (largely because the corresponding functionality is handled by the Wayland compositor instead of by the X server).
Also, "minimal amount of code overall" isn't the ultimate metric to decide this. Wayland supports features which X can't, and this gap will keep widening. There are reasons why Wayland was created instead of continuing to improve X.
Posted Dec 2, 2024 15:31 UTC (Mon)
by paulj (subscriber, #341)
[Link] (5 responses)
> "So... you're complaining that a *console* application with clipboard integration for the standard UI-clipboard-protocol across Linux and pretty much all Unixes for decades doesn't work in Wayland"
Wayland is now *40%* of the age of X11, and 53% the age of the X11R6 release, and it's still breaking a lot of stuff / not providing equivalent alternatives for reasonable and not uncommon workflows.
Posted Dec 2, 2024 16:26 UTC (Mon)
by pizza (subscriber, #46)
[Link] (3 responses)
Please read what I actually wrote.
Meanwhile: https://github.com/vim/vim/issues/5157 (and https://github.com/vim/vim/pull/9639 for a lot of history and technical details)
Also, this was trivial to find:
https://github.com/jasonccox/vim-wayland-clipboard
Posted Dec 3, 2024 10:57 UTC (Tue)
by paulj (subscriber, #341)
[Link] (2 responses)
A lot of this could be fixed if Xwayland was just a completely seamless part of Wayland. But for some reason it is not.
Posted Dec 3, 2024 20:26 UTC (Tue)
by pizza (subscriber, #46)
[Link] (1 responses)
By "longstanding desktop integration protocols" you mean "All of X11 (and its innumerable extensions)"
Wayland _does_ have an answer (ie protocol) for tackling this particular problem, but it's not their fault vim still hasn't implemented it.
> A lot of this could be fixed if Xwayland was just a completely seamless part of Wayland. But for some reason it is not.
The "some reason here" is the same problem one runs into when running multiple/nested X11 sessions -- clipboard synchronization between them won't happen without explicit synchronization.
The technical explanation here is that xwayland automatically synchronizes the wayland and x11 clipboards... but only if the clipboard operation comes from a window that has focus. The vim-in-a-terminal doesn't have a window to be in focus, therefore the synchronization doesn't happen. Note that graphical-vim doesn't actually interact with the wayland clipboard either! There's no technical reason why that can't be done (as evidenced by those plugins) -- they just haven't written/integrated the code to do that yet.
Posted Dec 5, 2024 4:30 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
There have been a lot of words written in this thread but these seem to be the most relevant ones, and ones that everyone agrees on, there is all the pieces of a way for clipboard integration with apps through the terminal that works remotely but it hasn't all been wired up yet in a way that works for Wayland everywhere that has been implemented for X11, so edge cases and workflows exist that work with X and not Wayland, which was the original question. I'm not sure what more can be said, it's not really that surprising, X has been around for nearly 40y and has had ? billions? poured into the ecosystem over that time, Wayland has a small team and a fraction of the resources, although they have the benefit of knowing their requirements before they started.
Posted Jan 4, 2025 10:14 UTC (Sat)
by daenzer (subscriber, #7050)
[Link]
When X was a similar age as Wayland is now, it only just got ground-breaking features such as support for anti-aliased text rendering or compositing, which we take for granted now and which Wayland supported from day one (just like other features which X got even later). (Not to mention Wayland supports features which X still doesn't, and in some cases can't — one reason why Wayland was created in the first place)
My point is mainly that this kind of comparison based on "it took N years to make use case foo feasible in bar" isn't very useful. The things to do always exceed the capacity of people to do them, and the duration / order in which things are done depends on many factors, a big one being what people happen to decide to spend their precious time on.
Posted Dec 2, 2024 16:17 UTC (Mon)
by tzafrir (subscriber, #11501)
[Link]
Is there any way to make wl-copy (or equivalent) over ssh?
BTW: wl-copy is not exactly "wayland". It is "wl-roots" (right?). This extra fragmentation is also slightly annoying.
v3 unusable for me
v3 unusable for me
v3 unusable for me
v3 unusable for me
v3 unusable for me
v3 unusable for me
-- including 1:1 (a dedicated XWayland server for each client)
v3 unusable for me
v3 unusable for me
Wol
v3 unusable for me
v3 unusable for me
v3 unusable for me
v3 unusable for me
v3 unusable for me
v3 unusable for me
v3 unusable for me
v3 unusable for me