Re: Getting libgnome* into shape

[Joe Shaw <joe ximian com>]

On 29 Aug 2001 16:48:20 -0700, George wrote:
> Imlib and GConf dependencies are completely different.  If GConf is used in
> libgnome* it exposes no extra API.  It is just linked to libgnome.  If we
> ever switch to something else.  Apps that don't use GConf themeselves will
> not see a difference.  Apps that still use GConf will have to link to it.
> Just like it would be with bonobo-config.

Sorry, I think I was unclear: they're not the same thing, but they're
analogous. In the same way that exposing the Imlib structures through
the gnome-libs API tied us (and all of our applications) to Imlib,
requiring applications to link against GConf ties our applications to
GConf. The former could have been avoided by moving the Imlib details
into a private structure and so forth, while the latter can be avoided
by using bonobo-conf.

I'm not saying there is anything wrong with GConf, but I would feel a
lot better if we implemented a policy across the platform for the
configuration stuff. The bonobo-conf stuff already uses the PropertyBag
interface, which we're tied to since we've committed ourselves to
bonobo... Seems to me like linking against GConf gains you little aside
from the future possibility of ABI breakage.

> Then we stop linking with it.  We can even stay binary compatible.  That is,
> as long as the app itself doesn't use GConf, but then ...

Right, apps linking against it is the problem. My point is that a single
configuration mechanism should be implemented in libgnome and "enforced"
as policy across the desktop. I'm fine with it either way (although i'd
prefer bonobo-conf, obviously), but one or the other needs to be made.

> And what if, I know this sounds inconcievable now, but from past gnome
> experience this WILL happen.  We find that bonobo-config is not "adequate" by
> whatever reasons.  And I'm sure that will happen given that similar things
> have happened in a smaller timescale.  Then we have to stay with it, since
> libgnome exposes bonobo-config API.

I don't think this will happen.

Seriously, though, the bonobo-config stuff doesn't add any API because
it's all done via monikers and the propertybag interface that we're
already committed to. I suppose there's a decent chance all of that
stuff might not meet our needs at some point in the future, too, but
then we're talking about more or less completely redoing the platform
(again).... At what point do you draw the line?

Joe