mapping between dconf dump output and gsettings schemas

For example :

dconf dump / | grep mouse
[org/mate/desktop/peripherals/mouse]
....

So if I want to make a gsettings command based on this output, I look to gsettings to list the schemas, but....

(output edited to include only likely candidates ):

gsettings list-schemas | grep mouse
....
org.mate.peripherals-mouse
org.gnome.desktop.peripherals.mouse
org.mate.SettingsDaemon.plugins.mouse
....

So it is not clear to me which of these mouse schemas I should use. My understanding is that gsettings is a command line interface to the dconf database, but there is no clear correspondence between gsettings data and dconf data -- as far as I can see.

Can someone explain or point me to explanatory documentation. Thanks.

Solution 1:

Typically, dconf schemas translate nicely into gsettings schemas by replacing slashes with dots and vice versa.

In your example, org.mate.peripherals-mouse is the closest matching for what I'd expect to be a static schema.

However, not all gsettings schemas translate nicely. There's something known as relocatable schemas:

A relocatable schema is what you need when you need multiple instances of the same configuration, stored separately. A typical example for this is accounts: your application allows to create more than one, and each of them has the same kind of configuration information associated with it.

For such cases, schema also requires a particular path added to it. For example,

gsettings set org.compiz.unityshell:/org/compiz/profiles/unity/plugins/unityshell/ dash-blur-experimental 1

Here's another example from one of Budgie desktop schemas:

$ dconf write /com/solus-project/budgie-panel/panels/{5f6251f2-9d09-11e8-be4b-d053493d53fd}/size 52
$ gsettings set com.solus-project.budgie-panel.panel:/com/solus-project/budgie-panel/panels/{5f6251f2-9d09-11e8-be4b-d053493d53fd}/ size 52

Typically paths for relocatable gsettings schemas are the same as for dconf, but it's not guaranteed from what I understand. Manual way would be to run dconf watch / and use GUI buttons/sliders/preferences menus to figure out which schemas are controlled by those.

Solution 2:

To further clarify the relation between GSettings and DConf:

First of all, they are part of the same system. To be more precise, GSettings uses DConf as its storage backend.

And that's what DConf is: a storage system. That's why it only speaks in terms of paths: it stores keys and values in a given path. Those paths, keys and values are then stored in a binary source. Think of dconf as a ZIP archive: it contains "files" (keys) with values, structured in directories and subdirectories.

For dconf that data has no semantics. Yes, its values are strongly typed (String, Integer, List, Boolean and so on). But they have no meaning. It doesn't care (or even know) about schemas.

Now comes GSettings. It organizes data in a logical way, with schemas declaring all settings an application uses, their description and summary. A Schema is the "blueprint" of a collection of settings, and has a unique ID. So an application, say Gnome Terminal, installs the schema org.gnome.Terminal.Legacy.Settings. The schema is saying "my (legacy) settings have this format".

GSettings (actually GLib) takes care of where and how such settings will be saved, so you don't have to. It could theoretically use an SQLite or MySQL database. Or INI files. Or JSON. It uses DConf, and so by default it saves that schema at dconf's path /org/gnome/terminal/legacy/settings/.

So is there a 1:1 mapping between GSettings schemas and DConf paths? For non-relocatable schemas (more on that later), yes. But you cannot derive a path from a schema name: even if most schemas are stored in a path resembling the schema, such as Gnome Terminal example above, that is not always the case: org.gnome.Vino, for example, is stored at /org/gnome/desktop/remote-access/. To get the paths where schemas are stored, use:

gsettings list-schemas --print-paths

And to infer the schemas from the paths... don't. You can get away with "replace / with ." only for the most basic cases. It won't work for:

• Schemas withMixed.case.Names, such as Gnome Terminal
• Schemas in non-standard paths, such as Vino
• Non-relocatable schemas

Relocatable? Yes, when the same Schema is used in multiple instances. For example, Gnome Terminal allows you to create several named profiles, which is a subset of the application's settings. Since all profiles have the same format, they all share the same "blueprint", the Gsettings schema org.gnome.Terminal.Legacy.Profile. The data for each profile is saved in a distinct dconf path, and so that schema is a relocatable one.

That's why for relocatable schemas the application (and you) must specify both the schema and path when using gsettings. If accessing dconf directly, as it doesn't know about schemas, you use just the path. But there isn't a 1:1 mapping, as relocatable schemas have a 1:N relation with paths.

To answer your question: none of the mouse-related schemas you listed is a relocatable schema (those would be listed with gsettings list-relocatable-schemas), so you can for this particular case get their DConf paths with

gsettings list-schemas --print-paths | grep -i mouse

As for "which one should I use"? Well, that depends on what setting you want to change. Several applications might have mouse-related settings. Gnome Desktop has one, Mate has another for its desktop (I presume) and a mouse-related plugin in its "settings daemon", whatever that is. What behavior in your system each setting controls is application-dependent, but that would be outside the scope of the question.