Re: [g-a-devel] Gail next steps (was Re: GTK and ATK)

[Piñeiro <apinheiro igalia com>]

On 06/07/2011 03:46 PM, Matthias Clasen wrote:
> So, I've discussed the best way forward for this with Benjamin today.
> Here is a rough 6-step plan for dealing with the 'gail problem':
>
> 0) write tests for accessible implementations
> 1) move modules/other/gail nach gtk/a11y
> 2) add tons of private headers for private structs, to share things
> 3) remove now unnecessary code
> 4) add a11y features support to core libs (mainly pango) - word
> detection, cursor handling etc, share with clutter
> 5) figure out new interfaces for GTK to expose necessary features to
> a11y (and other consumers, such as IM and OSK)
> 6) get rid of gtk/a11y and atk-bridge and use a generic dbus
> marshaller using the new interface
>
> As I've said earlier, some of this is clearly long-term and not
> remotely doable for 3.2. But some of it is; at least steps 0-3.
>
> So, here is the rough roadmap for the near future:
>
> This week, Benjamin and Cosimo review and merge all the outstanding
> CSS feature branches for 3.2. Then I do a 3.1 release. After that, we
> (mainly Benjamin and me, I guess) work on moving the gail code to
> gtk/a11y and doing some initial cleanups in master. The goal is to
> have things back to a more or less working state (I would expect a11y
> to work about as well as it does now, no major improvements yet) by
> mid-July, so we can do another 3.1 release with this before Guadec.

This seems an awesome plan, thanks.

> Further work on steps 4, 5 and 6 can happen later, and does not block 3.2.
>  Comments ?


0) (in relation with being isolated) Don' hesitate to ask to the 
gnome-accessibility-devel list to try to clarify it, bugzilla, or 
propose any specific topic on the a11y weekly meeting [0]

3) I think that it is worth to mention this bug [5], as one of the 
current messiest code on gail is related with the focus. I will try to 
work on clutter about the same [7] (although in the case of clutter is 
no so messy, and it would be also required some change on at-spi2).

4) Is also an awesome plan (proper shared libgailutil replacement).

About 5) and 6) and without the intention of being controversial again ... :

5) Li already mentioned here [1] that ATK is already an abstraction 
layer, so not sure why it is required a new one.

6) This is mostly the same original "merge both interfaces" proposal 
that Benjamin sent to the list. Proposal with some advantages but 
several disadvantages (IMHO). Most of the people involved on the 
discussion were against it, and several questions were not answered 
(like IPC abstraction [2], one-screen-reader per toolkit problem, 
multi-toolkit environment [3]), etc. Taking into account this point, it 
seems that this thread was started in order to communicate a final 
decision instead of creating a real debate. Anyway, as I said, this is a 
long term item, so probably it is still not written on stone, and we can 
debate it again (so you will have another chance to convince the others, 
and the others to convince you, and blabla). And after all, this is more 
or less what Qt is trying to do these days, and Frederik Gladhorn is 
still alive after being present on the *ATK*/AT-SPI2 hackfest.

Again, thanks for your interest and effort.

PS: is there the intention to have any some kind of GTK BoF/Workshop on 
the desktop summit [4]? It would be a good place to talk about this 
again, face-to-face.

BR

[0] http://live.gnome.org/Accessibility/Meetings
[1] https://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00057.html
[2] https://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00058.html
[3] https://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00059.html
[4] https://www.desktopsummit.org/program
[5] https://bugzilla.gnome.org/show_bug.cgi?id=649575
[7] https://bugzilla.gnome.org/show_bug.cgi?id=650669

--
Alejandro Piñeiro Iglesias (API) (apinheiro igalia com)