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

[Brian Cameron <brian cameron oracle com>]

Benjamin:

Overall, I was just trying to suggest that I think we need more analysis
before making a decision.  You raise a number of important issues at the
GTK+ layer, but there are many high-level issues that also need to be
considered.  Cross-free-desktop interoperability is just an example.

Another example is that the ATK abstracts common characteristics of
widgets in a way that is useful to AT programs.  All widgets that deal
with text (labels, entry fields, combo boxes, etc.) all implement the
same AtkText interfaces, providing AT programs a common way to provide
alternative UI's for the end user.  While not trivial, adding ATK code
for a custom widget is a more reasonable approach to making a custom
widget accessible than having to update every AT program like orca to
support it.  If we did not have the ATK, the AT program suddenly needs
to know how to interact with each stock and custom widgets directly
and separately.  This adds a lot of code to the AT program, you see.

On 05/11/11 07:57 AM, 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.

Agreed.

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

Typically the problems and issues we find with GAIL are not situations
where subtle differences are being managed.  Instead, the worst problems
tend to arise when the widget does not directly provide information or
functionality that the ATK interfaces require, and hacks are used.

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

I am sure there are issues, but the ATK was implemented with the GTK+
first in mind.  It was the first widget set that supported ATK.  So,
this was not really the situation in this case.

Obviously, there are issues.  For example, I know there are hacks in
the GAIL Treeview/TextView widgets since they were never designed well
to expose internal data.  Issues like this tend to make the glue code
messy.

But, if we agree that widgets should provide the information that the
ATK wants, then it seems it would be better to just fix the GTK+ widgets
to avoid needing such mess.

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

I do not think your analogy works well here.  The point of the ATK
interface is not to provide a lowest-common-denominator interface.  Its
point is to abstract things so that AT programs can access all widgets
that contain text in a common way.

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

We agree there is a problem here.  I would like to better understand
the situation, though.  For the past couple of years, the GNOME a11y
team has been focused on making accessibility work with D-Bus instead
of CORBA and trying to provide some reasonable accessibility for GNOME
Shell.  These tasks seem to be well underway or starting to ramp down.
So, perhaps you are just highlighting that the accessibility team's
focus should return to GTK+/GAIL, which has been neglected for a while.

> > 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 know that the ATK does contain interfaces that no programs currently
use.  Some of the ATK interfaces were designed with the thought of
future AT programs, such as programs to support dictation.

If we see bugs and problematic corner-cases in these sorts of
functions, it may not be such a problem.  Perhaps we could also
consider eliminating some unused ATK interfaces, especially if they
are particularly problematic.

You do not clarify how the problems and issues you see in the GAIL
code are distributed.  Is it all equally bad?  How is the code that
has the most issues used?

Perhaps if we consider the use-cases that cause the most problems,
we might think of ways to solve the problem more elegantly.

> 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.) But of course I have no idea if that is actually true,
> I just wouldn't rule it out from the start like you seem to do.

Not at all, I agree that we should consider all the alternatives.

> What remains is that we have a problem: The AT code in GTK is so bad
> that it is off by default and nobody is in sight that wants to fix it.
> And that is bad.

Agreed.

I remember that accessibility was originally targeted for GNOME 2.0.  It
did not make it into the 2.0 release.  Instead it went into a follow-up
release.  GNOME was really not usability accessible until a 2.14/2.16
timeframe.  While there are issues at the moment, we seem in far better
shape now than we were in then.


Brian