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

[chrys87 web de]

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/

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?

Cheers chrys


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

-- 
Gesendet von meinem Jolla