Everyone grumps about the network transparency but what I dislike about Wayland is:
1) reliance on hardware acceleration which is not always available
2) The every frame being perfect thing (I far prefer having garbage on the screen temporarily if it lowers the latency for feedback. Latency makes me physically feel sick, I really really hate it.)
3) All the extra compositor specific crap for keylogging, screen recording, etc. It makes sense if you're building an Android competitor and expect people to carelessly throw binaries around but people don't do that on Linux.
I don't think Wayland will ever be a full replacement for me as it lacks network transparency. I really love that about X and with cloud solutions this usecase is becoming more important again.
Unfortunately, with modern toolkits the network transparency is often abysmal. I remember that Qt 3 had awesome performance and Gtk 2.0 had passable performance, bit modern ones feel like they have to redraw everything from scratch by bitmapping every time and would be totally unresposible until they do that.
Can it also stream single programs instead of whole desktops? As I understand it that was still something that wasn't possible. And it's exactly what I use all the time (windows from different systems on one desktop)
Yes, that's it exactly its primary purpose: to replace X forwarding.
> waypipe should be installed on both the local and remote computers. There is
a user-friendly command line pattern which prefixes a call to ssh and
automatically sets up a reverse tunnel for protocol data. For example,
waypipe ssh user@theserver weston-terminal
will run ssh, connect to theserver, and remotely run weston-terminal,
using local and remote waypipe processes to synchronize the shared memory
buffers used by Wayland clients between both computers.
Aha I have to look more into this, thanks. I can't currently use Wayland on most of my systems (it's broken for KDE on FreeBSD which I use the most) so I haven't really spent much time really looking into it. But this sounds interesting, I'm glad this usecase is finally being considered.
'shared memory buffers' sounds like an exploit waiting to happen though. Of course X11 is no better in this regard, an X-Client running on a remote X-Server has complete access to the remote display(s). But this is something that is unfortunately a design flaw from more naive times. And if there had been an X11R7 and onwards it would no doubt have addressed it.
I think part of the problem here is that the same people promoting Wayland have also taken X11 on board to 'maintain' so they have all the incentive to let it die. I'd have preferred to see an organisation that was ready to take it into the future.
The network transparency is dying already, all modern UI toolkits that target X paint every pixel themselves and don't use the X primitives. You the up using thinlinc,vnc,etc anyway unfortunately
The other fatal flaw of Wayland is that it’s support on anything other than Linux is abysmal. I can run an X server on Linux, BSD, Commercial UNIX variants, Minix, macOS, OpenVMS, and even Windows. Heck at one point there was even an X server for DOS!
I'm running FreeBSD myself and there is in fact a working Wayland stack. THe only issue is that the KDE integration is currently broken so I can't use it. But I've been told by people using other DE's and WMs like sway that it works great.
But yes X is a great common denominator. I used it back in the 90s with Xappeal on DOS. Was great at college when we ran out of free X terminals.
1) reliance on hardware acceleration which is not always available
2) The every frame being perfect thing (I far prefer having garbage on the screen temporarily if it lowers the latency for feedback. Latency makes me physically feel sick, I really really hate it.)
3) All the extra compositor specific crap for keylogging, screen recording, etc. It makes sense if you're building an Android competitor and expect people to carelessly throw binaries around but people don't do that on Linux.