Hi everybody, thanks for the answers, and sorry for the delay of my own one. I will answer this thread to reply both [Accessibility] threads, as current status on both are really similar.
On 12/12/2013 03:41 AM, Matthias Clasen wrote: > > As Bill says, input methods already have a private protocol for > intercepting and processing input events on the server side, and a > similar facility could be added to the private protocol for ATs During these days, I have been doing some research in relation with that, specifically about how third-party (not included on the compositor) on-screen-keyboards could solve the same problem accessibility technologies have. As far as I saw, maliit is one of the third-party osk that did more work in relation with Wayland support. Reading their wiki [1], some of their proposals include define new wayland extensions. Reading what they have right now defined [2], it is really similar to accessibility needs. > . And again, having at-spi using that private protocol and then > offering key snooping to everybody over dbus would negate an advantage > of Wayland, so the user of the private protocol should be the actual > AT, not some multiplexing intermediate layer. Well, if we can consider an on-screen keyboard, or a screen reader trusted clients, but we can't consider as a trusted client the daemon providing accessibility services, then we have a problem. Probably on at-spi2 itself. If the concern about exposing those wayland private protocols are security, then we hit again the problem that at-spi2 allows to access to their feature to everyone. For example, you can use at-spi2 to click any button on any application without any restriction (several automatic tests frameworks are based on it). Probably this is the time to solve that, in general. After all DBUS has security policy support. Hopefully, it could be possible to add a mechanism so ATs would need to authenticate in order to use at-spi2 services. Under that assumption, I hope that at-spi2 could be considered a trusted client. In any case, my conclusion from these two emails is that in order to get those features we would need to define some wayland extensions, no matters if is Orca or at-spi2 the one using it. So with all that in mind, what about a plan like this: a) Start to write accessibility-specific wayland extensions a.1) Start to implement them on a compositors (first on Weston?) b) Meanwhile investigate if it is possible to add security policies on at-spi2, so this can be the trusted client using those extensions. b.1) If that fails, Orca would be the trusted client using those extensions Thoughts? [1] https://wiki.maliit.org/Wayland_Input_Method_System_Proposal [2] https://gitorious.org/maliit/maliit-framework/source/f562ad91ee14680aaafc6401428ef259a9e61598:weston-protocols/input-method.xml -- ---- Alejandro Piñeiro _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel