What really frustrates me about Wayland is we're replacing an old system with lots of structural problems with a new system with lots of structural problems, and when it comes down to it X and Wayland are problemy for the same reason: They both farm ou...
-
What really frustrates me about Wayland is we're replacing an old system with lots of structural problems with a new system with lots of structural problems, and when it comes down to it X and Wayland are problemy for the same reason: They both farm out way too much core functionality to extensions, leaving a fragmented vendor ecosystem and disjointed developer experience. We got to do it all over and we made the same mistake! We don't even get to trade up to a DIFFERENT fundamental flaw!
In the current twilight moment the proposition with Wayland is Linux is giving up inbuilt GUI network streaming with the supposed benefit of a system which structurally works better on "unusual" display devices such as phones and VR helmets. However it seems unlikely we'll ever get to USE that benefit, because the hardware you're hoping to target there is hard locked in to Android— not Linux, Android. Unless you can appropriate Android GPU drivers or build Wayland atop SurfaceFlinger, who cares?
-
In the current twilight moment the proposition with Wayland is Linux is giving up inbuilt GUI network streaming with the supposed benefit of a system which structurally works better on "unusual" display devices such as phones and VR helmets. However it seems unlikely we'll ever get to USE that benefit, because the hardware you're hoping to target there is hard locked in to Android— not Linux, Android. Unless you can appropriate Android GPU drivers or build Wayland atop SurfaceFlinger, who cares?
@mcc Quartz Compositor also does not directly support network transparency. I don't think a display server needs to support this, and it is most likely best left to something more suited for the purpose of network extension.
-
undefined Oblomov ha condiviso questa discussione
-
What really frustrates me about Wayland is we're replacing an old system with lots of structural problems with a new system with lots of structural problems, and when it comes down to it X and Wayland are problemy for the same reason: They both farm out way too much core functionality to extensions, leaving a fragmented vendor ecosystem and disjointed developer experience. We got to do it all over and we made the same mistake! We don't even get to trade up to a DIFFERENT fundamental flaw!
@mcc in many ways, it's even worse because for the last 20+ years or so server extensions (as opposed to client-to-client protocols) were largely usable even without proper support from the WM/DE, meaning they were de facto universal (if clumsy to use). With the Wayland approach, instead, everything is meaningless until/unless all compositors agree on implementing it the same way. This has effectively rolled back the ecosystem to the state it was 30+ years ago
-
@mcc Quartz Compositor also does not directly support network transparency. I don't think a display server needs to support this, and it is most likely best left to something more suited for the purpose of network extension.
@ariadne I think my point is that the benefits of Wayland feel, in the short term, relatively virtual.
-
@ariadne I think my point is that the benefits of Wayland feel, in the short term, relatively virtual.
@ariadne Also it does seem to me efforts to make a good network streaming extension will be held back by the same thing that makes a good accessibility extension* difficult, that Wayland just pushes framebuffers and has no sense there are deeper semantics something might want to introspect. Right? A single abstraction could have been used for both screen reader areas and streamable rectangles, but Wayland doesn't include abstractions.
* All I know about the status of this is it's going badly
-
@ariadne Also it does seem to me efforts to make a good network streaming extension will be held back by the same thing that makes a good accessibility extension* difficult, that Wayland just pushes framebuffers and has no sense there are deeper semantics something might want to introspect. Right? A single abstraction could have been used for both screen reader areas and streamable rectangles, but Wayland doesn't include abstractions.
* All I know about the status of this is it's going badly
@mcc X is just framebuffers being pushed around anymore, plus a whole bunch of legacy stuff that no real world applications use anymore for decades. accessibility is handled by the toolkits directly.
that someone is trying to improve on this by integrating screen reader hints and other accessibility features into wayland itself is an improvement over X11.
-
@mcc X is just framebuffers being pushed around anymore, plus a whole bunch of legacy stuff that no real world applications use anymore for decades. accessibility is handled by the toolkits directly.
that someone is trying to improve on this by integrating screen reader hints and other accessibility features into wayland itself is an improvement over X11.
> that someone is trying to improve on this by integrating screen reader hints and other accessibility features into wayland itself is an improvement over X11.
Hi. I think you're talking about my project. It's been on hold for a year now; the last status update was: https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the-wayland-native-accessibility-project/
What I like about my approach is that accessibility tree updates are serialized, unlike any existing platform accessibility API I know of... so they could efficiently be pushed over a network.
-
> that someone is trying to improve on this by integrating screen reader hints and other accessibility features into wayland itself is an improvement over X11.
Hi. I think you're talking about my project. It's been on hold for a year now; the last status update was: https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the-wayland-native-accessibility-project/
What I like about my approach is that accessibility tree updates are serialized, unlike any existing platform accessibility API I know of... so they could efficiently be pushed over a network.
@ariadne You're right that AT-SPI, the current accessibility protocol, is independent of both X and Wayland. And you _really_ wouldn't want to run that chatty interface over a network with any significant latency, though you theoretically could, since it's D-Bus-based. In certain scenarios it's already bad enough doing chatty IPC between local processes, as are other platform accessibility APIs.
-
@ariadne You're right that AT-SPI, the current accessibility protocol, is independent of both X and Wayland. And you _really_ wouldn't want to run that chatty interface over a network with any significant latency, though you theoretically could, since it's D-Bus-based. In certain scenarios it's already bad enough doing chatty IPC between local processes, as are other platform accessibility APIs.
@matt yes i do not personally know the specifics as the toolkits deal with AT-SPI for me. my point is that it’s not part of X11, but clearly people think it is.
-
@mcc in many ways, it's even worse because for the last 20+ years or so server extensions (as opposed to client-to-client protocols) were largely usable even without proper support from the WM/DE, meaning they were de facto universal (if clumsy to use). With the Wayland approach, instead, everything is meaningless until/unless all compositors agree on implementing it the same way. This has effectively rolled back the ecosystem to the state it was 30+ years ago
@oblomov @mcc Yeah, that's very true, and the biggest problems are social and resources not technical. 30+ years ago when CDE/Motif and ICCCM were being hammered out it was between a handful of large vendors who were serious about the high-end workstation market and were willing to throw people at the problem to make their ecosystem work, quickly. That isnt true today, while there are some vendors selling workstations it's not a huge and growing market that is attracting investment (all the money us going to "AI") so there isn't the same pressure to hammer out protocols and code across the desktops as there was 30+ years ago when X11 had the same problems. It is happening, but much more slowly and with fewer people, eg IIUC accessibility only had one or two volunteer maintainers until like a year ago when RH hired an FTE to be able to effect architectural changes. It's all XKCD 2347 all the way.
It's honestly amazing that the Linux desktops are in any way competitive with MacOS and Windows as both of those have _way_ more people than any of the different Linux desktops, so they can just *do* more.