The Case for Gconf

While not hating GConf quiote as much as the OP, I sympathize with his point of view.

XML is an easily grepped pure text format that can be modified with a simple editor.

I can do "db1_dump | egrep" that doesn't make libdb files humanly usable. XML, esp. as used by GConf, is not human friendly. You also have to manually restart GConf, you can't just edit text files and do "gconftool --reload" or something equally obvious. I'd also bet good money on the crappness of the text format making startup/login slower (and when I've seen people complain about this the developers say something like "Hey you want fast write a PostgreSQL backend".)

This is:

1. Not a problem with gconf. Any failure of this form represents bugs in the application.
2. Not provided with any examples or links to bug reports. I've not seen anything like this since Nautilus was being maintained again (and even then the problems didn't happen when you upgraded.

This is absolutely GConf's problem. From an applications POV you want to be able to say X is what the preferences looked like before, Y is what they look like now ... do what you will. Even GConf saying "application ABCD has changed it's preferences reverting to defaults", but that's the "worst" case of what it should do ... it could be much more helpful.

You could argue that something like leafrea (that stores all it's application data in GConf) isn't really GConf's fault ... but that is mostly bad by degrees, and the more data you have the more annoying not being able to easily change it becomes.

For a properly written application, ..., the effect of all its keys is documented.

And I'll say that in my experience that is true, using the graphical client is failry easy to tweak small config. options (once you know where they are -- how hard would have a find operation been?) ... and GTweakUI is aparently a very small source footprint, which could be expanded upon.