> 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 %. > * 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, all those keybinding signals, 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. > Omitting all optional subsets yields a 16% smaller libgtk-x11-2.0.so, > omitting only broken, deprecated and specialized still comes up 10% > smaller - I'm not entirely convinced that these numbers justify the > effort... > > There is a number of issues with the patch > - specialized currently has a dependency on deprecated, since > GtkInputDialog uses GtkOptionMenu. Replacing them with GtkComboBox is > somewhat risky, since the GtkInputDialog struct exposes members pointing > to the option menus (although they are not marked as public). > - it turns out that we never deprecated the old file selector, at > it is not protected by GTK_DISABLE_DEPRECATED. > - the "specialized" subset is somewhat weakly defined. > - the patch adds gtkconfig.h which has defines for the included subsets. > I don't think we need runtime checks for included subsets, since a > missing subset will almost always prevent successful linking anyway. 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. It also make it easier to make sure that the GTK+ examples and demos build, so that you can distcheck a subsetted GTK+. > But maybe the .pc should have some variables that can be used to check > for subsets. > - The docs need to be updated to explain the subsets, and tell for > each widget in which subset it belongs. > > Comments ? Well done. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
