Gconf, Dconf, Gsettings and the relationship between them

Question

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:

1. Which backend system is more often used - Dconf or Gconf?
2. Gsettings works with both of them? And why doesn't it show all Dconf schemas?
3. Where does Dconf save its data?

Answer 1

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:

• What are the differences between gconf and dconf?
• Can I use dconf-editor to modify Gconf settings?
• GSettingsMigration on gnome.org

Answer 2

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 older gconftool command line tool is for GConf.

Answer 3

Ignoring GConf here because it's obsolete. TLDR: use gsettings.

dconf is ignorant of schemas, so is blind to defaults

from man dconf (1):

The dconf program can perform various operations on a dconf database, such as reading or writing individual values or entire directories. This tool operates on dconf directly, without using gsettings schema information. Therefore, it cannot perform type and consistency checks on values. The gsettings(1) utility is an alternative if such checks are needed.

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:

> gsettings list-recursively org.gnome.desktop.interface | grep scaling
org.gnome.desktop.interface text-scaling-factor 1.0
org.gnome.desktop.interface scaling-factor uint32 0

> gsettings list-schemas --print-paths | grep org.gnome.desktop.interface
org.gnome.desktop.interface /org/gnome/desktop/interface/

> dconf dump /org/gnome/desktop/interface/ | grep scaling
> dconf list /org/gnome/desktop/interface/ | grep scaling
> dconf read /org/gnome/desktop/interface/text-scaling-factor
> dconf read -d /org/gnome/desktop/interface/text-scaling-factor
>

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:

> dconf write /org/gnome/desktop/interface/text-scaling-factor 1.0
> dconf dump /org/gnome/desktop/interface/ | grep scaling-factor
text-scaling-factor=1.0
> dconf read /org/gnome/desktop/interface/text-scaling-factor
1.0
> dconf read -d /org/gnome/desktop/interface/text-scaling-factor
>

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:

> dconf write /org/gnome/desktop/interface/foo 123
> dconf dump /org/gnome/desktop/interface/ | grep foo
foo=123
> dconf reset /org/gnome/desktop/interface/foo
> dconf dump /org/gnome/desktop/interface/ | grep foo
>

gsettings uses schema data

Well, 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:

      <key name="text-scaling-factor" type="d">
        <range min="0.5" max="3.0"/>
        <default>1.0</default>
        <summary>Text scaling factor</summary>
        <description>
          Factor used to enlarge or reduce text display, without c>
        </description>
      </key>

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 (see gsettings 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:

> gsettings describe org.gnome.desktop.interface text-scaling-factor
Factor used to enlarge or reduce text display, without changing font size.

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 data

Despite 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: