I'm trying to understand how Gconf, Dconf and Gsettings works and what the relationship is between them.
All I know is:
- Gconf - XML based database (backend system). The older one.
- Dconf - BLOB based database (backend system). The newer one.
- Gsettings - CLI tool to edit settings. Looks like it works only with Dconf (although I saw somewhere that it might work with Gconf).
I know that for Gconf there is a GUI - Gconf-editor, and for Dconf - Dconf-editor.
So:
- Which backend system is more often used - Dconf or Gconf?
- Gsettings works with both of them? And why doesn't it show all Dconf schemas?
- Where does Dconf save its data?
Dconf is a data store designed for storing configuration. It is the replacement for Gconf, which was used for the same purpose. Eventually, no programs should depend on Gconf any more.
Gsettings is a development library used to read and write to a configuration store backend. On Linux, it uses Dconf, but on Windows, it uses the registry, and on OS X, it uses a native data store. (The
gsettings
command on the CLI uses this library.)Application developers and end-users are recommended to use Gsettings, not Dconf directly.
See also:
GConf is obsolete. It is the older GNOME 2.x configuration API and system, and has been replaced by DConf/GSettings in newer versions. However, some applications still use it.
GSettings is a GLib implementation of DConf, which stores its data in a binary database.
The
gsettings
command line tool is simply a tool to access or modify settings via the GSettings API, in the same way that the oldergconftool
command line tool is for GConf.Ignoring GConf here because it's obsolete. TLDR: use
gsettings
.dconf
is ignorant of schemas, so is blind to defaultsfrom
man dconf
(1):I don't care that much about "type and consistency checks".
In practice, I see a more important difference —
dconf
only sees settings that I explicitly set. Example of untouched settings:Here
dconf read -d
claims it reads default values, but in practice does nothing for me? ?I can still write it (blindly), even if to same 1.0 value as default and then dconf sees it:
Moreover, I can store any key I make up! So it functions like a dumb hash table of exlicitly set values, and
reset
just deletes the entry:gsettings
uses schema dataWell, that makes sense. I used
locate --regexp org.gnome.desktop.interface
and got a couple xml files (maybe not the right one), and the schema files do contain the default:So
gsettings
combines the actually set values with defaults.? That's why instead of single path it takes two arguments eg.
gsettings read SCHEMA[:PATH] KEY
— because it starts from the schema, maps it to dconf path (seegsettings list-schemas --print-paths
but takes optional PATH for relocatable schemas), and then overlays the modified values from dconf.It can also dump some schema info:
but somewhat disappointingly, I don't see any way to just read the default (if a value is set), nor distinguish whether a settings is left at default or explicitly set to same value.
dconf-editor
also uses schema dataDespite its name, dconf-editor does show both modified and default settings, including which are default and which are explicitly set:
and is fully aware of schema info: