Re: ATK ,GTK...

[<mongoose magic shiman com>]

  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?

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?


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
>