p.kaluza at tu-bs.de
Sat Mar 5 16:28:52 EET 2005
>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
>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
- 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.
More information about the xdg