Submitted by “To put things short, Gconf is a system built in GNOME 2 which stores applications’ preferable configuration data as well as graphical environment variables in its own files. I’d like you to get familiar with the Gconf tool’s functions, engineering, and usage with this article.”
Does Free Desktop provide some common way to store preferences? I have over 200 hidden files and directories in my home directory, and it would be convenient if every application stored its preferences in a common way to cut down this clutter.
Becouse is easy copy your 200 configuration files and always you will have the same configuration in all your system. I really hate gconf, its like the windows register. I have .*rc that I haven´t change in 15 years.
It’s easy? Perhaps you could tell me what this file does:
.aspell.en.prepl
Or this one:
.gtkrc-1.2-gnome2 as opposed to .gtkrc or .gtkrc-kde
Or this one:
.recently-used (How do you even know what program this belongs to?)
Or this one:
.rhn-applet.conf
Luckily I’m fairly experienced with Linux, so I can guess what some of them do. But even still, it’s hard to determine what function these files play in their associated programs. Some of them are binary files, so I can’t even open them. If they are text and if I delete one of these files, will all my preferences be gone, or just some of them? For example, if I delete “.realplayerrc,” will this just delete my history or my network preferences? It’s hard to tell, and few people really care enough to go through each file, modify or delete them, and see what the change is.
“I really hate gconf, its like the windows register.”
As it has been explained before, GConf is just a wrapper / GUI tool for modifying XML files. No need to hate it – no need to use it anyway.
Personally, I prefer configuration files that have a more simple format; XML is an overload that has its advantages, true, but “directness” (I may use this term) surely is not one of them.
Files that resemble a format of NAME=”SETTING” are easier to edit due to a flat (1 level) hierarchy. Editing is very easy here. I won’t claim this storage format is ideal for every imaginable purpose, but files of this format (and similar formats that use certain keywords) can cover a huge amount of setting saving intentions.
“I have .*rc that I haven´t change in 15 years.”
Same here, too. And I’m happy I didn’t have to change one of them because the applications they belong to are still able to use them.
Sorry, but what is the reason for having a registry analog in Gnome?
I guess it’s a matter of taste, but the beauty of Linux is an ability to modify settings/preferences in vi.
And while you can still do that in Gnome, it is way more obtuse than it should be in my opinion.
We all suffer greatly from the registry in Windows, so why repeat the experience?
I mean, it works great (GConf), but, but… I just want to be able to repair something relatively easily from the command line (in case GConf wouldn’t start for some reason)
If anyone could explain…
Thanks
It’s not really a registry. It’s a settings backend. The real beauty of GConf is the fact that everything is stored in human-readable and editable XML files.
Another interesting thing that I’ve noticed is that if you change a setting in GConf, the application is notified and reacts accordingly. That means that if you simply edit the color field for a button in nautilus, it instantly changes color (assuming nautilus would have something like that).
GConf is also conceived in a way that is pretty user friendly, thus browsing through it is not a complete mess like browsing through the Windows Registry.
Could’ve fooled me.
It felt just like editing the Windows registry.
Even the structure resembles the registry.
Simillar sections with simillar names. And noone knows (well, except the authors) what they do, what values they accept, and what will happen when changed.
I haven’t tried it recently but a few years back when I was still willing to give Gnome a chance, I managed to corrupt the Gnome configuration every time beyond repair (had to reset Gnome by deleting it’s conf directories) within hours of starting to use it.
I Hear you. Same happened more than once.
And I’m afraid, Gnome XML configuration files aren’t very human readable, as there is very little (none really) documentation describing what is what and where it is. And so fixing problems without wiping out an entire Gnome profile is fairly difficult.
I’ve never done that. Not once. Ever.
The ‘drawbacks’ you cite have nothing to do with the structure of gconf and equally well apply to many .whatever configuration files. These very often don’t tell you what each setting does, what values it accepts, or what will happen when changed either. Why do you act as if these problems are unique to apps that use gconf?
It’s true that some conf and .rc files are not documented or not enough documented to be easily editable.
But IceWM preference file is a “work of art”, clearly documented, values take 1 or 0, it’s simple to edit, simple to copy to another user account or machine, simple to back up.
And gui configuration utilities for it exist too.
If all apps used configuration like IceWM then the world would be a much better place.
“It’s true that some conf and .rc files are not documented or not enough documented to be easily editable.”
Sadly, this is true due to the “unpleasantness” of documentation often found in Linux world. If you install an application foo, then “man foo” should continue a section FILES including name, location and content of configuration files. In BSD world – but please NB we’re talking about an OS now – important files have their own manpage and examples; furthermore, OS developers have seen the usefulness of good examples and informative comments.
But why is it neccessary to document configuration files? The solution “Windows” propagates is the following: Hode everything from the user, don’t bother him. So applications tend to make everything on their own, including configuration saving / retrieval. Outside “Windows” land, we do have choice. So a GUI frontend can be used, but files may be changed manually, too, which is great especially if something does not work as expected. It is a means to the user to help him solve problems by his own.
Some *.conf and .*rc files really impress by strange syntax that you’ve never seen anywhere before. But fortunaltely, this does not cover the majority of them. Example entries, comments and self explaining identifiers (Programmers, take care!) are a good help.
“But IceWM preference file is a “work of art”, clearly documented, values take 1 or 0, it’s simple to edit, simple to copy to another user account or machine, simple to back up.”
Yes, it is. I had to setup a system (some years ago) where the adduser command (in fact: pw) would copy IceWM preconfiguration data from the system’s skel directory. Easy work.
“And gui configuration utilities for it exist too.”
There are some (more than one, maybe two?), if I remember correctly…
“If all apps used configuration like IceWM then the world would be a much better place.
“
Allthough I like IceWM’s configuration concept, inheriting a bit from KDE’s centralism would be an interesting approach. Let’s assume a ~/.config dir with subdirectories named after the corresponding application, containing the config data needed in a format that is easy to handle.
GConf is intended for Gnome and Gtk applications in first place. The UNIX world does not consist of KDE and Gnome only. Allthough integration to these two most important desktop systems is important, there are situations where Gnome’s or KDE’s overhead is not needed or wanted.
Could’ve fooled me.
It felt just like editing the Windows registry.
Even the structure resembles the registry.
Uhh no. Gconf-editor looks a bit like regedit but that’s about it. Also gconf-editor has a much more sane layout and built in documentation.
Simillar sections with simillar names. And noone knows (well, except the authors) what they do, what values they accept, and what will happen when changed.
If you can read you can make sense of GConf without having to look up KB articles.
I managed to corrupt the Gnome configuration every time beyond repair (had to reset Gnome by deleting it’s conf directories) within hours of starting to use it.
If you did that on Windows the computer wouldn’t even boot. You would be forced to manually roll back the registry, which is much more of a pain in the ass than having to restore application settings.
You’re making rather lame excuses for an incompetent developers bad design decisions.
And actually you’re saying that it’s ok if configuration corrupts and I have to redo all app settings.
Well, that may be acceptable to you but I have much higher software standards and like having software that works without self-destructing every few hours.
Unfortunately the sad fact is that Gnome will not change until someone forks it or Havoc looses control of the project and someone more competent and flexible takes over.
Of course if you corrupt your configuration files applications will malfunction. It doesn’t matter if it’s gconf or your ~/.foo files. So your point is?
You’re making rather lame excuses for an incompetent developers bad design decisions.
And actually you’re saying that it’s ok if configuration corrupts and I have to redo all app settings.
You’re the one making lame excuses. Corruption can happen from hard drive failure also. What do you do then? I have never experienced corruption in GConf myself but I have in Windows’ registry on several occasions.
Well, that may be acceptable to you but I have much higher software standards and like having software that works without self-destructing every few hours.
No problems here. By the way if using GConf causes your computer to self destruct every few hours you should probably stop using a computer.
Au contraire; everyone knows what the GConf keys do since every single GConf key is documented. The documentation is visible in the GConf-editor UI, and it’s localized for non-english speakers. If a key should be undocumented, it’s a bug. As for what values are accepted, that is defined both by constraints as well as being documented in GConf.
The same is true of any configuration system. If you want to break it, you can.
Edited 2007-07-03 07:19
You, Sir, have made some very funny experiences. While I agree with you on the structure of GConf resembling the structure of the Windows Registry being both hierarchical and thus simliar, I fail to see the similiarities in the naming.
Registry: HK_Local_MachineSystemControlSet001Enum1394MaxtorOneTouch
GConf: /desktop/gnome/peripherals/mouse/
Also I have to say that I never had any case of GConf corruption. If a problem arises with a CGonf setting, the worst that will happen is that GConf just reads the default value from the supplemented Schema files. The worst case scenario involves deleting of the corresponding xml file.
And while some of the GConf configuration option may be named somewhat improperly, the values they accept is always defined by the Schema.
This is, by the way, not a problem of GConf. GConf provides very convenient ways to documet each single configuration option.
And on another note; Not knowing what a configuration option is used for and not knowing what kind of values it will accept is more a problem i associate with plain text configuration files.
The real beauty of GConf is the fact that everything is stored in human-readable and editable XML files.
I always laugh at people who describe XML files like that. XML is by no stretch human readable.
What stops You from going with vi to the ~/.gconf dir?
You will find there planty of xml files which are easy to edit.
GConf is a wrapper for that dir, nothing else, You don’t need to access any config files in Your app, just use gconf to open/edit prefs.
Some people also don’t like that amount of dot{file,dir} things in they home dir, one dir for configs is enough.
what is the reason for having a registry analog in Gnome?
Two main reasons. First, a configuration is essentially a set of key/value pairs, where the key is an identifier and the value can be a boolean, integer, or string. Standard text configuration files have various means of encoding the key/value pairs. A registry features a unified means of describing these pairs without any loss of generality. Most registry implementations also feature the notion of hierarchical keys, which are rarely implemented in traditional configuration files.
Second, registries allow key values to be safely modified without worrying about concurrency or forcing applications reload their configuration. Applications read their keys directly from the registry. If a value changes, the application sees the change instantly. This is how “instant apply” works in GNOME. A registry implementation usually includes a daemon that caches key/value pairs in memory, so reading a key is very cheap.
beauty of Linux is an ability to modify settings/preferences in vi.
There’s a lot to like about Linux. It’s free, reliable, efficient, flexible, and so on. But manageability is one of the areas where it can use some work. I enjoy vi(m) as much as any hard-core Linux user, but I use it for system administration simply because there is no more convenient way. Properly designed GUI and CLI tools are usually more convenient than an editable text file.
The GConf GUI front-end used to be horrible, and now it’s what I would call marginally acceptable. It still needs find-as-you-type, and I would like to see a per-application view of the editor easily accessible from the application itself. In the long-run, you should be able to checkmark a GConf key to instantly add the appropriate configuration widget to the appropriate tab in the application’s preferences dialog. Key types would then have to reflect the appropriate widget rather than merely the type of the value.
We all suffer greatly from the registry in Windows, so why repeat the experience?
The problem with the Windows registry is that its heritage dates to when Windows was a single-user OS both in practice and in theory. When Windows became a multi-user OS (in theory), applications continued to assume that they could write to system-wide parts of the registry. Therefore, most Windows users kept running as administrator, and the security model of the entire OS (not just the registry) was completely compromised. An application running with administrator privileges can do whatever it wants. It doesn’t matter how the registry is designed or secured.
The problem with the registry is that it is a binary format.
As has been pointed out, gconf is human redable. (Assuming you call XML human readable, of course.)
Aside from that, what’s wrong with keeping the all the config in one place in a consistent format easily parsed by any utility of programming language that handles XML?
Or perhaps you like a zillion little dot files in your home directory, each with its own idea of a syntax. That’s what we’ve traditionally had in Unix. It simply does not scale to the kinds of complex desktops that we have today. Arguably, it didn’t really scale to the simple desktops that we used to have, either.
From a UI standpoint, Gconf and gconf-editor are nice because the interface can be kept clean and usable, but power-user options can be retained and available through Gconf.
On that note, the people who moan and complain about Gnome’s “lack of functionality” need to learn about all the stuff available to them through gconf-editor.
Edited 2007-07-02 22:22
We all suffer greatly from the registry in Windows, so why repeat the experience?
The two biggest issues with the Windows registry are not present in GConf. The first issue is the infamous corrupt registry. Windows will fail to load when this happens and there is little you can do short of restoring the registry manually. Corrupt gconf keys can be edited and corrected manually or deleted and rebuilt. A deleted gconf tree will not prevent GNOME from loading.
The second issue with the Windows registry is its practical lack of separation between user and administrator. Microsoft’s registry was hacked in from a single user system. The end result is the necessity of bad security to ensure compatibility.
Based on what my brother said (he is a Gnome users):
Gconf was introduced in Gnome because Icaza likes the Windows registry.
On the other hand, KDE has a decentralized configuration framework that im my opinion is way better than GConf or the Windows Registry. The configuration files reside on a specific directory and their format resemble .INI files. They can be edited with vi too.
Edited 2007-07-02 20:35
Well, your brother is wrong.
First because GConf is not the brainchild of de Icaza but of Havoc Penning, second because Havoc never wanted to recreate the Windows Registry.
The goals for GConf were (amongst others) to create a common API to manipulate configuration files. The XML store GNOME uses today was never intended to be the only settings store, other backends (like an LDAP backend) were also part of the design.
It’s also very interesting that people never seemed to confuse GConf with the Windows Registry until the first versions of the gconf-editor, in look very similar to Regedit.
Remember; if you really want your configuration files scattered all over your home directory, in that funny /Windows/ INI format, you can have that with GConf also. You just have to write the backend.
That whole discussion reminds me very strongly to the discussion Compiz vs. Beryl. Wasn’t one of the reasons the Beryl crowd split from Compiz because they didn’t recognise the flexibility of Compiz and that Compiz also could (easily) have a file file configuration backend, if only someone wrote it?
Sorry about the wrong info then.
But I still prefer KDE’s way of doing this.
I think, Microsoft has been down this road.
first they reliazed that a b-zillion config files is unmanagable.
second: you need some standards and a centeral config repository
MS’s mistake was in piling *everything freaking thing* into the regitsry, Now MS is trying to push ppl away from it and have app devs use there OWN xml based config files. and *not* just dump shit into the registry.
I think if Gnome can use both. config files for some stuff and GConf for others it would be a good thinmg.
-nex6
Every app gets its own XML config file(s) in the gconf structure anyway, so where’s the difference? It’s just convenient and some people are making a fuss out of nothing as always.
This is really a dead horse anyway, but I guess people will still argue back and forth with exactly the same arguments when a successor is done.
Please, don’t compare the way Microsoft does things to the quality of design in GNU/Linux.
I often hear that Microsoft has thousands of the most talented and best programmers in the world.
But so far I have not seen any evidence of that yet, at least by looking at their OS products.
I wouldn’t hire Microsoft programmers to design a simple static html page, never mind an entire OS.
My main workstation is Slackware with KDE used as a standard desktop which means it’s fully loaded with variety of apps.
Right now my uptime is 27 days and 15 hours and I’ve been running all kinds of apps on it , games, propriatory Nvidia drivers, wine with some Windows apps, Skype, Azureus with java and other java apps, and some of these are bound to leak memory and resources.
Yet my desktop is running as fast today as it was when I started it 27 days ago and didn’t have a single hick up or crash or slowdown.
Now you try that on XP and at the end of the day it’ll be like molasses and pretty much unusable in a few days (that is if you don’t blue screen and reboot before that).
And Vista? That crap will restart itself if you look at it the wrong way.
So no, I don’t want Linux developers taking any lessons from Microsoft.
And from my experience, Gnome desktop has been the least reliable software on Linux by far. It’s so easy to break it’s not even funy.
one of the main benefits of storing things in a properly organized XML structure is automation. It enables the development of tools like Sabayon, which would be a _hell_ of a lot harder to do if every app had its own dot file (likely formatted in a different way from every other app).
The shell script presented in the article is claimed to be a BASH script. But it shows noting specific to the Bourne Again Shell that the UNIX standard shell, the Bourne shell, would not be able to do. So, in oder to use this script on other UNIX systems (except Linux), one may change !/bin/bash to !/bin/sh. Assuming a Linux only solution, the author just forgot to mention this, allthoug he states that zenity and scrot need to be present. (On some UNIX systems, explicitely changing the BASH interpreter call to !/usr/local/bin/bash is neccessary because BASH does not belong to the OS itself and needs to be installed afterwards.)
I like gconf when i’m just a user or a programmer and have an easy way to store and retrieve config informations.
I hate gconf if for example i want to move my evolution settings to another PC. Than gconf becomes a real horror!
The /only/ similarity between GConf and the Microsoft Windows Registry is the hierarchical representation of the stored settings. But after that, everything is different.
The only part most people seem to think about when they hear “GConf” is the gconf-editor. The gconf-editor, looking somewhat similar to Regedit, creates an instant animosity towards the GConf framework, because most people with taste dislike the Windows Registry. And for good reason!
It’s unaccessible, it’s a binary, single file (once damaged, all configuration is lost), and it cannot be changed from the command line – yes, the Windows Registry is a mess!
But GConf is none of that. GConf is a completely different beast. What a lot of people don’t seem to realise (“Why can’t we just use flat configuration files?!?”) is that the GConf itself is only a flexible configuration management solution.
It consists of three parts; fontend, server, backend.
The frontend is what most people complain about; the gconf-editor.
There are two default GConf frontends; the graphical gconf-editor and the command line gconftool. Both can be used to access the GConf store in a very convenient way.
The GConf server is the core. It reacts to the GConf C API and writes and reads the application settings out of the active backend. It also informs the applications of value changes, so the can react instantaneously to configuration changes.
The default backend uses XML files in a filesystem tree to store the settings. But it would also be possible to use a flat-file backend. There is even a LDAP backend, you can use for large deployments (Though I don’t know how stable it is.) Remember; GConf itself is represented only through an API.
Additionally, there are also command line tools to manipulate GConf. This is much more convenient than having to use awk, believe me.
And last, but not least; with using GConf, you don’t have to care about the format the configuration settings are stored in. You just use the command line front end (or better yet; the C API) and let GConf worry about the rest.
Having a centralised configuration management solution is just as sensible as having a common toolkit. Or as having a common metadata store. Or as having a common icon set. It reduces code duplication and simplifies coding. This way application developers don’t have to implement everything by themselves (reading, parsing, writing of configuration files, supervise configuration files, recovery, and so on).
By the way; the next version of GConf is having a dbus API. So maybe – maybe – we are going to see some other dbus-enabled applications using GConf as their configuration store.
I hope disperses some FUD about what GConf really is about.
Windows registry is not a single file. It’s separated into a number of hive files and subfiles.
To all of you who think “ew, GNOME sucks, it has that Windows Registry thing, it’s dumb”:
– gconf is basically just a “middle-man” that allows handling settings in XML files.
– gconf was mainly born for gnome to have it’s awesome “instant-apply” behavior since the 2.x series. I’m not sure if KDE or other DEs do that, I haven’t checked. To have an idea of what I’m talking about, change your wallpaper in gnome. Did you have to click an “apply” button? No? I didn’t think so
the majority of settings for gnome apps are applied in realtime. You can activate/deactivate thumbnails for Nautilus and see them appear/disappear while you toggle the options, which is great.
– the single greatest feature I can see is that gconf can act as a “notifier” between programs; basically, program A can play with the settings of another program (or its own settings), and program B will “know” that. It is done using callbacks with the gconf daemon. Something like that
While you think of it, I guess the whole dbus idea sounds familiar to gconf callbacks.
That’s about all I know so far, but I think it summarizes the reasons for gconf’s existence.
The presence or lack of an apply button does not have anything to do with GConf. It just changes the time at which the applet applies the settings. Either the settings change when you actually modify something in the dialog, or they change when you click “Apply”. Programs still need to be notified of the change (via the gnome-settings-daemon). This is true in KDE and GNOME alike. The GConf registry might make it easier to communicate changes to applications, but it doesn’t just make it happen by virtue of being an XML registry.
And that is a part of gconf. Why don’t you read about it? This document is quite old but the goals haven’t changed (though some technical details might have):
Data change notification service. If configuration data is changed, all interested applications are notified. The notification service works across the network, affecting all login sessions for a single user.
This means that programs built from components (where each component may be in a separate process) are much easier to write, because if one component changes a setting the others can discover the change and update themselves. For example, GNOME’s new Nautilus file manager is actually a collection of applications, including an embedded web browser, and various navigation components. The components communicate via CORBA. However, you want a single preferences dialog located in the top-level “shell” component. Without GConf, a custom protocol would have to be invented for each preferences setting, to notify embedded components of changes to user preferences.
Notification is also useful if multiple application instances are running. GNOME 2.0 uses this feature to let user interface configuration take effect on-the-fly without restarting any applications; if you turn off toolbar icons, for example, toolbar icons will immediately disappear in all running apps.
http://developer.gnome.org/feature/archive/gconf/gconf.html
(1) Unlike the Windows registry, it is not used for system control – if the gconf files get corrupted, your system is still bootable. at worst, some of your desktop application preferences will be lost.
(2) GConf’s file format is actually not strictly the XML file format. You could easily create any new file format and plug it into GConf. GConf actually has two different included backends by default. One gives each app its own file, and the other uses one file for everything.
(3) The one file for everything approach was actually converted to from the old one, because having many multiple configuration files was a huge performance drag, and actually increased reliability issues. The one-file backend uses basic robust UNIX file writing techniques, so the file won’t get corrupted any easier than any other configuration file on your system, including the boot-essential files.
(4) GConf does far more than the Windows registry or common text files can. GConf includes a daemon that allows for instant change notification, which flat files can’t support on their own, and even with inotify cannot support as efficiently. The GConf daemon also makes it possible to support distributed settings systems, which is super useful to large deployments, though not so useful for the average home user.
Some more specific replies:
Not sure what your point was, but just to clarify, none of those files have anything to do with GConf.
How have they done that? I’ve never had my GConf XML files corrupted, and even if I did, my computer would still boot just fine, and I could still repair things. But then, if the file was corrupted, I probably have bigger hardware/kernel problems and need a reinstall anyway.
I change compiz settings in GConf using vi all the time. Yes, it’s hard. But then, so are many other file formats.
Unfortunately, a basic INI file format really isn’t up to snuff. You can’t put structured data in an INI file unless you invent some other new sub-format to embed in the file, which is just silly. Perhaps an ideal mix would be to use INI style files and then use a well defined XML format for structured values, but I’m not sure you’d have actually bought a whole lot here.
GConf has used a single file for apps for a long time now. While it scares some people, it’s no less reliable. It also greatly improves performance.
The nice thing is, GCong isn’t like the registry and you can copy your GConf files between machines every bit as easily as you can transfer your other dotfiles. I’ve moved my current GConf settings between 4 machine upgrades now.
Your brother isn’t much of an authority. I don’t think you’ll find Icaza praising the registry too much, although he (and many other developers and administrators) will praise what the registry enables. The Windows implementation of a registry sucks rocks, but that’s like saying that since one popular web browser sucks, all web browsers are just as bad.
It’s also worth noting that Icaza isn’t the one who introduced GConf.