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

于 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 :

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]