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: [email protected] [mailto:[email protected]] On Behalf Of Mark Doffman Sent: Tuesday, January 13, 2009 4:29 AM To: [email protected] 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 [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
