Are you willing to write accessibility support for the new xfce only wayland compositor? How will you get every other wayland compositor to support your non-'wayland core' accessibility extension?
People like to frame things like the waylands are some sort of default and nothing is being lost and no one is being excluded.
Everyone has settled on an accessibility standard (Matt Campbell's). So it's not "your" accessibility protocol, it's already "the" accessibility protocol. This is working as intended IMO: allow things to compete and future in the wild and then pick the fittest.
Right. The push based accessibility that is only supported by GNOME's compositor, mutter, and GNOME's DE's userland as of this last 6 months. I would very happy to hear about even this extension supported under other wayland compositors and software. Do you know of any?
Since you seem informed perhaps you can clear something up for me, when Cambpell says "push full accessibility tree to trusted clients" does that mean you get the entire desktop tree, or only for that application?
Because if you don't get the entire window tree, because you only get the single windows information when that application provides it, it is highly incompatible with existing solutions. They say it is compatible because application developers can create a new virtualized thing themselves. But that's not compatible. And beyond that, it is a "solution" that prevents me from controlling my own computer. I understand GNOME is targeting everyone not just power users. But as a power user I am someone. I am a human being.
And Campbell's assertions that push is more performant than pull and full tree are being backed by arguments informed from problems that don't even apply generally. GTK 4 broke this, not GTK 3. It's not a push versus pull thing. It's wayland architecture focused Gtk4 causing the problem when things are fine in X11 focused GTK 3. ref: https://gitlab.gnome.org/GNOME/gtk/-/issues/6269 a11y: No API for supporting a11y Selection interface , https://gitlab.gnome.org/GNOME/gtk/-/issues/6204 a11y AT-SPI: get_child_count implementation iterating over all children causes freeze for objects with many a11y children
If the XLibre project appears to be making enough fairly-consistent progress for you to be comfortable tossing around some cash, then do gather up some likeminded folks to hire a dev to follow the guidance here [0] and help out!
Do note that I've never tried to croudfund a programmer, but that's something that I have to believe is possible to do.
Given that FDO [0] has been screaming about how Xorg is dead and Wayland is (despite plenty of evidence to the contrary) ready for everyone and every use case for the past like ten+ years, I remain somewhat wary about their opinions regarding Xorg development.
Maybe XLibre will be a damn trainwreck, or maybe it'll be to xorg what xorg was to XFree86. I intend to find out through the testimony of users of XLibre.
[0] ...or maybe just a very vocal subset of the folks at FDO...
Are you also willing to maintain it?