Wayland works pretty well on FreeBSD and I know at least wlroots compositors work a bit on OpenBSD (though, I suspect anyone on OpenBSD would prefer to use their homegrown Xenocara). There are Wayland compositors for Mac, the youtuber Brodie Robertson did a good overview of them a few days ago
Rather than going fully protocol-based (like Waypipe), they used Weston to render to RDP. Using RDP's "remote apps" functionality, practically any platform can render the windows. I think it's a pretty clever solution, one perhaps even better than plain X11 forwarding (which breaks all kinds of things like GPU acceleration).
I don't know if anyone has messed with this enough to get it to work like plain old RemoteApps for macOS/BSD/Windows/Linux, but the technology itself is clearly ready for it.
It depends on what you mean by send. Wayland doesn't have network transparency, there's a bit of a song and dance you have to do to get that working properly. I'm not sure the state of that or of Wayland compositors in general on Mac.
For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.
X's network transparency was made at a time when we drawn two lines as UI, and for that it works very well. But today even your Todo app has a bunch of icons that are just bitmaps to X, and we can transfer those via much better means (that should probably not be baked into a display protocol).
I think Wayland did the correct decision here. Just be a display protocol that knows about buffers and that's it.
User space can then just transport buffers in any way they seem fit.
Also, another interesting note, the original X network transparency's modern analogue might very well be the web, if you look at it squinted. And quite a few programs just simply expose a localhost port to avoid the "native GUI" issue wholesale.
> For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.
I used run and use diskless SparcStation 5s with remote X on 10BASE2 network with the binaries running on Sun E3500s: it worked well enough for non-video web sites running Netscape 3.x. Also Matlab, Octave, Emacs, Vi(m), etc.
I've used it to run backup application GUIs when I was still on DSL (<25Mbps) displaying at home many years ago, and it worked well then. I now have >100Mbps fibre at home, so doubt that bandwidth (or even latency) is worse.
Well, we are using much higher resolutions with much higher frame rates and with more media-rich content.
You surely agree that not having a good compression here is less than ideal.
And it begs the question whether this is indeed the task of the display manager, or it's packing an unrelated functionality that could be better solved by another software.
And we haven't even gotten to sound - should a display manager now suddenly also handle sound?
Of all the things that seem useful to conflate, audio and video does make sense to me, as they so often need to be synchronized. Hell: many monitors also support audio, all televisions do, and the cables used to connect them carry both signals.
Watching a video will be the same as a on Wayland, just sending a video buffer, no?
The icons: you allocate memory on server for that and do not transfare the icon everytime. I think x11 works like that, not sure.
I know GUI lib that you can still compile with freetype disabled. Not everyone need the GUIs you talking about. Everyone is using cars, so lets ban bikes.. it does not need to be like that.
I find X11 RPC useful, simple UI is ok.. you can write programs that will run on any slow or not computer, remotely. Web is not that simple, it is different way of programming, it is not transparent. Web is useful for commerce, but not for controlling machines at factories or pilot cabins. IMO.
I don't really get your first 2 paragraphs. We are talking about connecting remotely to another computer, you can't do much at the other end of a network call with a server allocated buffer - at most you can cache stuff there. But that ain't helping with a video or any kind of fancier than a solid rectangle graphics.
And sure, simple UIs have their place - but they will also work just as well with a proper transport protocol, hell, they would compress even better. So just waypipe that simple UI as you see it fit.
You can cache icons on the server, you do not need to send them over a network, that is it. With video, I'm saying it is a case where wayland is not better, it is just the same.
So you say compression of said icons, etc, is better than caching them on the server? No.. You've mentioned web, but no one does that on the web.
I mean, no one does what you suggest on the web. You do not render a web page to an image and send that to a browser.
To summarize. No one wants X11 transparency to run a web browser. But ok, if someone wants to do that.. X11 still can be more advantegeous over waypipe.
Because on the web we have a very very complex protocol(s) built up over decades to tell a client what to draw locally. That's html/css/js and its scope is far larger than of x draw commands (it's also an application model).
But again, GUI apps don't use X draw commands for the most part, so they are effectively a bitmap/video stream to X's eyes. And what's better to transport a video stream than a format designed for efficient transport of video streams.
Idk given there is no concept of cache. But also I'm looking at GTK menu, it is a simple menu, white bg. May be it can be rendered using draw calls. May be the complex UIs is just fashion and will be gone in a few years. The GUIlib could detect if program is running on a remote computer and reduce the effects, but they will need a concept of network for that.
Also the font rendering. The client could then just send text to the x11 server if it was not vector fonts.
x11 xrdb. With it you can configure say font size on your computer, not on the computer where program is running. Say comp1: 10pt, comp2: 20pt.
It's not "complex UI", it's what programs are generally used. It's gtk, qt, and a bunch of other cross-platform platforms all doing their own thing. They simply render (in a hardware-accelerated way) to a local buffer and that's the only commonality.
Could random draw calls be transported over the network? Sure, and for certain kinds of GUIs it is definitely more efficient than rendering and sending some compressed artifact.
Will XMotif suddenly change the world and apps will be written in it? Absolutely not. It's not even a thing on the minuscule Linux desktop, let alone elsewhere. We are running electron apps and whatnot.
And as I said, this "send draw commands" exists: SVGs are possibly the closest thing, but the web as a whole is literally this with a couple of more features.
>It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.
This is extremely misleading. Web browsers (and games) are the worst case for X11's network transparency. The overwhelming majority of applications belong in the same category as xeyes.
> the original X network transparency's modern analogue might very well be the web
It's Arcan, which solved this problem without sacrificing network transparency at the altar.
> The overwhelming majority of applications belong in the same category as xeyes.
Well, I'm not sure you are using that many xmotif apps. Most of the GUI programs are gtk/qt (and let's be honest, electron) - and they are mostly bitmaps to X's eyes (pun not intended). They don't use draw commands with such a small granularity that network transparency would benefit.
And Arcan is so many things at once I'm not convinced it is a good alternative to Wayland. It has good ideas, but they sort of require the whole package. Meanwhile Wayland is just a minimal API over the Linux kernel API for managing display buffers, that can be extended with additional protocols.
>And Arcan is so many things at once I'm not convinced it is a good alternative to Wayland. It has good ideas, but they sort of require the whole package.
That's a bit of a double edged sword, it's the exact reason why I don't think Wayland is a good alternative to X. Wayland's minimalist attitude towards responsibility is good for one thing, and that's implementing new compositors from scratch. The bare bones compositor will be a long way from usable, but it will be technically complete. The question is, does it matter to me that there are 30 different compositors? Each in various states with their own eclectic featureset with no guarantees given, a la USB-C? Not really. In effect, it did present me with the conundrum of choosing between a half-baked compositor (dwl) or a desktop experience I have literally zero interest in (Gnome/KDE) which left me with a sour taste in the mouth.
Moving beyond that, a real problem with Wayland's architectural minimalism is that a display server does more than simply abstract a single API. It provides a lot of rather complex features, from accessibility to input handling. Not every compositor is capable of handling that kind of complexity, especially if it's to work well. What we will find going forward are two possible futures:
1. The future resembles the present status quo of fragmentation, made worse by time. The compositor archipelago is here to stay, and deploying software in this environment has become excessively annoying. There are 10 different competing libraries for any given category of basic infrastructure, and each library in each category has their own ideas and idiosyncrasies that have to be worked around. Most of them are buggy and incomplete.
2. Smaller compositors effectively die off, and we are left with a single monolithic compositor, back to the modular Window Manager/Desktop Environment. This monster implements the defacto Extended Wayland protocol, where all of the different parts don't quite match each other very well because that's the cost gained from not having vertical integration of complicated components. There's no cohesive rhyme or reason to the design of anything. Thus, the exercise in minimalism has wrought an uglier and more complicated beast than Xorg itself.
I think it's clear Wayland is going to continue to sweep the Linux desktop given its massive corporate backing. But I'm not really compelled to run a bare Wayland compositor under any circumstances, because my Arcan server already works perfectly fine as a Wayland compositor. It works as any number of Wayland compositors running whatever extensions they implement. In effect, no matter which future we end up in, by using Arcan I'm in a much better position than someone running a normal compositor. This fact alone makes me favor Arcan, even before we get into its unique merits.
You need waypipe installed on both machines. For the Mac, I guess you'll need something like cocoa-way (https://github.com/J-x-Z/cocoa-way). Some local Wayland compositor, anyway.
If an application is written for Wayland, is there a way to send its windows to (e.g.) my Mac, like I can with X11 to XQuartz?