Re: Getting libgnome* into shape



On Wed, Aug 29, 2001 at 08:32:20PM -0400, Joe Shaw wrote:
> 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.

Huh?  If imlib details would have been in a private structure it would be in
EXACTLY the same position as GConf.  As in, something which we can stop
linking the library to.  People that use GConf will still have their apps
linked to GConf, people who don't, won't.

Nobody still haven't answered the question of 'What if we want to get rid of
bonobo-config?'  I see it as the same kind of question.  Because I don't
see bonobo-config as a be all end all soltion that will solve every problem
known to man for eternity.

With the way the GConf dependency works, we can change it to something else
at a minor release without breaking compatibility.  Apps that use it will
just have to add -lgconf to their link lines explicitly.

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

I've comitted myself to nothing.  I don't really like the property bag
interface for this kind of stuff.  It's ok for object properties, it's not a
general API for configuration storage.  In my opinion of course.  Just
because I like bonobo doesn't mean I have to use EVERY ONE of it's interfaces
for everything I do.  Especially if it makes me less productive by (in
my opinion only of course) a more awkward API.

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

Yes, and GConf has been agreed as this mechanism.  What's not agreed is how
to access GConf in libgnome.

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

I don't care if it uses PropertyBag's or whatever.  There IS an API in
libgnome/gnome-init.h that ties bonobo-config directly into libgnome.  There
is no such API for GConf.

Also just because it uses PropertyBag doesn't mean it's not an API.  It's
just an API that's expressed by a hardcoded string rather then a method.
Just because it uses existing functions with different strings doesn't mean
it's not an API BTW.  That would be like saying that object properties are
not API.

George

-- 
George <jirka 5z com>
   People never lie so much as after a hunt, during a war or before an election.
                       -- Otto von Bismarck




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]