Preamble: This post is <i>genuinely</i> not meant in bad faith. I have glanced over the Wayland source, it is very nice, clean code, and I have no doubt at all that the wayland developers are very competent and focused people, and I admire the work they done and the motivation they have.<p>I won't rule out that I don't understand all relevant concepts in wayland yet, if so I'd like to apologize already.<p>Now to the things which - as per the title - frustrate me. The year of "Linux on Desktop" is almost there, as we all know - jokes aside, Linux really gets more and more traction even outside of developers. And while developers are fine to tinker and modify the system, and do workarounds, regular users don't like that and often even can't help themselves.<p>So, here is a list of some applications one expects from a modern desktop OS:<p>- Screenshots<p>- Screen recorders<p>- Password managers<p>- Accessibility helpers:<p><pre><code> - Screen readers
- Application-sensitive keyboard augmentations (i.e. key reconfiguration based on currently focused application)
- Magnifier
</code></pre>
- Remote desktop software (both server and client)<p>Now, as far as I understand the wayland model, _all_ of the above must be handled by the compositor, not by wayland itself.<p>The compositor exists to keep the wayland core small and to not over-generalize concepts to make different window environments, like Gnome, KDE, Xfce etc. work. Instead, each window environment has to implement its own compositor.<p>This is per se obviously okay. But for all of the above points there is no protocol or standard defined, to the best of my knowledge. That means, and appears to be the reality, that all those functions are either missing or are implemented in a compositor-specific way¹.<p>This in turn means that all of the above tools need to be re-written and adapted to each possible compositor, or that each window environment provides the required tooling, or that some outside party defines a standard which all compositors implement which facilitates a common API for all of the above.<p>And this is the frustrating point: we had a really nice ecosystem of tools for all of the above points. Now we don't anymore. And it doesn't appear to me that fixing this is any priority for the wayland team.<p>Now, please help me: do I miss something important, if so please inform me. Otherwise, what would you propose on how to support the wayland team here? I have the impression that even if someone were to provide high quality, working merge requests for parts of the above, they would be rejected due to "security considerations" or that they don't belong into wayland core.<p>Some examples of related bug reports or discussions:<p>* https://gitlab.freedesktop.org/wayland/wayland/-/issues/326
(which links to a very interesting bug in xdg-desktop-portal, where several accessibility-related projects are involved in the comments)<p>* https://gitlab.freedesktop.org/wayland/wayland/-/issues/233<p>* https://wiki.gnome.org/Accessibility/Wayland<p>* https://news.ycombinator.com/item?id=25175894<p>¹ I think there are some exceptions, like wlroots, but I have a hard time understanding which compositor supports wlroots (is there a list somewhere?)