cross-posted from: https://lemmy.world/post/39342270
Well folks, it’s the beginning of a new era: after nearly three decades of KDE desktop environments running on X11, the future KDE Plasma 6.8 release will be Wayland-exclusive! Support for X11 applications will be fully entrusted to Xwayland, and the Plasma X11 session will no longer be included.
Thanks, this is a much more nuanced take than what I’m used to.
Regarding thinlinc: They seem to be on it: https://community.thinlinc.com/t/wayland-tigervnc-and-thinlinc-the-future-of-remote-desktops-in-linux/1755.
Regarding fragmented support: is that true? Why would some CAD software not work everywhere when most other software does? Does the thing really need some specific niche Wayland protocol that’s only implemented on one DE for the time being? And if yes, will that protocol really be the first relevant one to not be implemented across the board? I feel like you’re conjuring to a problem that doesn’t necessarily exist. Do you have an actual concrete example that goes beyond “the subwindow placement for this multi-window program is a bit wonky without impeding usability in the slightest”?
Software compatibility is a problem on X as well, so I’m extrapolating. I don’t expect the situation to get better though. I’ve managed software that caused fucking kernel panics unless it ran on Gnome. The support window for this type of software is extremely narrow and some vendors will tell you to go pound sand unless you run exactly what they want.
I’m no longer working with either educational or research IT, so at least it’s someone else’s problem.
As for ThinLinc, their customers have asked about what their plan is for the past decade, but to quote them: ”Fundamentally, Wayland is not compatible with remote desktops in its core design.” (And that was made clear by everyone back in 2008)
Edit: tangentially related, the only reasonable way to run VNC now against Wayland is to use the tightly coupled VNC-server within the compositor (as you want intel on window placements and redraws and such, encoding the framebuffer is just bad). If you want to build a system on top of that, you need to integrate with every compositor separately, even though they all support ”VNC” in some capacity. The result is that vendors will go for the common denominatior, which is running in a VM and grabbing the framebuffer from the hypervisor. The user experience is absolute hot garbage compared to TigerVNC on X.