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
Hi,
On Tue, 2013-12-17 at 11:23 +0100, Piñeiro wrote:
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.
A bridge to connect existing accessibility
Not currently.
I'm not sure what you mean with consumed. Do you mean that a not
consumed event is still received by the client that has the focus
while a consumed one is not?
If so, i guess a protocol could be developed where the compositor
sends an event with the key that is pressed and then the
On 12/11/2013 07:14 PM, Giulio Camuffo wrote:
Not currently.
I'm not sure what you mean with consumed. Do you mean that a not
consumed event is still received by the client that has the focus
while a consumed one is not?
Yes, means that. On the example with Orca (GNOME screen reader), if you
Piñeiro wrote:
On 12/11/2013 07:14 PM, Giulio Camuffo wrote:
Not currently.
I'm not sure what you mean with consumed. Do you mean that a not
consumed event is still received by the client that has the focus
while a consumed one is not?
Yes, means that. On the example with Orca (GNOME screen
On Tue, Dec 10, 2013 at 3:29 PM, Piñeiro apinhe...@igalia.com wrote:
GNOME Assistive Technologies need to be able to listen to key events
globally and have the possibility of consuming them. Example use
cases:
* Orca's presentation of navigation (Events not consumed)
- Right Arrow: Speak
GNOME Assistive Technologies need to be able to listen to key events
globally and have the possibility of consuming them. Example use
cases:
* Orca's presentation of navigation (Events not consumed)
- Right Arrow: Speak character moved to (right of cursor)
- Shift Right Arrow: Speak
