Comment by ux266478 5 days ago
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?
>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.
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.
Today you would do:
`$ waypipe ssh somehost foot`
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.
> It depends on what you mean by send.
Currently I can:
and get a window on macOS.