Re: GtkSocket/GtkPlug accessibility



On 28/12/16 18:33, Emmanuele Bassi wrote:
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;

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



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