Re: Getting libgnome* into shape

[George <jirka 5z com>]

On Wed, Aug 29, 2001 at 03:44:14PM +0200, Martin Baulig wrote:
> > 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.

I must say first:

Happy birthday

And second:

What are you smoking?  You can't be serious to suggest that the actual reason
for not using _DISABLE_DEPRECATED is precisely because it's a good solution
and we wat to use it.  In any case.  I don't think you've read Owens post.
There are several levels of deprecated.  You can _DISABLE_DEPRECATED for
recently deprecated stuff that's on by default for now.  And you can
_INCLUDE_BROKEN for stuff that is off by default now (as you have to do work
to use it).  Now I may be daft here but what about doing just that.
Currently deprecated stuff is

  GNOME_DISABLE_DEPRECATED

When GNOME 2.1 or whatever it's called comes around, we can move some of them
to

  GNOME_INCLUDE_BROKEN

and put the new deprecated stuff into

  GNOME_DISABLE_DEPRECATED

Or we may have several levels of _DISABLE_DEPRECATED.  It's all up to us, but
it's ONE policy not a multitude of weird policies where different things use
different deprecating procedures.  What's so special about stuff that's
deprecated now as opposed to stuff that's deprecated later or in 3.0 or 4.0.
Why should we treat this stuff completely differently from ANYTHING ELSE in
the platform?  That's confusing to me.

> 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.

And what will we do when we turn 3.0?  Come up with a third incompatible
deprecation policy to confuse people even more?

> 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.

No, I added a dependency on GConf just like we depend on libtiff.  Or just
like we depend on GConf through bonobo-config.  Think about it.  It uses the
bonobo-config gconf monicker, thus depending on gconf.  There are more lines
in the picture but we STILL depend on GConf.  GConf is part of the platform
and the core applications depend on it.

Not to mention that since there is none of GConf internals, headers or
anything else exposed through libgnome*, we can remove the GConf linking
without breaking binary compatibility.  (Except for apps that use GConf
directly of course, but there you depend on GConf no matter what)

However the way bonobo-config is added to the platform we CANNOT switch to
something else from bonobo-config later, even if bonobo-config goes out of
style.   bonobo-config adds an Imlib style dependency.  Something we'll be
stuck with no matter what.  I know we all now love bonobo-config (well not
all), but at one time we all loved imlib.  (Except for Jay Painter who did
tell me that imlib is complete shit at LinuxExpo '98 so I suppose he's a
visionary)

George

-- 
George <jirka 5z com>
   The great masses of the people ... will more easily
   fall victims to a big lie than to a small one.
                       -- Adolf Hitler, "Mein Kampf", 1933