Re: GtkSocket/GtkPlug accessibility
- Date: Wed, 28 Dec 2016 20:33:34 +0000
- From: Emmanuele Bassi <ebassi@xxxxxxxxx>
- Subject: Re: GtkSocket/GtkPlug accessibility
On 28 December 2016 at 17:29, Colomban Wendling <cwendling@xxxxxxxx> wrote:
> 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.
[@] ebassi [@gmail.com]
gtk-devel-list mailing list