Re: [g-a-devel] The a11y ghetto


A few comments.

(ccing Kjartan, since he did the last few gnome-canvas releases)

At the Gnome summit, Bill Haneman approached Owen and me again about
moving the a11y implementation from gail into GTK+. This was discussed a
number of times already, but it never happened. We hope to achieve a
number of things by this move:

- Make a11y implementations a more integral part of the process of
  adding new interfaces to GTK+.

- Giving a11y implementations access to internal GTK+ apis

- Sharing the maintenance cost among a larger group of people

Yes, this is a good idea.  I think quite a few gail implementations
have some performance issues because sometimes it is not so effective to
get the information via GTK+ API's.  For example, table row moves are
handled as delete and then add events, so the fact that the operation
was actually a move is lost.  Things like this would probably be
easier, faster, and cleaner to implement directly in GTK+.

There are a number of obstacles to this:

- gail currently has a gnome-canvas dependency

My understanding is that the gnome-canvas code was put in gail for
convenience (to avoid having a separate ATK implementation library
for GTK+ and libgnomecanvas0..  The gnome-canvas code probably should
move into libgnomecanvas directly just like the GTK+ implementations
are moving into GTK+.  Sounds like this is what you plan on doing.

- besides the module, gail installs a small library of utility functions

Yes, these are designed to make it easier to implement the ATK functions
for those widgets that implement AtkText.  I think all GTK+ text widgets
use these common functions.  It would probably make sense for these to
become GTK+ interfaces since they hide a lot of the ugliness of
implementing AtkText.

The rough plan we agreed on is this:

1) move the canvas a11y implementation to gnome-canvas to remove
   the gnome-canvas dependency from the gail module

2) move the gail module into the GTK+ tarball as a separate module
3) move a11y implementations from the module into GTK+ itself

This plan does not cover the gail utility library mentioned earlier,
maybe we want to deprecate it in favor of some a11y utility functions
inside GTK+ itself.

Bill agreed to look into the first step. Once that is done, I'll be
willing to work on 2). The last step is something that can be done
incrementally over time, it doesn't have to happen in one step.

I think it is quite possible to get 1) and 2) done in time for the next GTK+ release - the first step should probably be kept on a gnome-canvas
branch until it is clear if the next GTK+ release will be ready in time
for Gnome 2.18. There are certainly other compatibility concerns that I
have not thought about...

Comments ?


Gnome-accessibility-devel mailing list
Gnome-accessibility-devel gnome org

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