Re: Get rid of deprecated widgets

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-12-05 at 13:04 +0100, Mathias Hasselmann wrote:
> Am Mittwoch, den 05.12.2007, 12:17 +0100 schrieb Mikael Hermansson:
> > Hello! Some thoughts
> > 
> > For years now there has been widgets that is deprecated in Gtk+
> > 
> > GtkList
> > GtkCList
> > GtkFileSel
> > GtkCTree
> > GtkItemFactory
> > 
> > Imho it really is time to kill this or atleast add an option in
> > Makefile/configure to not include them as default.
> > 
> > If there still is apps that using this old API(is there any???) they
> > should just copy&paste it to theyr project or just migrate to the new
> > widgets.
> 
> I am also supporting this idea for a long time: There is no point in
> deprecating code, if you plan to support it forever. Regarding ABI
> stability: That old code could be moved into libgtk-compat-2.0.so.
> 
> So programs that still want to use deprecated widgets:
> 
> - link against an old version of gtk - for what other reason gtk is
> using libtool's -version-info switch?
> - link against libgtk-compat-2.0.
> 
> Its really pointless to pay of this old stuff everyday, when none of
> your daily programs uses those old and deprecated symbols.

The only way to make this backwards compatible is to make
libgtk-2.0.so.0 have the deprecated symbols and link to
libgtk-no-compat-2.0.so.0 which doesn't. Then normal apps will keep
working, and apps that don't need compat widgets will need to link with
-lgtk-no-compat-2.0. Of course, this would only be ABI compat on
platforms with late symbol binding, like ELF. 

However as long as any library you use needs (or accidentally links to)
the compat lib this will pull in an extra library which will slow down
all symbol resolves and require an extra private page per process. This
is far worse than some unused code on the disk which is not even paged
in.

A possibly interesting approach would be to put all the deprecated code
in another ELF section and place that section at the end. This will mean
that the deprecated stuff will be in one continous place and might make
paging in non-deprecated code slightly more efficient and less seeky.
I'm not sure you would be able to measure the difference this would make
though...