Re: Getting libgnome* into shape

[Martin Baulig <martin home-of-linux org>]

George <jirka 5z com> writes:

> We can progressively get rid of the staleness this way just as well.
> When 2.2 comes along, we can wipe a few of the deprecated things.  Just as if
> we got rid of something from libgnome1-compat.  Or we could drop all
> deprecated stuff at that point.  The choice is ours.

And how do you want to remove a function from a library without breaking binary
compatibility. Sure, libtool versioning - but what you're proposing to do is giving
our users a guarantee that we *will* break binary compatibility doing point releases.

> I can do internal evil hacks with libgnome1-compat just as well.  (And
> believe me I will have to do evil hacks in several things I maintain)  That
> is not at all an argument for libgnome1-compat.

And as soon as an app is fully ported to GNOME 2, that app doesn't need to link against
it anymore. Plus, we don't need to keep compatibility in libgnome1-compat in the same
strict way than in the core libraries. I can also imagine that when we're doing 2.1,
libgnome1-compat won't be used anymore anyways.

> > > There are many other reasons for the _DISABLE_DEPRECATED macros rather
> > > then an extra lib which Owen mentioned in his mail.  We don't need to
> > > list them here again.
> > 
> >         I don't find any of Owen's points very convincing - but I'll reply
> > to them later.
> 
> Another issue is that we already used _DISABLE_DEPRECATED in libgnomeui,
> in 1.x and actually even in 2.0.  To deprecate single methods.  So we in fact
> had BOTH methods, because libgnome1-compat alone couldn't cut it.

This is actually an argument _for_ moving things into libgnome1-compat.

Because I just realized that we may need the _DISABLE_DEPRECATED macros in libgnomeui
in future - to deprecate a GNOME 2.0 method in GNOME 2.1.

This means that libgnome1-compat will contain the code which was already deprecated at
the time GNOME 2.0 was released - and that _DISABLE_DEPRECATED will be used in future
2.1, 2.2, 2.3 .... releases to deprecate stuff which was non-deprecated in 2.0, but
which we need to support until 3.0.

Since we need to support all this stuff until 3.0, I think it's even more important not
to confuse developers here - code which is in libgnome1-compat will go away soon - but
code which is _DISABLE_DEPRECATED will stay until 3.0.

> There are two pieces of API which are just as applicable to if you use GConf
> or if you're using bonobo_config with the gconf monicker.  (or not, they're
> just for getting paths).  They could be for all I care dropped as well.
> Else, it's actually bonobo-conf that's adding API to libgnome*, not the other
> way around.  And I can't see a reason for removing that.  Though I suppose it
> would make a lot more sense to make that initialization optional.  So that
> only people that use it actually init it.

You added an explicit GConf dependency to all GNOME 2 applications - that's different to
the implicit dependency through bonobo-config which we had before.

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)