GNOME.org
 

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

On 05/11/2011 08:57 PM, Benjamin Otte wrote:

On Tue, May 10, 2011 at 10:46 PM, Brian Cameron
<brian cameron oracle com>  wrote:

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.


Yes, there is two ways to do things. A lot of projects try the idea of
defining an abstraction layer and then working on getting that
interface implemented on top of a different interface. wxWidgets or
AWT try that for toolkits, Cairo tries it for rendering methods and
Wine tries it for the Windows interface. KDE has a lot of abstraction
layers too, like Phonon, Solid etc.

Now this approach has, as you pointed out, one big advantage. It
allows writing code to the abstraction layer and the code will then
run unmodified on all supported backends.
It has big disadvantages though. First of all, unless the backends you
target support your API directly, you have to write glue code that
bridges their interface to your interface. And this code will likely
try to fix a lot of subtle differences between those interfaces.



And
if a backend is sufficiently different from the interface that you
want to provide, you end up with glue code that looks like a cesspool.
The best example for that is probably Wine. Of course you also need to
find someone to actively maintain that interface with enough knowledge
on both interfaces or it will bitrot. (See my last mail for that
topic.)
Yes, of course there are pros and cons. An abstract layer cost every toolkit to 
implement it. And this is why GAIL needs to be implemented in GTK+ directly
to gather more information.

Last but not least, you end up with some sort of lowest common
denominator interface. You cannot support features that are only
available to one backend, when all the other backends do not support
it. Or you have to write your own implementation of it. So your
interface will never look very appealing to the outside.
ATK has a lot of interfaces, roles and so on which a toolkit does not necessarily 
implement or use all of them.

And while GTK's ATK interface does provide the huge benefit of
providing an easy abstraction layer, I can also clearly see all the
bad things happening. And not just that, I can see all of these bad
things actually getting worse. Our glue code is in gail. It tries to
fix subtle differences in the interfaces. It does look like a cesspool
of corner-cases. It's basically unmaintained, there certainly is no
core GTK developer caring about it. And it does not gain new features
and only supports a bunch of features of GTK in a very limited way.

Then GTK+ is changing its API, it cost a lot of resource to make
GAIL catch up with it, which I think we don't have. So this require
both GTK+ people and accessibility people work on it. And again,
implement GAIL directly in GTK+ will help.

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.


What concerns me a lot is that there is only very few applications
that actually make use of this huge abstraction layer that is AT-SPI.
I'm often thinking that we would have less code to maintain if we
indeed wrote Orca code once for every toolkit we target Orca at
instead of having to maintain a big ATK interface for every toolkit.
(And the same for the other few applications that have accessibility
requirements.)

That would mean we need to have one screen reader for each toolkit, and one
on-screen keyboard for each toolkit and ... Even worse, I can't image what happen 
for applications that use two or more toolkits at the same time.

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