Re: [g-a-devel] GTK and ATK

[Piñeiro <apinheiro igalia com>]

On 05/11/2011 02:57 PM, Benjamin Otte wrote:

Well most of the paragraphs were already answered by Brian, but I would 
like to add a comment here.What concerns me a lot is that there is only 
very few applications

> that actually make use of this huge abstraction layer that is AT-SPI.
> I'm often thinking that we would have less code to maintain if we
> indeed wrote Orca code once for every toolkit we target Orca at
> instead of having to maintain a big ATK interface for every toolkit.
> (And the same for the other few applications that have accessibility
> requirements.) But of course I have no idea if that is actually true,
Well, there are some issues with this proposal:
  * It is true that right now the AT more mature and maintained is 
Orca, but we still have other AT tools, like Caribou, Dasher (if it 
migrates to libatspi), MouseTrap/OpenGazer, Gnome Shell magnifier 
(Joseph is planning to use some AT-SPI features).
  * And although that would be true, I think that our target is "GNOME 
being accessible", and provide a proper framework to do that. Just 
providing support to Screen Readers are limited.
  * In fact, improving the a11y general support would allow to create 
new ATs easily.
  * As you said, one of the current problems on the ATK-toolkit 
relation is that the implementor requires to know both in order to do a 
good work here. But with this proposal you are just moving from "need to 
know about an abstract accessibility toolkit and an specific toolkit" to 
"need to know about screen readers and an specific toolkit". Screen 
readers can be tricky.
  * A lot of people working on those toolkits already know about 
abstract accessibility toolkits. IE: LibreOffice and Gecko has also 
support for IA2. Most of the people that are already implementing 
support for IA2 are also implementing ATK support.

> I just wouldn't rule it out from the start like you seem to do.

Well, sorry if thats what you extracted from my comments. It is clear 
that current accessibility status is not good enough. Thats a fact. And 
we all are open to proposals to solve that. I was just trying to discuss 
your proposals in a constructive way.  Sorry if I failed at that.

> What remains is that we have a problem: The AT code in GTK is so bad
> that it is off by default and nobody is in sight that wants to fix it.
> And that is bad.

Well, just a comment here. As Brian said one of the reason is that a lot 
of effort these years were used on the at-spi IPC switch. During those 
years we were in a situation were nobody put a lot of effort on at-spi 
as it was using an deprecated technology, and at-spi2 was in a "work in 
progress" status. Mike Gorse was starting to try to solve the just on 
the last iterations. (And DBUS is still, in general, less performant 
that CORBA).

Anyway, one of the big problems in performance preventing to having by 
default the a11y on is related to the treeview. Specifically the 
"adding/removing a lot of rows on the model means a performance penalty" 
[1]. As Li said a11y treeview implementation is really complex because 
the lacking way to expose the internal information of the treeview. I 
hope that this gail-to-gtk move could help to improve this, and mainly, 
simplify gailtreeview implementation. Right now it is mostly an 
gtktreeview replication.

BR


[1] https://bugzilla.gnome.org/show_bug.cgi?id=577098


--
API