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

[Piñeiro <apinheiro igalia com>]

On 05/10/2011 04:28 PM, Benjamin Otte wrote:
> So I've been thinking about accessibility in GTK for a while (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.

Well "fix the somewhat sad state of the code we do have" is one of the 
reason we are organizing an ATK/AT-SPI2 hackfest.
http://live.gnome.org/Hackfests/ATK2011

I mean that the accessibility team are aware that the status could be 
better, and we want to improve that situation, so the people with 
experience on ATK/AT-SPI2 is trying to propose solutions at the short, 
medium and long term.

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

As Brian and Federico already said, this was made by design.

In summary, before going into detail, IMHO, you are basing your analysis 
in GTK accessibility.  ATK is intended as a abstract accessibility 
interface to multiple toolkits. Right now it is used not only on GTK+. 
It is used on Clutter, Gecko, OpenOffice, Webkit, Unity, etc.

But probably the reason is that the description here:
http://developer.gnome.org/platform-overview/stable/atk

is somewhat gtk-oriented, and we would require to rephrase it.

> 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.

As Federico mentioned in his answer, ATK tries to abstract the UI 
interaction with any toolkit using a gobject technology. And at that 
moment, AFAIK, used GTK to orient the design. So this is the reason it 
is so similar to GTK, but in the same way, possible to be adapted to 
other toolkit.

> 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.

In general ATK is an abstracted library, so a lot of that "adding extra 
functionality on other => require to add extra functionality on the 
other" is not true in all the additions.

> 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.

Again: you are basing you analysis from an GTK POV. ATK is also used by 
Gecko, Webkit and Clutter developers for example.

> 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?)

This is not true. Matthias Clasen usually review and take care of 
accessibility issues at GTK, although it is true that it is not his main 
task.

But, it is true that in general, accessibility is not the most 
attractive feature of any toolkit.

But, sincerely, I don't see how having a "unified API" could solve that.

> Due to the previous reasons, the ATK interface is bitrotting. The code
> is crashing more and generally behaving buggier with every release.

Really? How did you come to that conclusion? Any specific example?

> 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.

Suddenly ATK API is bad? I though that you said that the problem of ATK 
is that is different/parallel to GTK.

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

See previous and summary comments. IMHO, your analysis is just an GTK 
POV analysis.

ATK was not created just for GTK. Is that would be the case, instead of 
an ATK bridge with AT-SPI, accessibility developers would chose to use 
the same solution that Qt developers is using right now with at-spi2, 
having an gtk-bridge with at-spi insted of an atk-spi bridge.

> 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...)

Sorry, Im not able to follow your reasoning path. Here you agree that it 
would be likely to require and abstraction layer, so ... why remove ATK 
... why it doesn't fulfill that "abstraction role" layer?

> 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.

There are some reasons to have a different object hierarchy for UI 
objects and accessibility objects, see :
https://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00062.html

> 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.

Have I already said that ATK purpose is being an abstract 
accessibility-oriented API and you are basing your analysis on an GTK 
POV? How autogenerate one API from the other would solve the general 
situation in any toolkit?

> 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

This is a unfair comment with respect to current ATK maintainers, mostly 
taking into account that they are also maintaining other accessibility 
related modules and ...

> 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.

... that you are agreeing that maintaining them is mostly a full-time 
job, and the real-life situation is that they can't afford that.

> 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.

Im happy with someone with your experience taking a look to this issue. 
But from my comments you can extract that in general I don't agree with you.

Thanks for taking care.

Best regards.

--
API