Dependencies and ATK support for extra-gtk+ widgets
- From: Bill Haneman <bill haneman sun com>
- To: gnome-accessibility-devel gnome org, gnome-devel-list gnome org
- Cc: gnome-2-0-list gnome org
- Subject: Dependencies and ATK support for extra-gtk+ widgets
- Date: Thu, 13 Dec 2001 12:03:30 +0000
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
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.
(I won't mention glib dependencies since glib is "bedrock".)
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.
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
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.
( gail for libgtk+ only ) : gtk+ and atk
( include gnome-canvas ) : gtk+, atk,
[pulls in libart]
( include gtkhtml2 ) : gtk+, atk,
The build-time requirement for gtkhtml2 is the most problematic since it
moves libgail quite a ways in the build-time dependency chart.
(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
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
(B3) for libraries other than GTK+, have the widget libraries
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
how the search would proceed.
Our position (Padraig and myself) is that (A2 + B3) is the right
it does not change API nor the current GTK_MODULES mechanism for GTK+
] [Thread Prev