Re: [g-a-devel] Coming to grips with the state of a11y in gtk

[Piñeiro <apinheiro igalia com>]

From: Emmanuele Bassi <ebassi gmail com>

> On Thu, 2011-02-17 at 09:43 -0500, Matthias Clasen wrote:
> 
>> The current state of affairs cannot be useful for anybody.
> 
> let's also look at the state of Atk's API, and what's required to do to
> create an ATK implementation. when I looked at the accessible
> implementations in GtkSpinner and GtkSwitch I was shocked at the
> verbosity and roundabout way you have to go to implement an AtkObject.

Well, ATK has been really useful during a lot of years. But the fact
is that is has been mostly the same API with minor aditions during 10
years. ATK is still on 1.X, while gtk has evolved to GTK 2.0 and now
to GTK 3.0

There are several things to improve, and also AT developers found
several things that should improve.

This is the reason we are organizing a ATK hackfest this year (well,
in fact ATK/AT-SPI2) hackfest. The page here [1]. I have pending an
official announce, but as I'm a horrible blogger and I wanted to also
create a blog post about it ...

> plus, it's *really* hard to implement an an accessible widget with
> anything else but C - and even there the type definition macros are just
> papering over the byzantine incantations to register factories and such.

I already discussed that with Owen Taylor while solving some bugs
related to St [2]. The factories are not required in this new world
where a11y is fully integrated with the app/toolkit. It was a lesser
evil when gail or other ATK implementation (hail) was an isolated
module. As cally was integrated on clutter, we could remove the
factory-related code from cally. But as this "just works", I prefered
to work on other thinks (priorities).

Anyway, I include this on the a11y roadmap item related to ATK [3], as
it requires to be discussed.

About this "hard to implement with anything else but C" ... well, yes
it is true, but for example, in the case of Javascript, right now is
also hard to implement a GtkWidget subclass without workarounds like
the ShellGenericContainer.

> finally, Atk is strictly dependent on how GDK works - especially with
> regards to events; I'm using Atk in Clutter, but there's a whole layer
> devoted to translating Clutter code into what Atk expects from GDK. for
> an abstract toolkit, that's a nice piece of fail right there.

Yes this GDK reference here [4] is not a good idea IMHO.

Anyway, as a abstract layer, that translation code would be
required. From the specific toolkit event structure (GTK, Clutter,
WhateverTK) to the abstract toolkit ATK event structure. The fail here
is include a GDK reference on the definition of this structure at the
ATK level.

In fact when I was working on that I detected this, but I forgot to
include that here [3].

Anyway, please take into account that ATK was being used on several
toolkits (not only Gtk+ and Clutter), so although there are some areas
that solve be improved, he worked fine as a abstract intermediate API.

> chucking away Atk is not the way, but fixing its glaring issues would
> make implementing a11y directly inside gtk+, and other toolkits, a lot
> easier.

Just for your information, in relation with the ATK hackfest we
created this [5] metabug. As a summary, the ATK hackfest would be
"solve or propose a solution for as much of this bugs as possible".

Feel free to create more bugs there.

BR

[1] http://live.gnome.org/Hackfests/ATK2011
[2] https://bugzilla.gnome.org/show_bug.cgi?id=626658#c9
[3] http://live.gnome.org/Accessibility/Roadmap#Augmented_and_Consistently-Implemented_Atk
[4] http://library.gnome.org/devel/atk/stable/AtkUtil.html#AtkKeyEventStruct
[5] https://bugzilla.gnome.org/show_bug.cgi?id=638537

===
API (apinheiro igalia com)