[Accessibility] Need to be able to register for key events globally

[Piñeiro]

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