Re: [g-a-devel] Coming to grips with the state of a11y in gtk
- From: Piñeiro <apinheiro igalia com>
- To: matthias clasen gmail com
- Cc: gnome-accessibility-devel gnome org, gtk-devel-list gnome org
- Subject: Re: [g-a-devel] Coming to grips with the state of a11y in gtk
- Date: Thu, 17 Feb 2011 17:22:39 +0100 (CET)
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 ), 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
* 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.
API (apinheiro igalia com)
] [Thread Prev