D-Conf

[P. Kaluza]

Hi Philip,

>And in all honesty.. s/gconf/dconf/g followed by s/GConf/DConf/g would
>do the trick for 99.9% of all applications currently using GConf.
>
>If we want to let the KDE-people start using GConf, we'll have to make
>them feel good about it. Very good since they'll be adopting alien
>technologies.
>
>If it's changing that G into a D is whats going to make them feel
>better, then thats exactly what we'll have to do.
>  
>
While the KDE crowd has more experience now with glib than when "they" 
decided to hate gconf, I don't think it's quite as easy. There were, 
after all, specific objections from their POV:
- glib dependency  sucks (_maybe_ resolved in most heads)
- architectural complaints (daemon sounds unneccesary to their model of 
doing things)
- API is not too good (the gnome ppl see this too)
- Waldo, what have i missed ?

I agree with Sean that we need to find our direction first. Then we 
should design a cool api for it. (This could certainly end up very close 
to the gconf API, but we'll see.)  Then we can overhaul gconf or 
something else, or, if necessary, start from scratch.

But I really don't expect s/gconf/dconf/g to be all that sufficent. But 
that's not so much of a problem. If the GConf guys agree with the 
direction DConf is taking, they could just make the next version of 
libgconf a compatibility wrapper. We could also do that ourselves, 
similar to how we'll probably provide a KConfig-like class.

Bye,
  Philipp