mapping between dconf dump output and gsettings schemas

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.


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? Not quite: you can already see the DConf path is all lowercase, while the schema ID is not. So you could get the path for a schema, but not the other way around.

Could? Yes, because sometimes the same Schema can also be used for 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 infer their DConf's path.

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.