Re: [g-a-devel] Coming to grips with the state of a11y in gtk

[Piñeiro <apinheiro igalia com>]

From: Matthias Clasen <matthias clasen gmail com>

> On Thu, Feb 17, 2011 at 10:03 AM, Piñeiro <apinheiro igalia com> wrote:
> 
>>
>> Although move the gail implementation to gtk has his advantages, why
>> this would be better that just fix them directly on gail? One of the
>> big problems here is the lack of resources, so doing the move would
>> add a extra work that could be used to just fix the problems.
> 
> The move ends one of the biggest source of problems with the a11y
> implementations as they are now: they are separate objects living
> outside of gtk and have to duplicate lots of widget state by listening
> for signals and poking at the widgets from the outside. That is both
> terribly inefficient, and prone to reentry problems. Just look at how
> often gailtreeview iterates over the entire model, e.g....

Ok, so you are proposing a change more deep that I thought.

You are proposing to forget this "proxy" approach on the accessibility
support. As far as I understand you are proposing to implement the ATK
interfaces directly on GTK, so instead of having a GTK widget and his
accessible equivalent, just having a GTK widget implementing the
proper ATK interfaces, right?

I already talked about that in the past (ie [1][2]), but summarizing
the reasons to avoid that:

 * Right now AtkObject is a different object, not a interface
   (although this could change with a new API if we decide that
   worths)

 * Allow to define a11y objects not related with a specific toolkit
   object (ie: fly weight objects on the tree view).

 * Allow to not define a11y object for any toolkit object (ie: I do
   not do that right now, but I always thought that it was not
   required an a11y object for a ClutterEffect).

 * ATK tries to be as abstract as possible, so abstract that could
   expose a11y support for non-glib toolkits. IE: WebKitGTK a11y
   support. It exposes ATK objects for internal webkitcore objects,
   that are C++ classes.

In summary, being able to expose a a11y object hierarchy different
from the toolkit object hierarchy/technology if necessary.

And yes, I know that the gtktreeview and the model iteration is a pain
in the neck from the a11y point of view...

> I haven't particularly checked.
> But if the two are incompatible, they should really take measures to
> prevent running them in parallel, like taking a well-known busname...

Well, Mike Gorse or Li Yuan would know the details better. Not sure if
it is really incompatible, or if it should be compatible and what I
found is in fact a bug.

BR

[1] https://bugzilla.gnome.org/show_bug.cgi?id=614121#c4
[2] https://mail.gnome.org/archives/gnome-accessibility-devel/2010-March/msg00003.html

===
API (apinheiro igalia com)