Re: GtkSocket/GtkPlug accessibility
Le 27/01/2017 à 15:32, Mario Sanchez Prada a écrit : > […] > > I know I arrive tremendously late to this thread, and I'm not even sure if > this is going to be helpful for your situation, but just in case this is a > small test application I wrote long ago to understand how the whole thing of > AtkSocket & AtkPlug works: > > https://github.com/mariospr/atksocket-atkplug-example I did found your test app when searching info about that, looked helpful if I happened to need implementing something :) > Also, in case it also helps, this is a (long) rant I wrote a while ago too > explaining how we implemented accessibility support in the multiprocess > architecture of WebKit2, also using AtkSocket and AtkPlug: > > http://mariospr.org/2013/02/03/accessibility-in-webkitgtk > > Now, feel free to dismiss all this if it's totally irrelevant :-) No, that looks interesting, esp. as you have included some info about Socket/Plug. Maybe not technical enough, but the example you linked above covers that :) Thanks! Colomban ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GtkSocket/GtkPlug accessibility
Hi, Thanks for those answers. Le 29/12/2016 à 11:51, Alejandro Piñeiro a écrit : >>> But fact is things like MATE-Panel make heavy use of those, so it'd be >>> nice to have it work properly. > > Then perhaps it is about using AtkSocket/AtkPlug on MATE-Panel. But that > is an advice given without looking at all that code. Okay, I'll see then. If it's not something that should be done at the GtkSocket/Plug level and would profit everyone, I might investigate a different hackish solution that might be good enough for the MATE-Panel specific problem. Or see to use AtkSocket/Plug in MATE-Panel's side if needed, we'll see. Regards, Colomban ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GtkSocket/GtkPlug accessibility
On 28/12/16 18:33, Emmanuele Bassi wrote: > Hi; > > On 28 December 2016 at 17:29, Colomban Wendling wrote: >> Hi, >> >> It seems that GtkSocket and GtkPlug aren't tied together at the >> accessibility level: e.g. the ATSPI tree from Accerciser shows them >> separately, and atspi_accessible_get_application() returns the embedded >> application rather than the embedding one. > AFAIR, there's really no mechanism to bridge two separate processes; Not sure if you are talking specifically about GtkSocket/GtkPlug, but just in case that is a general statement: AtkSocket/AtkPlug can be used to bridge two processes of one application from the a11y POV. They were initially created to support some Mozilla plugins, where the plugin was running on different processes, but it was preferred to expose them as a single application from the AT-SPI pov. It is also used on WebKitGTK, where each tab can be a different process. Probably there are some more cases where they are used. > there's not even a discovery mechanism that allows you to know if the > embedded window has any accessibility support, let alone something > ATSPI can consume. Yes thats true. All the current usages of AtkSocket/AtkPlug are based on assuming that the embedded windows are controlled by the embedder, and that they have accessibility support. > Additionally, it's even possible to embed a > sub-tree of a separate process, within different contexts of execution > — e.g. it's entirely possible that the embedder is the window > manager/compositor, and the embeddee is a part of an application > > We'd need a separate interface for ATK and ATSPI to negotiate > capabilities and act as a proxy — and we're already coming up short > with regards to other windowing systems like Wayland. Perhaps it's too early in the morning, but I don't follow this last paragraph. Could you provide a specific example? >> So I'm wondering what should be done here. Should GtkSocket and GtkPlug >> have accessible implementations making use of AtkSocket and AtkPlug, and >> this just hasn't been done yet, or is something else required? Would >> that solve the issue? > It's likely that we'd need something more than that… Last time I checked, GtkSocket/GtkPlug were not really good candidates for providing a default AtkSocket/AtkPlug implementation. As Emmanuele is mentioning, it is likely that something else would be needed. >> I know some people would like to forget about GtkSocket and GtkPlug :) > … but, really, the actual solution is to revise the accessibility > stack in a way that's usable under Wayland. I agree that there are several things on the accessibility stack that needs improvement/reimplementation under Wayland. But still not sure if it is the embedder/embedded window mechanism for applications with more that one process is one of it. But as I mentioned before, probably Im forgetting a specific case. > > And, yes: GtkSocket and GtkPlug can die in a fire, as far as I'm concerned. > >> But fact is things like MATE-Panel make heavy use of those, so it'd be >> nice to have it work properly. Then perhaps it is about using AtkSocket/AtkPlug on MATE-Panel. But that is an advice given without looking at all that code. BR ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GtkSocket/GtkPlug accessibility
Hi; On 28 December 2016 at 17:29, Colomban Wendling wrote: > Hi, > > It seems that GtkSocket and GtkPlug aren't tied together at the > accessibility level: e.g. the ATSPI tree from Accerciser shows them > separately, and atspi_accessible_get_application() returns the embedded > application rather than the embedding one. AFAIR, there's really no mechanism to bridge two separate processes; there's not even a discovery mechanism that allows you to know if the embedded window has any accessibility support, let alone something ATSPI can consume. Additionally, it's even possible to embed a sub-tree of a separate process, within different contexts of execution — e.g. it's entirely possible that the embedder is the window manager/compositor, and the embeddee is a part of an application We'd need a separate interface for ATK and ATSPI to negotiate capabilities and act as a proxy — and we're already coming up short with regards to other windowing systems like Wayland. > So I'm wondering what should be done here. Should GtkSocket and GtkPlug > have accessible implementations making use of AtkSocket and AtkPlug, and > this just hasn't been done yet, or is something else required? Would > that solve the issue? It's likely that we'd need something more than that… > I know some people would like to forget about GtkSocket and GtkPlug :) … but, really, the actual solution is to revise the accessibility stack in a way that's usable under Wayland. And, yes: GtkSocket and GtkPlug can die in a fire, as far as I'm concerned. > But fact is things like MATE-Panel make heavy use of those, so it'd be > nice to have it work properly. As long as you want to keep MATE X11-only, accessibility is probably the least of your worries. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
