5 ms·

> Wayland's design requiring accessibility to be reimplemented by every DE I'm not a big Wayland fan (quite the opposite truly), but I don't know if this is t

by renox 3y ago

> Wayland's design requiring accessibility to be reimplemented by every DE I'm not a big Wayland fan (quite the opposite truly), but I don't know if this is true: if there's an accessibility protocol made for Wayland you could (in theory) have one accessibility SW accessing many Wayland DE. So this isn't a Wayland design issue, but it is an implementation issue: given that many DE have reimplemented the Wayland server, there will be less shared code than with X and more bugs to take into account. Of course given the age of Wayland and that this is still an issue really show the problems with Wayland..

hedora 3y ago
From what I can tell, Wayland makes things much less customizable and much more brittle than X11 (since Gnome, KDE, etc have their own monolithic compositors, and implementing a compositor is much more complicated than implementing a window manager). Since accessibility implies customization (for different people's issues), I think that means the Wayland ecosystem will never support accessibility in practice. Take this redit post from someone with a bum shoulder, for example: https://www.reddit.com/r/linux/comments/17oo98g/wayland_simplicity_and_compositor_complexity_a/ https://www.reddit.com/r/linux/comments/17oo98g/wayland_simp... It's the second hit for "Wayland Accessiblity Protocol", so (I'm guessing) if there is such a protocol, it's extremely obscure and unsupported. The first hit links to these two pages, which are separate lists of wayland accessibility regressions for KDE and GTK: https://www.freedesktop.org/wiki/Accessibility/Wayland/ https://www.freedesktop.org/wiki/Accessibility/Wayland/ https://www.freedesktop.org/wiki/Accessibility/GTK-a11y-revamp/ https://www.freedesktop.org/wiki/Accessibility/GTK-a11y-reva... Of course, even if they address all the things on both lists (which is at least twice as much work as doing it under X11 was) none of that will help the person with a bad shoulder, since they need to mix and match between multiple environments to use their machine.
- addicted 3y ago
  > Wayland makes things much less customizable and much more brittle than X11 Another way to put it is Wayland with a few years of development by a few Linux players (others were building alternatives, while yet others were seeing which one would win out, and yet others were hoping to stay on X11 forever) under its belt, is almost as solid as X11 with many decades of development by all the Linux players. The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong. X11 has been built and expanded for decades and even today is incapable of doing many modern functions that its competitors can. Wayland, OTOH, has almost reached parity with X11 rapidly, does things that X11 is not even capable of, and has a roadmap to reach complete parity.
  - yjftsjthsd-h 3y ago
    That's not "another way to put it", that's a completely different claim. Now if you'd like to make the claim that Wayland is actually developing at a great pace because the first 10 years didn't really count, that's plausibly defensible in some ways, though I'm not sure how we could objectively tell[0]. > The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong. It's also not something anyone is arguing, and something that's not really meaningful because we have Xorg already. At best, you're arguing that Wayland actually has a chance to catch up even though it hasn't in the first 15 years. > Wayland, OTOH, has almost reached parity with X11 rapidly, Debatable but possible, > does things that X11 is not even capable of, Capable of without more extensions, but who's counting? > and has a roadmap to reach complete parity. Yeah, no. Wayland has roadmaps to someday hope to implement a lot of features, but explicitly is designed to not cover others and AFAIK has nobody working on others. There is not, and probably never will be, a wayland protocol to separate the window manager from the display server. There could be but AFAIK isn't any effort to let programs manipulate windows in a portable way (read: there will never be accessibility tools that work on all, or even most, compositors). Wayland is aiming for ~90% feature parity with X, and may someday reach it. --- [0] I can think of some metrics you could use, but they're all hopelessly entangled in confounding variables. For example, we could graph number of X11 window managers released per year against Wayland compositors released per year, but even if you could pin down good numbers they're happening in completely different ecosystems and contexts. Likewise, we could make up a list of features and when they were added, but it seems a bit unreasonable to ex. hold it against X11 that nobody cared about HiDPI for the first ~30 years it existed.
  - josephcsible 3y ago
    > Another way to put it is Wayland with a few years of development by a few Linux players (others were building alternatives, while yet others were seeing which one would win out, and yet others were hoping to stay on X11 forever) under its belt, is almost as solid as X11 with many decades of development by all the Linux players. If Wayland is going to be caught up and have feature parity so soon, then why can't decisions to deprecate and remove X11 be 100% put on hold until then? > The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong. Nobody thinks that. But at the time X11 was missing all of those important features, there wasn't another full-featured option that everyone was rushing to deprecate and remove support for to force everyone onto the immature and incomplete X11, at the expense of things that already worked.
codingkoi 3y ago
> the Wayland server This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol. Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. I think most casual users haven't realized this. KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain). That makes targeting it, whatever "it" actually is, with tools for accessibility all that much harder. That's on top of the Wayland protocol's hostility to things that would make that job easier. We've "secured" the system against use by anyone who doesn't have working eyes or hands. There's no malice there, just the unintended consequence of a system designed by able-bodied people. I'm not even sure X is better in this regard, except that there are solutions like Talon that work there. There are shared libraries like wlroots that can help with consistency, but it doesn't implement everything and not every compositor is using it. Something like accessibility shouldn't be an extension protocol but a core part of the design.
- diegocg 3y ago
  Yes, the lack of an unified server is such a shame. The great selling point of Wayland originally was that it avoided extra context switches by unifying the server and the window manager, this means every window manager must reimplement the server and every protocol by itself. But in an ideal world, we could have had a single Wayland server and window managers being loaded as plugins in the server process.
  - nolist_policy 3y ago
    > But in an ideal world, we could have had a single Wayland server and window managers being loaded as plugins in the server process. It is never too late to start improving things.
    - yjftsjthsd-h 3y ago
      Ecosystem effects mean that it kind of is. Even if we made the software in question (probably on top of wlroots, maybe even just extending wayfire which IIRC kind of already has the plugin system you need?) there is zero chance GNOME or KDE will use it, and I wouldn't bet even on sway or such.
bee_rider 3y ago
It is sort of interesting, having the renderer split from the desktop environment did seem to enforce some level of compatibility. Of course, there’s no reason that this has to be a separate process, it could just have been a library that everybody links to. wlroots looked like it could have been a nice library that provided a lot of that shared functionality, but then Gnome and KDE didn’t use it, so the predictions of fracturing seem to have come true.

by renox 3y ago

hedora 3y ago

From what I can tell, Wayland makes things much less customizable and much more brittle than X11 (since Gnome, KDE, etc have their own monolithic compositors, and implementing a compositor is much more complicated than implementing a window manager). Since accessibility implies customization (for different people's issues), I think that means the Wayland ecosystem will never support accessibility in practice. Take this redit post from someone with a bum shoulder, for example: https://www.reddit.com/r/linux/comments/17oo98g/wayland_simplicity_and_compositor_complexity_a/ https://www.reddit.com/r/linux/comments/17oo98g/wayland_simp... It's the second hit for "Wayland Accessiblity Protocol", so (I'm guessing) if there is such a protocol, it's extremely obscure and unsupported. The first hit links to these two pages, which are separate lists of wayland accessibility regressions for KDE and GTK: https://www.freedesktop.org/wiki/Accessibility/Wayland/ https://www.freedesktop.org/wiki/Accessibility/Wayland/ https://www.freedesktop.org/wiki/Accessibility/GTK-a11y-revamp/ https://www.freedesktop.org/wiki/Accessibility/GTK-a11y-reva... Of course, even if they address all the things on both lists (which is at least twice as much work as doing it under X11 was) none of that will help the person with a bad shoulder, since they need to mix and match between multiple environments to use their machine.

addicted 3y ago
> Wayland makes things much less customizable and much more brittle than X11 Another way to put it is Wayland with a few years of development by a few Linux players (others were building alternatives, while yet others were seeing which one would win out, and yet others were hoping to stay on X11 forever) under its belt, is almost as solid as X11 with many decades of development by all the Linux players. The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong. X11 has been built and expanded for decades and even today is incapable of doing many modern functions that its competitors can. Wayland, OTOH, has almost reached parity with X11 rapidly, does things that X11 is not even capable of, and has a roadmap to reach complete parity.
- yjftsjthsd-h 3y ago
  That's not "another way to put it", that's a completely different claim. Now if you'd like to make the claim that Wayland is actually developing at a great pace because the first 10 years didn't really count, that's plausibly defensible in some ways, though I'm not sure how we could objectively tell[0]. > The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong. It's also not something anyone is arguing, and something that's not really meaningful because we have Xorg already. At best, you're arguing that Wayland actually has a chance to catch up even though it hasn't in the first 15 years. > Wayland, OTOH, has almost reached parity with X11 rapidly, Debatable but possible, > does things that X11 is not even capable of, Capable of without more extensions, but who's counting? > and has a roadmap to reach complete parity. Yeah, no. Wayland has roadmaps to someday hope to implement a lot of features, but explicitly is designed to not cover others and AFAIK has nobody working on others. There is not, and probably never will be, a wayland protocol to separate the window manager from the display server. There could be but AFAIK isn't any effort to let programs manipulate windows in a portable way (read: there will never be accessibility tools that work on all, or even most, compositors). Wayland is aiming for ~90% feature parity with X, and may someday reach it. --- [0] I can think of some metrics you could use, but they're all hopelessly entangled in confounding variables. For example, we could graph number of X11 window managers released per year against Wayland compositors released per year, but even if you could pin down good numbers they're happening in completely different ecosystems and contexts. Likewise, we could make up a list of features and when they were added, but it seems a bit unreasonable to ex. hold it against X11 that nobody cared about HiDPI for the first ~30 years it existed.
- josephcsible 3y ago
  > Another way to put it is Wayland with a few years of development by a few Linux players (others were building alternatives, while yet others were seeing which one would win out, and yet others were hoping to stay on X11 forever) under its belt, is almost as solid as X11 with many decades of development by all the Linux players. If Wayland is going to be caught up and have feature parity so soon, then why can't decisions to deprecate and remove X11 be 100% put on hold until then? > The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong. Nobody thinks that. But at the time X11 was missing all of those important features, there wasn't another full-featured option that everyone was rushing to deprecate and remove support for to force everyone onto the immature and incomplete X11, at the expense of things that already worked.

codingkoi 3y ago

> the Wayland server This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol. Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. I think most casual users haven't realized this. KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain). That makes targeting it, whatever "it" actually is, with tools for accessibility all that much harder. That's on top of the Wayland protocol's hostility to things that would make that job easier. We've "secured" the system against use by anyone who doesn't have working eyes or hands. There's no malice there, just the unintended consequence of a system designed by able-bodied people. I'm not even sure X is better in this regard, except that there are solutions like Talon that work there. There are shared libraries like wlroots that can help with consistency, but it doesn't implement everything and not every compositor is using it. Something like accessibility shouldn't be an extension protocol but a core part of the design.

diegocg 3y ago
Yes, the lack of an unified server is such a shame. The great selling point of Wayland originally was that it avoided extra context switches by unifying the server and the window manager, this means every window manager must reimplement the server and every protocol by itself. But in an ideal world, we could have had a single Wayland server and window managers being loaded as plugins in the server process.
- nolist_policy 3y ago
  > But in an ideal world, we could have had a single Wayland server and window managers being loaded as plugins in the server process. It is never too late to start improving things.
  - yjftsjthsd-h 3y ago
    Ecosystem effects mean that it kind of is. Even if we made the software in question (probably on top of wlroots, maybe even just extending wayfire which IIRC kind of already has the plugin system you need?) there is zero chance GNOME or KDE will use it, and I wouldn't bet even on sway or such.

bee_rider 3y ago

It is sort of interesting, having the renderer split from the desktop environment did seem to enforce some level of compatibility. Of course, there’s no reason that this has to be a separate process, it could just have been a library that everybody links to. wlroots looked like it could have been a nice library that provided a lot of that shared functionality, but then Gnome and KDE didn’t use it, so the predictions of fracturing seem to have come true.