Re: Gail next steps (was Re: GTK and ATK)

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.



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

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