On 28/12/16 18:33, Emmanuele Bassi wrote: > Hi; > > On 28 December 2016 at 17:29, Colomban Wendling <cwendl...@hypra.fr> 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
