Re: ATK ,GTK...

[Bill Haneman <bill haneman sun com>]

mongoose magic shiman com wrote:
> 
>   So now this sounds like the AT has to go through a shared library which
> accesses SPI, which accesses the ATK interface. This matches the
> SPIBlockDiagram. What is the "shared library" part though?

The shared library offers a set of C bindings to the SPI, so that the
AT doesn't have to know about the details of the IPC and serialization
protocols used by the SPI implementation (CORBA).

> I am wondering about the neccessity of all these layers though. To me it
> seems the only important layers would be the translation of the widget
> data to accessible data
> 
> Widget Set -> Accessiblity Interface -> AT
> 
> Where -> represents events and the Accessibility Interface translates
> events as neccessary into an accessible format. At the highest level all
> that is being done is translating a graphical interface into an accessible
> interface. Why the need for more layers?

You sound as if layers are a bad thing ;-)

For one thing, accessibility support is not just about events, though
event dispatching is important.  AT also needs to interrogate the
applications about the context of received events, and to explore the
topology of the applications UI.  So just wrapping events and
dispatching them one-way (which could indeed be done with just some
new wire protocol) isn't enough, object-based access to the UI
components is required.

There are lots of design requirements underlying the diagrams, you
might review the GUADEC slides and list archives for some of them. 
But consider the following:

Much AT needs to live in its own process space (with the possible
exception of "driver-type" adapters).  This means that it cannot
access the widget info directly.  Thus AT needs out-of-process
(IPC-based) access to this information.

There are heterogeneous toolkits on the desktop, and at least one
(Java JFC) has its own accessibility interfaces built-in, which are
not inherently available out-of-process and which are not based on
native code.  So the need to bridge to different toolkits, while
presenting a consistent interface to AT, requires that the AT
out-of-process layer be different from the toolkit's own in-process
layer (which uses toolkit-appropriate structures and paradigms).

Also, AT wants to see the "whole desktop", not just one application. 
This implies the existence of some registration function tying
multiple applications together (the alternative being that each AT
would have to solve this problem over again).  Thus the "broker" at
the heart of the SPI.

This results in a simple 3-tier architecture for the IPC which I think
is uncontroversial as far as it goes. (Note that brokering only occurs
when events are dispatched or AT enumerates desktops and applications;
AT queries involving a particular application or widget go direct to
the application and do not pass through the broker, though they use
the same SPI interfaces).

The other "layers" in the GTK process space are tookit abstraction
layers like others used in GTK+.  Defining ATK as a set of interfaces
is important because it defines the interfaces that must be
implemented by or on behalf of custom widgets in order to interoperate
with the accessibility architecture.  The actual implementation is
externalized (in GAIL) for several reasons:  it reduces footprint when
not in use, it removes any dependency of GTK+ applications thenselves
on the implementation library, it minimizes disruption to GTK+, and it
allows ready replacement/substitution/upgrading of accessibility
support without any library or binary incompatibilities.

In other words, the ATK/GAIL/GTK+ separations are more a matter of
componentization of widget set features than they are about "layers"
in the sense of indirection and translation.

-Bill 

> On Fri, 8 Jun 2001, Bill Haneman wrote:
> 
> >
> > >  So let me get this straight. ATK is just the definition of an
> > >interface and GAIL implements this interface. So does GAIL take gtk data
> > >and convert it to be accessed through the ATK interface? That is, does the
> > >Assistive Technology (Screen reader, etc...) access a GUI's data through
> > >the ATK interface without any knowledge of the GUI itself?
> >
> > Yep.
> >
> > >If so then ATK could become an interface standard for AT
> > >devices/applications to access and get information on a GUI.
> >
> > It's certainly an interface "definition", and an open one.  Whether it goes from "spec"
> > to "standard" (in the absence of a standards body ;-) probably has more to do with how
> > widely it is adopted than anything else.
> >
> > The reason that ATK is not going to be the "standard" for adaptive technology
> > devices/apps is that ATK is an in-process interface, and it also includes some API that
> > is intended to be called from the application and not the AT (for instance, many of the
> > "setter" methods for accessibility properties.  The API that AT will use is defined by
> > the SPI, whether or not the GUI uses ATK internally.
> >
> > The SPI maps very closely onto ATK, so there is not a big difference other than the fact
> > that the SPI will be accessed by AT via a shared library that communicates with multiple
> > applications that bridge to it.  (Note that applications that are unable to use the
> > shared library's C bindings can implement the SPI's CORBA IDL via an alternate means if
> > they choose to do so).
> >
> > >Is SPI going to be the solution to access data from a GUI that does not
> > >have an ATK interface? Looking at the diagram it looks like it will rely
> > >on intercepting events sent to and from the GUI.
> >
> > The SPI applies for all GUIs, whether they use ATK internally or some other, similar
> > accessibility API (for instance, Java apps using the Java Accessibility API).  This means
> > that ATs will interact with accessible applications the same way regardless of whether
> > they use ATK or some similar accessibility interfaces at the toolkit level.
> >
> > There are two aspects to this SPI: there is a central accessibility broker that moderates
> > requests to enumerate the accessible applications on the desktop, and relay event
> > notifications from the GUI to listening AT.  However once an AT is notified of an
> > application's existence the AT can and will query the application directly via the other
> > SPI interfaces.  Thus the SPI includes both broker functionality and application
> > interrogation.
> >
> >
> > -Bill
> >
> >
> > >On Fri, 8 Jun 2001, Bill Haneman wrote:
> > >
> > >>
> > >> >  I'm browsing around these accessibility docs and I'm a little
> > >> confused.
> > >> >Are there two projects going on with gnome for accessiblity? An
> > >> addition
> > >> >to GTK to make applications using GTK accessible, and another project
> > >> (ATK
> > >> >I think it's called?) to make applications that don't use GTK
> > >> accessible?
> > >> >Am I correct? Thanks
> > >>
> > >> Not quite ;-)
> > >>
> > >> ATK is a set of interface definitions and wrappers defining
> > >> accessibility.  ATK is not GTK-specific, but ATK does define the
> > >> accessibility interfaces which GTK uses.
> > >>
> > >> In turn, the actual implementation of those interfaces on behalf of the
> > >> GTK+ widgets is in a project called GAIL, which is dynamically loadable
> > >> by a GTK+ application.
> > >>
> > >> Thus:
> > >>
> > >> GTK+ depends on the accessibility interfaces in ATK (thus ATK "defines"
> > >> accessibility for GTK+).
> > >>
> > >> ATK itself has no dependencies on GTK+, thus other toolkits could still
> > >> use ATK as their accessibility interface definition and accessibility
> > >> API.
> > >>
> > >> The actual widget-specific code that implements those interfaces lives
> > >> in another module which is dynamically loadable (GAIL).  If GAIL is not
> > >> loaded, GTK+ widgets will have a default accessibility implementation
> > >> that basically returns "null" information though it nominally conforms
> > >> to the ATK API.
> > >>
> > >> ATK depends on glib, so any toolkits wishing to implement ATK as their
> > >> accessibility interfaces will need to link to glib.
> > >>
> > >> Status:  ATK is basically complete/frozen, GAIL is under active
> > >> development, somewhere around 35% complete.
> > >>
> > >> There is another set of interfaces, still being finalized, called the
> > >> accessibility Service Provider Interface (SPI).  These interfaces are
> > >> used by out-of-process clients to obtain accessibility information about
> > >> running applications.  (ATK can't be used for this since ATK is an
> > >> in-process interface, and can only be used directly within the
> > >> application's own process space).  This SPI can be implemented by any
> > >> toolkit.  In the case of GTK+, the internal ATK interfaces are exported
> > >> to the SPI via the "Accessibility Bridge".
> > >>
> > >> Two diagrams of interest:
> > >>
> > >> http://developer.gnome.org/projects/gap/presentations/GUADEC/gnomeaccess
> > >> architecture.html
> > >>
> > >> http://developer.gnome.org/projects/gap/tech-docs/SPIBlockDiagram.png
> > >>
> > >> Regards,
> > >>
> > >> -Bill
> > >>
> > >> > Garrett Banuk
> > >> >
> > >> >
> > >> >_______________________________________________
> > >> >gnome-accessibility-list mailing list
> > >> >gnome-accessibility-list gnome org
> > >> >http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> > >>
> > >> ------
> > >> Bill Haneman x19279
> > >> Gnome Accessibility / Batik SVG Toolkit
> > >> Sun Microsystems Ireland
> > >>
> > >>
> > >> _______________________________________________
> > >> gnome-accessibility-list mailing list
> > >> gnome-accessibility-list gnome org
> > >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> > >>
> > >
> > >
> > >_______________________________________________
> > >gnome-accessibility-list mailing list
> > >gnome-accessibility-list gnome org
> > >http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> >
> > ------
> > Bill Haneman x19279
> > Gnome Accessibility / Batik SVG Toolkit
> > Sun Microsystems Ireland
> >
> >
> > _______________________________________________
> > gnome-accessibility-list mailing list
> > gnome-accessibility-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> >
> 
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

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