Dynamically loading AT and ATK+ [was Re: Comments on GTK+ patches from Atk tarball]

[Bill Haneman <bill haneman ireland sun com>]

Owen Taylor wrote:
> 
> Bill Haneman <Bill Haneman sun com> writes:
> 
> > Hi Owen:
> >
> > Thanks for the feedback.  A couple of these points have come up before,
> > I think, but it's been awhile :-)
> 
> Yeah, its been awhile. :-(. Far too many balls in the air right
> now.
> 
> > > * I don't see the point of GtkAccessible. As it stands now,
> > >   the only thing it has now is a backpointer to the widget
> > >   and no implementation. Is adding more stuff to this
> > >   planned?

Going back for a moment to your initial question:  I have been
pondering a scenario that indeed argues for "adding more stuff" to
GtkAccessible.  It has to do with a requirement that we heard
expressed at the Linux Accessibility Conference last week (and also at
the concurrent California State University-Northridge Conference on
Technology and Disability ("CSUN") conference).

The requirement is for accessibility support to be dynamically
loadable on a running application; for instance I am running a program
and have a problem, I call my co-worker Ed to offer an opinion.  If Ed
is blind, he will need a screenreader in order to see what my app is
doing, but of course I have been running the app without a
screenreader.

A screenreader can be cranked up and connect with a running "SPI", no
problem.  But unless I have been running my app with the runtime
accessibility library loaded, any programmatic accessibility
properties that the app may have provided will have just gone into the
bit bucket, and I will only have the "default" accessibility
properties if I dynamically load the accessibility module.  Of course
one answer is that if I am in an office where AT may ever be needed, I
always load the runtime library... but how friendly is that?  It would
be better if I could somehow keep only the explicitly set
accessibility properties (when running without the runtime library)
and only load the complicated property-computation stuff in the
runtime library on demand.  Thus this order of operations:

1) Start app without libagtk
2) App sets an accessibility property, such as an icon label. 
Skeletal implementation of ATK in libatk stores this property, but
does not load libagtk or compute any other ATK properties.
3) I start a screenreader, which bootstraps the SPI module and causes
the app to dynamically load libagtk (via a method in GTK+ which we
have yet to define ;-)
4) libagtk sets the accessibility factories for Gtk widgets, and sets
a flag that marks the existing GtkAccessibles as stale.
5) The next request for a GTK widget's accessible object (via the AT)
triggers:
5a) the creation of a new GtkAccessible from the new factory;
5b) the copying of the cached explicitly-set accessibility properties
from the old GtkAccessible,
5c) the deletion of the stale GtkAccessible, returning the new
GtkAccessible into whose cache the old preexisting properties are
copied.

This scenario also works for the case where an AT decides to install
new factories for widgets used by a particular application.

In order to do this, there needs to be a primitive cacheing
GtkAccessible instance created for widgets which explicitly set
accessibility properties, so that these explicitly set properties are
available if libagtk is subsequently loaded on demand.

The alternative is to say that in order to support explicit setting of
accessibility properties/hints by an applicaion, libagtk must be
loaded even if there is as of yet no AT listening to it.  I'm not sure
how acceptable this restriction would be, and it would still leave the
problem of dynamically replacing GtkAccessibilityFactory instances
unsolved.  I know that from a AT and AT-user perspective, loading of
AT on-demand is a firm requirement; what is less certain is whether
other users in a "potentially AT-using" environment such as an office,
school, or library, would consider mandatory preloading of libagtk too
burdensome.

The third alternative would be to allow late binding of libagtk when
AT is bootstrapped, without cacheing explicit accessibility
properties.  That means that some accessibility support built into
apps (e.g. any explicitly set accessibility properties) would be
missing if apps were started without loading libagtk.  This is
probably a lot less palatable to the users who need such support.

Note for text below:  
libatk = dependency of GTK+, where wrapper/shell implementations of
ATK live.
libagtk = the dynamically loadable, optional, runtime implementation
library for the "complete" ATK implementation.

To recap:

options:

(1) create stripped-down GtkAccessibles inside libatk (not libagtk),
whenever an app sets an accessibility property, and copy the cached
properties when new GtkAccessibilityFactory instances are installed.  
Pros:
Allows late binding of libagtk only when needed, without compromising
AT support in the late binding scenario.  Supports replacement of
factories at runtime, and on a per-app basis.
Cons:
More complex code, and adds weight to the (non-optional) libatk.


(2) Automatically pre-load libagtk if apps set accessibility
properties.
Pros: 
Simple to implement, guarantees availability of accessibility
properties if requested by ATs after app has started.
Cons:
Will add weight of libagtk to all apps that use the ATK APIm whether
needed or not.

(3) Discard explicitly set accessibility properties until libagtk is
loaded (on-demand); allow on-demand loading when requested by AT.
Pros:
Simple to implement, no additional overhead until AT requires it.
Cons:
Inconsistent behavior of some apps depending on when libagtk is
loaded; compromised accessibility information.   

(4) Disallow dynamic loading of libagtk, allow preloading only.
Pros:  Easiest of all to implement, consistent "all or nothing".
Cons:  Forces users to to decide in advance whether AT support might
be needed by the app or not.  


Thoughts?  


-Bill


-- 
--------------
Bill Haneman
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland