GConf
GConf
Posted Apr 1, 2004 2:45 UTC (Thu) by elanthis (guest, #6227)Parent article: A look at GNOME 2.6
"One is unpleasantly reminded of the Windows Registry when tinkering with GConf."
We can all agree that it's so much better when apps each have their own configuration file, located in slightly different places under slightly different naming conventions, usually in incompatible file formats requiring swaths of duplicated code to deal with them, with no ability to provide central system administration or lock-down, no change notification, no ability to safely share settings between multiple apps, no ability to store settings in a centralized manner to be available to multiple machines, etc etc. Right?
The only big user-related difference between GNOME's GConf and the nearly identical systems used in KDE, OS X, etc is that GConf has a user-visible graphical tool for modifying the settings files. Yes, that's right, KDE has a configuration system that stores files in XML files, just like GConf, and provides a lot of the same functionality as GConf. Again, the only difference is that KDE apps shove every possible bell and whistle somewhere into the UI. Both of them are just as "unpleasantly" similar to the Windows Registry. GNOME just doesn't hide the config system behind masses of UI clutter.
Is GConf the utopian implementation of a settings database? No. Of course not. It is, however, something that developers, system adminsitrators, and even users actively want. (See first paragraph for reasons why.)
Posted Apr 1, 2004 8:14 UTC (Thu)
by one2team (guest, #7316)
[Link]
Using an XML format is not a magic way to get readable files (though it *is* possible to get pleasant XML config files as fontconfig attests). You have to work at it just like you have to work on GUI usability. When one takes a look at actual GConf files it's obvious it's seen my most developpers as just another black-box store. In some files you even have *huge* blobs in unrecognizable format stored in a single XML attribute (ie the developper didn't even bother to think about breaking his info into meaningful tags) The direct result is any gconf install will be bitrotting as fast as any windows registry - a human just won't be able to clean up the mess, and the apps care just as much as the developpers that designed the file formats - ie not at all.
Posted Apr 1, 2004 10:54 UTC (Thu)
by alex (subscriber, #1355)
[Link]
I also agree there is probably a lot of duplicate code that GConf removes. The seperating of frontend and backend also makes sense. However what I miss is comments. My exim.conf is 562 lines long, of which 252 are comments. I find with any complex software the inlined commentry about what each variable is for or why I changed x to y really useful. And I don't see what the current GConf implementation does to replace this most useful feature of plain 'ol configuration formats. Alex.
Posted Apr 1, 2004 16:04 UTC (Thu)
by dlpierson (guest, #5124)
[Link]
I find the difficulty of changing things like URL handling in Evolution
GConf would have succeeded in not becoming another Windows registry if the Gnome people have payed more attention to the junk they put in their files. GConf
I can see what GConf is getting at and they have made moves to to avoid some of the pitfalls of the Windows registry (the backend is not one big binary blob, if you want you can go at it with a text editor).What I like about .conf files
p.s. However I can also say that Sendmail and Procmail configurations have made me reach for the yak bucket from time to time....
Not to mention that GConf is likely to be missing or hard to findGConf
for those of us who use gnome applications in a non-Gnome environment.
a real pain because I use Evolution in KDE rather than gnome.