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

[Mark Doffman <mark doffman codethink co uk>]

Quiring, Sam wrote:
> Mark,
> 
> Does the Qt QAccessible interface only push accessible objects that are
> visible on the screen?  Or is the entire tree pushed at startup?

AFAIK A QAccessible is created for all existing QWidgets. This doesn't
necessarily mean that they are all pushed to the client, but in my (Very
early) Qt-AT-SPI Bridge this is the case.

> 
> 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?

My intentions for the Qt-AT-SPI bridge is that no tree traversal will be
neccessary. QAccessibleBridge has a signal (Callback)
notifyAccessibilityUpdate that should inform the bridge of all new and
removed accessible objects. You can find out more about the Qt interface
by looking at http://doc.trolltech.com/4.4/accessibility.html.

Its not the responsibility of the application to maintain a model of the
accessibility tree. What I was asking for were signals that would make
it easier for the ATK-AT-SPI-Bridge library to maintain the model.

> 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?

Well the updates are part of a caching mechanism. There is also a method
call (getTree) that gets the data initially.

There is one D-Bus daemon (Server) that is running from startup and
keeps track of all the available accessible applications. An AT would
query the registryd to find all the accessible apps. The registryd also
updates ATs about new accessible applications when they are started.

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

I believe so yes. The basic Qt A11y modules are a core part of Qt, which
I think means they are always loaded. (I know nothing of Qt 3 which may
be different)

> 
> -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