Re: [g-a-devel] ATK - Signal indicating new AtkObject creation.

["Quiring, Sam" <Sam Quiring windriver com>]

Mark,

Does the Qt QAccessible interface only push accessible objects that are
visible on the screen?  Or is the entire tree pushed at startup?

In the case of Qt, do you need the server-side mechanism described below
(traverse the tree every time there is an update...)?  Or does Qt just
push exactly the stuff that is needed, so that no server-side model is
required?  Is it the responsibility of every accessible application to
field all these signals and maintain a model of the accessibility tree?
If I start up an accessibility app after the system is running, how does
it obtain all the accessibility objects of the current system?  Is there
one accessibility server running on the AT app-side of D-Bus (vs. the Qt
side) that is present at startup and that receives all the pushes and
keeps a model of the Accessibility objects?

Is the Qt QAccessible interface on all the time, even when no AT apps
are present?

-Sam

-----Original Message-----
From: gnome-accessibility-devel-bounces gnome org
[mailto:gnome-accessibility-devel-bounces gnome org] On Behalf Of Mark
Doffman
Sent: Tuesday, January 13, 2009 4:29 AM
To: gnome-accessibility-devel gnome org
Subject: [g-a-devel] ATK - Signal indicating new AtkObject creation.

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
_______________________________________________
Gnome-accessibility-devel mailing list
Gnome-accessibility-devel gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel