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; 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
