Re: [g-a-devel] Cross desktop environment event capture for assistive technologies.



On 07/12/16 07:28, chrys87 web de wrote:
Howdy,

Sorry i have no concrete solution  for that. But i found a good blog that gives a talk about privileged 
access to wayland. Maybe there is someuseful information:

http://www.mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/

I just skimmed it a little, and seems interesting, thanks for sharing.
Will read it when I get the time to do it properly.


LibWSM looks like a try to implement  that stuff. Maybe its a good point to start. But the last commits are 
over 6 month old.

Maybe the guy that implement  global hotkey management in gnome have similar  problems and you could give a 
talk to them?

By "global hotkey" do you mean gnome keyboard shortcuts like these?
https://wiki.gnome.org/Design/OS/KeyboardShortcuts

AFAIR, it is handled by gnome-shell, independently of wayland spec.


Cheers chrys

Cheers, and thanks for the link.



Am Mo. Dez. 5 12:31:19 2016 GMT+0100 schrieb Alejandro Piñeiro:
On 05/12/16 00:43, Luke Yelavich wrote:
Hey folks.
I am working on accessibility for Unity 8. One thing that we need to solve is 
input event capture/processing for Orca. Whilst things work well enough with 
Qt via its X QPA plugin, the Mir QPA plugin does not do any form of keyboard 
snooping, therefore when using Orca with Qt apps under Mir, Orca's commands 
cannot be used. I am pretty sure the same applies for Wayland as well. 
Yes, the same applies for Wayland. It is one of our oldest TODOs. We
even had some email threads about the topic on wayland-dev some years
ago, without too much success. The thing is that they are open to
discuss it, but they didn't give too much hints about how to implement
it, and we should be the ones doing it.

FWIW, the issue is not only about snoop input events, but also about
synthesize input events.

I know 
in the case of Qt's Mir support, the developers do not want to add any form 
of keyboard snooping such as is present in Gtk/Clutter/Qt via its X QPA 
plugin.
Depending on who you ask, that also happens on gtk, but even on X11.
Fortunately, after our insistence, whey kept it on X11. Future on
Wayland is uncertain.

I'm wondering whether anybody has done any work to spec out a cross desktop 
solution for this problem. My understanding is that any solution would not 
involve working on Wayland/Mir directly, since the compositor/shell is the 
arbitor of all things input. Instead any solution would be implemented in the 
compositor/shell, so mutter, KWin, and the unity 8 shell.
Yes, the first step, as far as I remember the chats, would be solving it
first on the compositor. For Wayland-GNOME, would be gnome-shell.

Without having tried to spec something out myself, I don't think it would be 
that complex, probably something over DBus that allows an assistive 
technology such as Orca to register its interest to process input events with 
the shell, at which point it is notified again via DBus when an input event 
needs processing, and signals the shell appropriately.
About exposing it through DBUS, at-spi already provides the API. On the
ancient times, it was implemented using the X extension XEvIE. When that
become unsupported, it was reimplemented with a combination of snooping
and event polling.

On a ideal world, we would like to reuse the existing at-spi API so Orca
and any other AT could use it, reimplementing it with "something"
available on Wayland.

 I guess this si 
something that would need amending an atspi spec somewhere, or would this be 
more along the lines of XDG?
As I mentioned, at-spi already includes the client API (obviously,
perhaps it could be improved). What it is missing is the Wayland/Mir
part, that as you mention, it is more a XDG thing. The more promising
thing (the "something" I mentioned before) I found is this:
https://www.x.org/wiki/Events/XDC2014/XDC2014DodierPeresSecurity/

It is promising because although the presentation point accessibility as
one of the main affected, it mentions that affects other use-cases,
meaning that we could get more traction.

Unfourtunately I didn't have time to take a deep look to this proposal.
I don't know about their current state either.

Finally, other place to take a look to are screen on keyboards. They
face similar problems, and I bet that there are Mir-based platforms with
some kind of screen on keyboard (Ubuntu Touch?)

Thanks for the interest, and good luck

[1] http://www.freedesktop.org/wiki/Software/XEvIE



_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel gnome org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]