On Thu, Feb 17, 2011 at 11:22 AM, Piñeiro <[email protected]> wrote: > > 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?
First and foremost, I am proposing that we need to have the widget implementation and the a11y object implementation share a bed, so to speak. They need to have access to each others private parts. Even more so, now that we've sealed gtk to make access from the outside harder / more controlled. > 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. All these are great reasons in theory, which have failed miserably in practice, if you ask me. _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
