Re: GTK+ modularization

Matthias Clasen 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
My current patch defines a small number of optional subsets:

* broken: widgets covered by GTK_ENABLE_BROKEN
* deprecated: widgets covered by GTK_DISABLE_DEPRECATED
* 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

Omitting all optional subsets yields a 16% smaller,
omitting only broken, deprecated and specialized still comes up 10%
smaller - I'm not entirely convinced that these numbers justify the

In the graphical debian-installer, where GTK+ is used over the DFB backend, symbol stripping is performed before the libraries are packaged in the installation ISO and this allows to get smaller installatio ISOs. I wonder if even more space on the instalation media could be saved with the modular approach you're proposing.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]