Re: GTK+ modularization

[Matthias Clasen <mclasen redhat com>]

On Wed, 2006-07-12 at 08:59 +0200, Murray Cumming wrote:
> > This has been discussed a bit at Guadec; and I have started looking into
> > what it would take to allow compiling GTK+ with certain subsets of
> > widgets.
> >
> > My current patch defines a small number of optional subsets:
> >
> > * broken: widgets covered by GTK_ENABLE_BROKEN
> > * deprecated: widgets covered by GTK_DISABLE_DEPRECATED
> 
> Does this also remove deprecated functions, signals, properties, etc. That
> might give an extra few %.

It removes entire source files from the build. Thus no traces of the
removed types remain, no properties, no signals, no classes. You are
right that it would be valuable to also compare the runtime effect
of subsetting. 

> > * specialized: some widgets which turned out to be too specialized to be
> > of general use; e.g. GtkCurve, GtkAspectFrame, GtkRuler
> > * printing: the new printing support in 2.10
> > * recent: the new recent files support in 2.10
> 
> I still think there might be something to be gained by removing ATK stuff.
> Apparently libatk just isn't used if it isn't present at runtime, but
> there's still the AtkObject interface imlmentation, 

the implementations are inside libgail, and are only in memory if the
a11y module is loaded.

> all those keybinding signals, 

keybindings are part of the core GTK+ functionality.

> and presumably some more ATK plumbing that's actually in GTK+
> itself. Maybe it would offer more of a pre-object memory gain than a code
> size gain. Of course, it could be difficult to remove that.

Admittedly, we do have a couple of a11y implementations in GTK+ itself
(for GtkIconView and GtkAssistant), but I'd be surprised if removing
them gave you more than 1% space savings.

> People might want to put #ifdefs in their code so that their build can
> automatically adapt to these platforms. If GTK+ provides the #defines then
> they won't need to build their applications with ./configure
> --enable-maemo-port.

The patch already has defines like GTK_HAS_BROKEN_SUBSET in the new
header gtkconfig.h.