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?

Solution 1

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.

Solution 2

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

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

Comments

[Admin]

I would be particularly interested in which settings are handled by which tool (dconf or gsettings) and why there are differences?

[idgar]

Is GSettings works with GConf also?

[dobey]

No, GSettings is an implementation of the DConf spec. The command line tool doesn't work with gconf. There are however, some compatibility layers currently in use on Ubuntu, where changing a setting in gsettings or gconf, will result in the change being propagated to the other. This isn't common though, and not something to rely on.

[idgar]

another thing,i saw somewhere that GSettings works with configuration files. is there something about it? and why does GSettings doesn't show the same schemas as DConf-editor?

[dobey]

GSettings doesn't work with configuration files. You could theoretically write a back-end for GSettings that uses configuration files, and configure it to use that, though. As for different schemas, I don't know what you're talking about.

[jpp1]

The interesting part to know would be which settings are managed by which tool? The keys which are present when using dconf or dconf-editor are different from those accessible with gsettings, for example there is a key /com/canonical/unity/always-show-menus accessible via dconf but there is no equivalent key accessible via gsettings in Ubuntu 15.04.

[dobey]

@Johsm I presume you are confusing gsettings with gconf here, because gsettings IS built on dconf, so anything visible in dconf-editor can be changed via CLI with gsesttings.

[jpp1]

OK, maybe I am confusing things here but what made me ask is this: if I run "dconf list /com/canonical/unity/ | grep menus | grep always" I get as output "always-show-menus" but when I run "gsettings list-recursively | grep canonical.unity | grep always" I get nothing. In other words, the key com.canonical.unity.always-show-menus is visible in dconf but not in gsettings. I am doing this on Unity 15.04 64 bit on a Lenovo w550s running Unity.

[dobey]

Because the schema is com.canonical.Unity, not com.canonical.unity.

[jpp1]

@dobey: thanks! I completely missed that! But now i do not understand why it works with lowercase in dconf and only with uppercase in gsettings?

[dobey]

@Johsm One is a path, and the other is the schema. They are not the same thing.

[jpp1]

@dobey: thank you for helping with this. What I am really after is though: how does the mapping between the key I have to use in dconf and the key I have to use with gsettings work? If I know one, is there an algorithmic way to find the other? In my concrete case I was given /com/canonical/unity/always-show-menus -- now how would I find the appropriate key for gsettings? If both use the same underlying data, should there not be a logical mapping? Or am I still missing something?

[dobey]

Read the schema file.

[Victor]

gsettings is a CLI tool though, like OP mentions. I think they want to know whether they should use that, or dconf (or gconf), basically.

[Flimm]

@Victor I'm not sure I understand your comment. Like I said, application developers and end-users are recommended to use Gsettings, not dconf or gconf.

[Victor]

OP is specifically asking about "Gsettings - CLI tool to edit settings." That's the context. Not about the library.

[Flimm]

@Victor I've edited the answer post to clarify that gsettings the CLI command uses Gsettings the library. Both application developers and end-users are recommended to use Gsettings (either as a library, or as a command on the CLI).

[Beni Cherniavsky-Paskin]

gsettings list-schemas --print-paths shows the correspondence, grepping for [A-Z] chars gives many examples of non-1:1 e.g. org.freedesktop.Tracker3.FTS /org/freedesktop/tracker/fts/ or ca.desrt.dconf-editor.Settings /ca/desrt/dconf-editor/