Great to read - where are we up to with regards to the long laundry list that voice control software like Talon needs?
It's interesting - if you're going to allow third-party a11y software to control your PC, you need a 'make my wayland compositor do stuff' API.
However, Wayland's intention to explicitly avoid baking specific desktop concepts onto its core protocols make this somewhat of a conflicting design req.
> However, Wayland's intention to explicitly avoid baking specific desktop concepts onto its core protocols make this somewhat of a conflicting design req.
I would say it's slightly worse. Wayland's intention was to explicitly prevent the implementation of those features in the name of security. To implement a protocol with enough flexibility to allow voice control of the general interface would necessitate walking back limitations that were heavily evangelized.
On the other hand, I'm utterly impressed how much more stable Wayland through Gnome and Plasma are over the last year or so, to the point I've switched to it as a primary desktop. They've also been adding protocols like xdg_toplevel_tag_v1 that were seemingly taboo until recently. I'm optimistic about this current batch of programmers. I think they'll manage to sort out accessibility pretty soon.
It's interesting - if you're going to allow third-party a11y software to control your PC, you need a 'make my wayland compositor do stuff' API.
However, Wayland's intention to explicitly avoid baking specific desktop concepts onto its core protocols make this somewhat of a conflicting design req.
Ref: https://github.com/splondike/wayland-accessibility-notes/blo...