GNOME.org
 

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


Benjamin:

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.

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.

Your analysis seems to not consider this at all, and instead seems to
assume that all free software accessibility work is done in a GNOME
or GTK+ vacuum.

Brian


On 05/10/11 09:28 AM, Benjamin Otte wrote:

Hey,

So I've been thinking about accessibility in GTK for a whie (since it
broke all the time during the unstable GTK 3 development to be exact).
And I've been wondering how to fix the somewhat sad state of the code
we do have. Unfortunately I have no idea how to solve it, but I have
an opinion about what the problem is.

The TL;DR version is this:
I think the problem is the fact that we support a separate API for
accessibility.


Now for the long version:

Currently there are two APIs that developers can use to interact with
applications that run GTK:
1) The official GTK APIs - see http://developer.gnome.org/gtk3/stable/
2) The official ATK APIs - see http://developer.gnome.org/atk/stable/
Both of these provide a very similar functionality. For example, to
write a function like
   void toggle_switch (GtkSwitch *switch);
you can use GTK like this:
   gtk_switch_set_active (switch, !gtk_switch_get_active (switch));
or you can use ATK like this:
   AtkObject *object = gtk_widget_get_accessible (GTK_WIDGET (switch));
   atk_action_do_action (ATK_ACTION (object), 0);
You can easily find more examples for this. Also, while both cover
most of the other's functionality, both of them provide functionality
that can not be achieved using the other's API.

Now, why is this a bad thing? There are multiple reasons. Of course,
the most obvious reason is that it is a duplication of work. If you
add functionality to one of these APIs, people also want it in the
other API. So you have to write and test code twice. Not only this,
you also have to wrap your mind around two different philosophies on
how to design an API - one of which you've probably never used
yourself and don't ever intend to. And maybe you even have to argue
with two maintainers about various details.

Another problem is that there's a huge imbalance in the amount of
users of the given APIs. While there are thousands of developers using
the GTK APIs to write applications, there is very few developers using
the ATK APIs to write applications for GTK. With way more eyes looking
at the GTK side, they are more polished, better documented, less buggy
and a lot more featureful. Also, the whole design of GTK internals
focuses on these.

Even worse, there is not a single GTK core developer that has a
personal interest in the ATK interface to GTK. I would even go so far
as to claim that developers do just the absolute minimum required to
be able to tick the "[x] accessibility" checkbox in the feature list.
Now this is especially bad because there is nobody available that can
and does give feedback on design questions about internals when it
comes to the ATK APIs. (examples: Is it a good idea to adapt the
allocation automatically based on margins? Or will this conflict with
what AtkComponent does? Does using Cairo to do drawing conflict with
ATK in any way?)

Due to the previous reasons, the ATK interface is bitrotting. The code
is crashing more and generally behaving buggier with every release.
This was not that much of a problem while the GTK API remained mostly
stable during the GTK 2 cycle, but turned a lot worse when we did the
API break leading to GTK3. And since we want to accelerate GTK
development, I don't think it is getting better. But then, it
certainly can't get a lot worse. Everybody not using programs that
require the ATK interface just doesn't use it. And because ATK is
pretty much only used by the accessibility interface, more than 90% of
the people fall into that category. Which is a vicious cycle: People
don't use the API because it is bad and because the API is bad, people
make sure not to use it.


So now after describing the problem, let me look at possible solutions.

The easiest solution of course is to just drop one API. If we dropped
ATK (which is the only option really, unless you want to rewrite all
the thousands of applications like the Gimp and Inkscape to use ATK
exclusively), you can only toggle a switch by using
gtk_switch_set_active(). There is no accessible object for doing the
same thing anymore. Of course, everybody that does now use ATK would
need to completely redo their application to actually use the GTK
APIs. It would also likely point out gaps in the GTK interfaces so
large that some things that are easy with the ATK interfaces are
impossible with the GTK interface. And it might end in a way that
somebody writes an abstraction layer for common required functionality
of apps that used to use ATK and ships it as a separate library. (And
that library might be named gail...)

We could merge the APIs so that in the end there is no duplication
anymore and the design philosophies from GTK and ATK are preserved as
well as possible. To stay with the switch example, it might turn out
that it's actually important to provide a gtk_switch_toggle() function
as opposed to just having gtk_switch_set_active(). This of course will
mean that we need to reorganize code and probably will end up
deprecating quite a bit of functions. And of course this is quite a
bit of work.

We could also try to auto-generate APIs. Especially now that we have
introspection capabilities it might be tempting to have a
postprocessing step that generates the ATK interface from the GTK
interface or vice versa. Of course, this would still be a duplication,
we'd just make it more bearable by automating it. And of course it
requires somebody sitting down and actually writing this tool.

And finally we could continue as-is and keep maintaining two
interfaces. If we do this, we need to find people interested in and
willing to actively maintain the ATK interface. First of all, that
would require someone with intimate knowledge of GTK, as that
developer would need to influence the direction of the project.
Code-wise, it would first require bringing its quality up to par and
after that it would require constantly keeping track of GTK
development and adapt the interfaces to new features. (Fwiw, I would
suspect that would involve roughly a full-time job for an experienced
GTK developer.) And I don't think anybody is up for that task. And
that would mean the ATK interface remains in the sorry state it is in.


This is where I am at the moment. I'm looking for solutions to the
problem, but none of them makes me very happy. So if anybody has an
idea about how to fix this, please tell me.

Benjamin
_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]