<div dir="ltr"><br><div class="gmail_extra">On Tue, Dec 10, 2013 at 3:29 PM, Piņeiro <span dir="ltr"><<a href="mailto:apinheiro@igalia.com" target="_blank">apinheiro@igalia.com</a>></span> wrote:<br><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">GNOME Assistive Technologies need to be able to listen to key events<br>
globally and have the possibility of consuming them. Example use<br>
cases:<br>
<br>
* Orca's presentation of navigation (Events not consumed)<br>
  - Right Arrow: Speak character moved to (right of cursor)<br>
  - Shift Right Arrow: Speak character selected (left of cursor)<br>
  - Down Arrow: Speak next line<br>
  - Etc.<br>
* Orca's navigational commands (Events consumed)<br>
  - H/Shift + H: Move amongst headings<br>
  - NumPad 8: Speak the current line<br>
  - NumPad 5: Speak the current word<br>
  - NumPad 2: Speak the current character<br>
  - Etc.<br>
<br>
Current solution: The Orca screen reader calls AT-SPI2's<br>
atspi_register_keystroke_<u></u>listener(). AT-SPI2 then notifies Orca of key<br>
events it receives from the toolkit implementation of ATK method<br>
atk_add_key_event_listener(). Applications then have to wait for Orca<br>
to consume the event or not. This requires two DBUS messages. Toolkit<br>
authors want to abolish this. That's fine, *if* we have an<br>
alternative. Do we?<span><font color="#888888"></font></span></blockquote><div><br></div><div>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. 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.<br>

</div></div></div></div>