[g-a-devel]Dependencies and ATK support for extra-gtk+ widgets

[Bill Haneman <bill haneman sun com>]

In developing ATK support for widgets outside of GTK+ we have come
across some issues of interest to the release team and the wider devel
community.

I list first some information on current accessibility dependencies.  In
short I think it's probably desirable to revert the recent new
dependencies of libgail on gtkhtml2 and provide support via another
means, which leads to the discussion which follows the dependency list. 

Best regards,

Bill

-------------------

(I won't mention glib dependencies since glib is "bedrock".)

Dependencies

atk : nothing to be said here except that gtk+ depends on it.

at-spi : composed of several components:

at-spi/idl:        the at-spi interface definitions.
                   dependencies: Bonobo_Unknown.idl.
at-spi/libspi:     the core implementation of the IDL for GNOME.
                   dependencies: bonobo-activation, libbonobo and atk.
at-spi/at-bridge : the "bridge" from atk to at-spi.
                   dependencies: atk and bonobo-activation, and libspi.
at-spi/registryd : the reference implementation of the at-spi registry.
                   dependencies: bonobo-activation, libspi.
at-spi/util :      a utilities cabinet.  Includes the
"bonobo-magnifier".
                   dependencies: bonobo-activation, libbonobo.  
at-spi/test :      demos and tests, including an integration test.
                   dependencies: hard dependency on libspi and
                   registryd, and the regression test has a soft
                   (runtime only) dependency on libgail.  That
                   dependency can be relaxed when other at-spi bridges 
                   exist, or the regression/integration test could be 
                   moved out of at-spi.  However that might diminish its
                   utility since it's the best way we have of regression
                   testing at the moment.

gail :             gail is the optional runtime library that implements
                   ATK on behalf of "core" GTK+ widgets.  The scope of
                   that support (e.g. which widgets libgail supports) is
                   one of the questions before us now.
                   dependencies: 

                        ( gail for libgtk+ only ) : gtk+ and atk
                        ( include gnome-canvas ) : gtk+, atk,
                                                   libgnomecanvas
                                                   [pulls in libart]
                        ( include gtkhtml2 ) : gtk+, atk, 
                                               gtkhtml2
                                               [libxml2, libz,
gnome-vfs?]                              
  
The build-time requirement for gtkhtml2 is the most problematic since it
moves libgail quite a ways in the build-time dependency chart.

========================

Approaches:

(A1) we can leave things as-is and tolerate the move of libgail to
*after* gtkhtml2, and accept that when using accessibility the extra
shared libs will be linked into gtk+;

(A2) we can move gtkhtml2 support (and possible gnome-canvas support as
well) out of libgail, thus trimming the shared libs substantially and 
moving libgail back down the build order.  If we do this, in order to
allow facilitate libgail code reuse we may either need to export some
libgail headers or possibly add a small bit of API to ATK.

(A3) we can split libgail while maintaining it in one buildable package,
and load optional libraries (libgailcanvas) at runtime (see runtime
loading discussion below);

=====

My feeling is that #A2 or #A3 are more attractive.  #A3 solves the
runtime
footprint concerns but does not move libgail back down the build
dependency tree.  #A2 suggests that we move ATK implementation 
support for extra-GTK+ widgets into the widget packages themselves,
to avoid further proliferation gnome packages.

Before we draw a conclusion on this part of the question, it's worth
thinking about runtime loading behavior.  At present libgail is loaded
as a GTK_MODULE.  That works well for pure-gtk+ programs but is a little
messy for bonobo components at the moment.  However if we split libgail
up rather than making libgail a complete ATK implementation repository
for gnome-2 core, we need a way to load the additional gail-like
capabilities on an as-needed basis.

There are several possibilities here:
(B1) continue to use GTK_MODULES and append on a per-app basis
(B2) use GTK_MODULES to load a bootstrapper which searches for gail-like
libraries as-needed.
(B3) for libraries other than GTK+, have the widget libraries
themeselves
link to gail-like libraries or include the ATK implementations in the
core widget code.

(B1) seems unworkable; (B2) introduces new complexities and it's not
clear
how the search would proceed.  

Our position (Padraig and myself) is that (A2 + B3) is the right
solution, and
it does not change API nor the current GTK_MODULES mechanism for GTK+
support.

-Bill