4 ms·

The thing is that from an outside perspective, Wayland took a wrong turn as well, very early on. It is such a clean base architecture on one hand, on the other

The thing is that from an outside perspective, Wayland took a wrong turn as well, very early on. It is such a clean base architecture on one hand, on the other hand it simply abstracts away lots of stuff and calls it a day. Most relevant to me: any and all accessibility-related APIs. I am quite convinced that Wayland won't ever really take off in its current form. Maybe someone integrates Wayland into a big package with all relevant APIs fixed and documented, and we get rid of the compositor abstraction mess we have. Also, I'm not really convinced that creating Wayland as a totally new development was a good idea. As we all know, greenfield projects to replace existing technology are almost always doomed. But in X's case, this may really be the best solution, I don't know and I'd lean to give credibility here to the (definitely incredibly talented) developers behing Wayland. Just one of lots of examples what's not so polished with wayland¹: https://community.kde.org/Plasma/Wayland_Showstoppers https://community.kde.org/Plasma/Wayland_Showstoppers There are lots of other links (see my comment history). I admit I am a bit sour. ¹ yes we're getting there, but only when all compositors and DEs have implemented their own APIs and solutions to the common problems wayland simply ignores

RunningDroid 3y ago
> But in X's case, this may really be the best solution, I don't know and I'd lean to give credibility here to the (definitely incredibly talented) developers behing Wayland. If I remember correctly the initial spec for Wayland came from the X maintainers because they were tired of X's design flaws.
tmzt 3y ago
I had the thought years back to layer a Wayland-like surface rendering protocol over X using an HTTP UPGRADE like primitive and XIE extended event IDs. Basically it would transform the socket to this new protocol which keeps X atoms under a binary ID prefix. This would keep backwards compatibility, with Xorg DIX replaced with a modern server implementation. This could be modified to a heavy client approach where direct rendering can bypass the server. Or a client can takeover chrome rendering through an extension.

RunningDroid 3y ago

> But in X's case, this may really be the best solution, I don't know and I'd lean to give credibility here to the (definitely incredibly talented) developers behing Wayland. If I remember correctly the initial spec for Wayland came from the X maintainers because they were tired of X's design flaws.

tmzt 3y ago

I had the thought years back to layer a Wayland-like surface rendering protocol over X using an HTTP UPGRADE like primitive and XIE extended event IDs. Basically it would transform the socket to this new protocol which keeps X atoms under a binary ID prefix. This would keep backwards compatibility, with Xorg DIX replaced with a modern server implementation. This could be modified to a heavy client approach where direct rendering can bypass the server. Or a client can takeover chrome rendering through an extension.