[g-a-devel] ATK - Signal indicating new AtkObject creation.
- From: Mark Doffman <mark doffman codethink co uk>
- To: gnome-accessibility-devel gnome org
- Subject: [g-a-devel] ATK - Signal indicating new AtkObject creation.
- Date: Tue, 13 Jan 2009 12:29:02 +0000
Hello everyone,
Currently the AT-SPI and ATK system has a 'lazy' system for creating new
accessible objects.
What we have been doing with AT-SPI D-Bus doesn't fit well with this
system. The idea was that an application would 'publish' its
accessibility information to the ATs, by pushing an entire tree of
accessible objects at application start-up.
This was a design decision for speed purposes. D-Bus is slower than
orbit per-call and ATs spend a-lot of time traversing the accessibility
tree at application start-up.
The current system could be regarded as 'pull' where the only object
sent to the ATs is the root Accessible object and everything else is
pulled from the application. We wanted to move to a 'push' system. To do
this we have a rather complicated, and error-prone, server-side mechanism.
This traverses the accessible tree every time there is an update and
pushes changes to the ATs. For example on application startup it does a
breadth first search from the root object and exports all AtkObjects
that have not already been sent to the ATs. Something very similar
happens when a "child-added" signal is received.
What I'm asking for is that ATK, in the future, moves to a non-lazy,
push based system. This would mean removing laziness, so in the case of
GTK a GailObject would be created with the GtkWidget itself, rather than
only when requested. It would also mean providing a signal to indicate a
new AtkObject has been created.
The Qt QAccessible interface works in exactly this way, and it makes for
a much simpler adaptor to AT-SPI D-Bus.
I'm unsure why Gtk chose the 'lazy' route of object creation. I imagine
its an optimization for memory usage. I'm not sure its a good one
though, as GailObjects, once created, have their lifetime tied to their
implementing GtkWidget. This should mean that once an AT has searched
the Applications accessible objects most of the GailObjects have been
created anyway.
In a more abstract way I think the 'push' model is conceptually better.
Say we were to use the GtkWidget 'realize' signal to delcare that a new
AtkObject has been created. In this case the GtkWidget is 'published' to
the AT at the same time that it starts using screen resources.
This isn't a particularly large change. The addition of a 'created' or
'new' signal to Atk doesn't make much difference to the API. The
difficulty is that all Atk implementations will have to be modified to
emit the signal, and that implementations that lazily create accessible
objects will have to change their behavior.
I'm a fan of having accessibility turned on-by-default in Gnome, so I
don't have the excuse that this will only use extra resources when
accessibility is switched on. This change will use more memory for Gtk
applications. I'd need to do some investigation to find out how much.
I'm not sure what the correct implementation in Gtk is, but its probably
as simple as adding gtk_widget_get_accessible somewhere in the GtkWidget
construction. Gail would have to be modified to emit the new signal
whenever a new GailObject is created. I don't know what the other Atk
implementations do with regards to lazily creating their Accessibility
implementation. I really doubt that the Mozilla or Java implementations
do it like Gtk, so modifying those might be much less politically
volatile, as no extra memory will be used.
Thanks
Mark
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]