[Kde-accessibility] Re: Documentation about ATK and AT-SPI

[Bill Haneman]

...
> I have some questions that I forgot to add to the mail:
> 1. Is it necessary to use the two classes AtkRegistry and AtkObjectFactory 
> when bridging to ATK or is it possible to create the AtkObjects in an other 
> way? The use of these two classes is extremely difficult if your widgets are 
> _not_ glib-based.

It's not absolutely necessary.  I would recommend using AtkObjectFactory
however, and then writing something similar to AtkRegistry which uses
something other than the GType system to identify the widget/object type
that an AtkObject is being created for.  In other words you can keep the
AtkObjectFactory and the AtkRegistry concepts without requiring that
your lookup-widgets have a GType.

> 2. Why is there an AtkDocument within ATK but no Document interface within 
> AT-SPI? How do the AT-clients get the access to the DOM?

They don't - because we haven't found it very useful with the current
generation of Linux/Unix applications, and we haven't got a good
standard ABI for w3c DOM available.  So far this has not been a
significant problem since direct access to the DOM is only really useful
to assistive technologies that have specialized knowledge of the details
of certain applications - in other words it tends to be application
specific, which reduces its usefulness to us at least in the short
term.  We think that eventually it may become a useful and powerful
facility but only in addition to the other APIs which we are using more
generally.

> 3. The documentation of AtkDocument does only say that it's possible to 
> enquire a gpointer to the DOM. Therefore I suppose we need to convert a 
> Qt-based DOM tree to a glib-based DOM tree. Is that correct?

No; we need a desktop-wide standard for the DOM tree before this API is
truly useful.

> 4. The same for AtkStreamableContent: I assume a Qt application that bridges 
> to Atk would need to convert a Qt based stream into a Glib based stream. Is 
> that correct?

AtkStreamableContent does return a GIOChannel object, so you'd need to
do the same.  However the two aren't that different, they rely on
standard POSIX capabilities on the backend anyhow so I don't think it
would be hard to bridge them.  This is another API that isn't getting
heavy use yet so we could defer implementing it for KDE in the first
edition of KDE-accessibility, I believe.

> 5. I know that AT-SPI is dependend on any Corba-implementation and that ATK is 
> dependend on glib. What are the exact dependencies of the library that 
> bridges between these two?

The existing atk-bridge implementation links to the following libraries
when compiled for GNOME on X11:

libspi (from at-spi)
libSM
libICE
libX11
libbonobo-2
libbonobo-activation
libORBitCosNaming-2
libIDL-2
libORBit-2
libpopt
libgthread-2.0
pthread
libgailutil
libgnomecanvas-2
libart_lgpl_2
libpangoft2-1.0
libgtk-x11-2.0
libgdk-x11-2.0
libatk-1.0
libgdk_pixbuf-2.0
libpangoxft-1.0
libpangox-1.0
libpango-1.0
libgobject-2.0
libgmodule-2.0
libglib-2.0
libXtst

Many (maybe most!) of these are probably not really needed and are
getting pulled in because our dependency tracking isn't as smart as it
ought to be, for instance libgnome-canvas-2 and libart_lgpl_2, and the
gtk+ libraries (which atk-bridge doesn't actually use!).  If these are
really a problem I think we can probably remove those dependencies or
only conditionally load them.  Up until now we haven't had a lot of
motivation to fix the 
dependencies since for GNOME we always end up loading libgail alongside
atk-bridge, and libgail does need the gtk+/gnome-canvas/etc. libraries.
We do use the PangoAttributes struct from pango, but otherwise we
don't call pango inside atk-bridge.

My own guess as to the modules we really are using in atk-bridge (and
lumping together the above libraries that come from the same module)
looks rather shorter:

 * at-spi
 * glib
 * X11
 * bonobo-2
 * bonobo-activation
 * ORBit-2
 * pthread
 * ATK
 * pango (for the PangoAttribute struct)
 * Xtst


However that's all opaque to the AT client and to the application, the
only limitation this poses is that in order to use atk-bridge you must
have those libraries installed on your system.  For most KDE
distributions this will be the case, unless for some reason your
distributor isn't including the GNOME libraries.

regards,

Bill

> Gunnar Schmi Dt
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE++VLcsxZ93p+gHn4RAnPpAJ9LzmBwi+vIhXYxGiTZpwQEPiydowCZAV4k
> Etw8XERvxMTLcsoPiLNDob8=
> =hnOr
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list at gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>