libgnome & bonobo-config ... the future.

[Michael Meeks <michael ximian com>]

On 29 Aug 2001, Martin Baulig wrote:
> However, let's assume GConf will have a public CORBA interface at some
> point in the future - no matter which CORBA interface this is.

        This does not seem likely to me. There are good reasons from
Havoc's perspective for keeping the interface private. And indeed writing
the C client API ( which I criticise much, but understand the [ good from
a certain perspective ] reasons for ).

        Ultimately however Gnome should be using a CORBA interface for
everything that it can get it's hands on - preferably right down to the
widget level; although this is currently not practical.

        As such, we want to move code away from using the GConf C API,
since it is not the API we want to reccommend for GNOME applications (
although perhaps in some limited circumstances for raw non-gnome, non-gui
type apps it makes some sense ).

> Once we did this switch, apps don't necessarily need to depend on
> GConf (as a library) anymore - they don't need to link against it and
> they don't need to initialize it.

        And they use a standard generic interface which has a lot of
advantages. Also, it doesn't tie GNOME to GConf - as a future migration
strategy - for GConf2 we can substantialy re-work everything and not be
tied to that C API.

        But anyway - ultimately, I simply want to limit the amount that
gconf is used - especialy not in sample code - and not exposed in headers,
and push the bonobo-config API across Gnome 2.0 as the correct, clean and
forward compatible way to access configuration. I can see that some people
can't cope with the concept - so use gconf natively, don't port
Nautilus[1] to use bonobo-config, it's fine - using the same backend store
is the only important issue here - we don't expect the world to be cleaned
up overnight - simply that we are not forced to stick with a broken world
forever.

        Regards,

                Michael.

[1] - in fact the bleating about the terrible problems of moving Nautilus
from GConf and the commensurate impossibility of a new API are just total
balderdash; do a simple grep for 'gconf' on nautilus and eel and you see
the extent of the problem. The gconf API has already been wrapped with an
eel API - so ... switching the backend is fairly trivial.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot