Re: [g-a-devel] GtkSocket/GtkPlug accessibility



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]


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]