Re: GtkSocket/GtkPlug accessibility

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 28 December 2016 at 17:29, Colomban Wendling <cwendling 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]