From: Matthias Clasen <[email protected]> > On Thu, Feb 17, 2011 at 10:03 AM, Piñeiro <[email protected]> wrote: > >> >> Although move the gail implementation to gtk has his advantages, why >> this would be better that just fix them directly on gail? One of the >> big problems here is the lack of resources, so doing the move would >> add a extra work that could be used to just fix the problems. > > The move ends one of the biggest source of problems with the a11y > implementations as they are now: they are separate objects living > outside of gtk and have to duplicate lots of widget state by listening > for signals and poking at the widgets from the outside. That is both > terribly inefficient, and prone to reentry problems. Just look at how > often gailtreeview iterates over the entire model, e.g....
Ok, so you are proposing a change more deep that I thought. You are proposing to forget this "proxy" approach on the accessibility support. As far as I understand you are proposing to implement the ATK interfaces directly on GTK, so instead of having a GTK widget and his accessible equivalent, just having a GTK widget implementing the proper ATK interfaces, right? I already talked about that in the past (ie [1][2]), but summarizing the reasons to avoid that: * Right now AtkObject is a different object, not a interface (although this could change with a new API if we decide that worths) * Allow to define a11y objects not related with a specific toolkit object (ie: fly weight objects on the tree view). * Allow to not define a11y object for any toolkit object (ie: I do not do that right now, but I always thought that it was not required an a11y object for a ClutterEffect). * ATK tries to be as abstract as possible, so abstract that could expose a11y support for non-glib toolkits. IE: WebKitGTK a11y support. It exposes ATK objects for internal webkitcore objects, that are C++ classes. In summary, being able to expose a a11y object hierarchy different from the toolkit object hierarchy/technology if necessary. And yes, I know that the gtktreeview and the model iteration is a pain in the neck from the a11y point of view... > I haven't particularly checked. > But if the two are incompatible, they should really take measures to > prevent running them in parallel, like taking a well-known busname... Well, Mike Gorse or Li Yuan would know the details better. Not sure if it is really incompatible, or if it should be compatible and what I found is in fact a bug. BR [1] https://bugzilla.gnome.org/show_bug.cgi?id=614121#c4 [2] https://mail.gnome.org/archives/gnome-accessibility-devel/2010-March/msg00003.html === API ([email protected]) _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
