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

[Li Yuan <lee yuan oracle com>]

于 2011/5/10 22:28, Benjamin Otte 写道:
> 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.
I don't see ATK interfaces has anything to do with the bugs you said. It 
is an abstract layer. If you are suggesting that GTK+ implements ATK 
interface directly then I am totally agree with that. Matthias has point 
this out : 
http://mail.gnome.org/archives/gnome-accessibility-devel/2011-February/msg00003.html 

> 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...)
ATK is that abstraction layer, why do we want another?
> 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.
As people pointed out, ATK is an abstract layer which is supposed to 
work not only for GTK+, but many other toolkits.
> 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.
Actually we have. And many people cares about ATK are getting together 
for ATK hackfest 2011 for the next version of ATK. And again, I don't 
think ATK has anything to do with the problem you said.

> 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.)
If you are talking about the GTK+ accessibility implementation 
(currently GAIL), then I agree with you. ATK is an abstract layer, but 
GAIL is the implementation for GTK+.

>   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.
Talking about GAIL, I agree that we don't have enough resource to work 
on that when GTK+ are changing its API. This may need efforts from both 
GTK+ people and accessibility people.

Li