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 11:22 AM, Piñeiro <apinheiro igalia com> wrote:
>>
>> 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?
> 
> First and foremost, I am proposing that we need to have the widget
> implementation and the a11y object implementation share a bed, so to
> speak. They need to have access to each others private parts. Even
> more so, now that we've sealed gtk to make access from the outside
> harder / more controlled.

Ok, sorry, I misunderstood you (again).

>> 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.
> 
> All these are great reasons in theory, which have failed miserably in
> practice, if you ask me.

Well, elaborating this a little:

 * AtkObject: nothing to say here.

 * fly weight objects: working, ie the cell objects on the tree view

 * filter not required object: yes it is true, nobody is taking care
   of this hypothetical filtering. Anyway, as most AT tools right now
   are reactive (ie Orca), having those objects on the hierarchy is
   not a big issue.

 * abstract non-glib-based-toolkits: JAW-ATK wrapper exposes JAVA a11y
   information using ATK, OpenOffice also expose his internal toolkit
   (vlc?) as ATK, Gecko and WebkitGTK html engines, etc.

1 of 4 is failing. Could you elaborate why this theorical points have
"failed miserably"?

BR

===
API (apinheiro igalia com)