GNOME.org
 

Re: GTK and ATK

I have realized that I forgot to include gtk-devel@list in my answer. C&P my answer here, just in case someone is interested. Please, if you want to answer this mail, also include gnome-accessibility-devel gnome org 

===

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]