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 with
Mixed.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.