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

[Benjamin Otte <otte gnome org>]

On Tue, May 10, 2011 at 10:46 PM, Brian Cameron
<brian cameron oracle com> wrote:
>
> A main reason that there are multiple sets of interfaces is to make the
> free desktop accessibility interfaces widget-set neutral.  A huge
> amount of effort has been invested over the years to make GNOME and KDE
> accessibility interoperable.  By making both GNOME and KDE talk to the
> ATK interfaces, accessibility becomes desktop independent.
>
Yes, there is two ways to do things. A lot of projects try the idea of
defining an abstraction layer and then working on getting that
interface implemented on top of a different interface. wxWidgets or
AWT try that for toolkits, Cairo tries it for rendering methods and
Wine tries it for the Windows interface. KDE has a lot of abstraction
layers too, like Phonon, Solid etc.

Now this approach has, as you pointed out, one big advantage. It
allows writing code to the abstraction layer and the code will then
run unmodified on all supported backends.
It has big disadvantages though. First of all, unless the backends you
target support your API directly, you have to write glue code that
bridges their interface to your interface. And this code will likely
try to fix a lot of subtle differences between those interfaces. And
if a backend is sufficiently different from the interface that you
want to provide, you end up with glue code that looks like a cesspool.
The best example for that is probably Wine. Of course you also need to
find someone to actively maintain that interface with enough knowledge
on both interfaces or it will bitrot. (See my last mail for that
topic.) Last but not least, you end up with some sort of lowest common
denominator interface. You cannot support features that are only
available to one backend, when all the other backends do not support
it. Or you have to write your own implementation of it. So your
interface will never look very appealing to the outside.

And while GTK's ATK interface does provide the huge benefit of
providing an easy abstraction layer, I can also clearly see all the
bad things happening. And not just that, I can see all of these bad
things actually getting worse. Our glue code is in gail. It tries to
fix subtle differences in the interfaces. It does look like a cesspool
of corner-cases. It's basically unmaintained, there certainly is no
core GTK developer caring about it. And it does not gain new features
and only supports a bunch of features of GTK in a very limited way.

> Your suggestion for ATK programs to just use GTK+ directly seems to
> suggest that each widget set should develop its own unique a11y
> infrastructure and mechanisms.  This would be a huge change in direction
> and a huge loss, I think.
>
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,
I just wouldn't rule it out from the start like you seem to do.

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.

Benjamin