I would like to monitor dconf
for changes so that while I tinker with settings, applications and the like I can see what keys are changed, if any.
Is there a way I can accomplish this?
dconf
I would like to monitor dconf
for changes so that while I tinker with settings, applications and the like I can see what keys are changed, if any.
Is there a way I can accomplish this?
The command-line tool dconf
seems to show only those settings which are actually set in the database (so they are different from the default), whereas dconf-editor
shows all possible settings. You will notice that the button "Set to Default" in dconf-editor
is greyed out for those settings which are not shown by dconf
.
dconf-editor
uses schema path
to show settings data tree. Same structure used to store data in GVariant database.
gsettings
(from glib-2.0) uses schema id
to show/get settings data. Same way as any other application should do which uses GSetttings API.
It's up to the application developer to set both as he/she would like. (with some restriction for canonical naming). So path
could be different than id
but most application developers prefer to use identical word series/combination. Some don't preserve same capitalization. Example Tracker project from Gnome
<schema id="org.freedesktop.Tracker.Miner" path="/org/freedesktop/tracker/miner/" />
In addition to that, some alternative applications share same settings which belong to the Gnome desktop. Example: input-sources
First, Apps should not mess with dconf
Introduction from dconf project page:
dconf
is a low-level configuration system. Its main purpose is to provide a backend to GSettings on platforms that don't already have configuration storage systems.
Where's the data stored? (Ref: https://wiki.gnome.org/Projects/dconf/SystemAdministrators)
A profile is a list of configuration databases. What it seems that Gnome & Unity use same profile.
$ cat /etc/dconf/profile/gdm
user-db:user
system-db:gdm
user-db:user
: First database in the profile is read-write rw
and it is created in the user's home directory.
$ file ~/.config/dconf/user
/home/sneetsher/.config/dconf/user: GVariant Database file, version 0
system-db:gdm
: read-only
$ file /etc/dconf/db/gdm
/etc/dconf/db/gdm: GVariant Database file, version 0
dconf
could bind a text style store in addition to GVariant Database from db.d/*
folder. Example (Notice file path, so it is a part of system-db:gdm
):
$ cat /etc/dconf/db/gdm.d/00-upstream-settings
# This file is part of the GDM packaging and should not be changed.
#
# Instead create your own file next to it with a higher numbered prefix,
# and run
#
# dconf update
#
[org/gnome/desktop/a11y/keyboard]
enable=true
[org/gnome/desktop/background]
show-desktop-icons=false
...
Schema Files: Relation between schema id
& schema path
(*.gschema.xml
)
What is the schema XML file in the data/glib-2.0 folder of my Quickly application? by trent shows a nice example of using GSettings API in a Quickly application, and his conclusion based on his experience.
Back to Vino. Each application that uses GSsettings should define its schema's and should store/install them in /usr/share/glib-2.0/schemas/
(It's a glib directory):
$ dpkg -L vino | grep -i glib-2.0
/usr/share/glib-2.0
/usr/share/glib-2.0/schemas
/usr/share/glib-2.0/schemas/org.gnome.Vino.enums.xml
/usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xml
$ more /usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xml
<schemalist>
<schema id='org.gnome.Vino' path='/org/gnome/desktop/remote-access/'>
<key name='enabled' type='b'>
<summary>Enable remote access to the desktop</summary>
<description>
If true, allows remote access to the desktop via the RFB
protocol. Users on remote machines may then connect to the
desktop using a VNC viewer.
</description>
<default>false</default>
</key>
<key name='prompt-enabled' type='b'>
<summary>Prompt the user before completing a connection</summary>
<description>
If true, remote users accessing the desktop are not allowed
access until the user on the host machine approves the
connection. Recommended especially when access is not password
protected.
</description>
<default>true</default>
</key>
...
If you noticed, The schema is defined with an id
and a path
. The schema file name follows the id
value.
<schema id='org.gnome.Vino' path='/org/gnome/desktop/remote-access/'>
*.enums.xml
files are for custom enumeration declaration, to be used as new data types in *.gschema.xml
with same schema id
.
$ cat /usr/share/glib-2.0/schemas/org.gnome.Vino.enums.xml
<!-- Generated data (by glib-mkenums) -->
<schemalist>
<enum id='org.gnome.Vino.VinoIconVisibility'>
<value nick='never' value='0'/>
<value nick='always' value='1'/>
<value nick='client' value='2'/>
</enum>
</schemalist>
<!-- Generated data ends here -->
$ gsettings range org.gnome.Vino icon-visibility
enum
'never'
'always'
'client'
$ gsettings get org.gnome.Vino icon-visibility
'client'
Compiling Schema's (Ref: Playing with dconf and gnome-tweak-tool)
As part of the installation process (it has a dpkg trigger), schema's are compiled with glib-compile-schemas
tool (from glib)
sudo glib-compile-schemas /usr/share/glib-2.0/schemas
*.gschema.xml
will be compiled to a binary file /usr/share/glib-2.0/schemas/gschemas.compiled
Vendor Override Files (*.gschema.override
)
In addition to schema files, glib-compile-schemas
reads vendor override files, which are key files that can override default values for keys in the schemas (Ref: man glib-compile-schemas
). They contain the changes done by Ubuntu distribution to override upstream schema defaults.
$ ls /usr/share/glib-2.0/schemas/*.gschema.override
/usr/share/glib-2.0/schemas/10_compiz-gnome.gschema.override
/usr/share/glib-2.0/schemas/10_desktop-base.gschema.override
/usr/share/glib-2.0/schemas/10_evolution-common.gschema.override
/usr/share/glib-2.0/schemas/10_gnome-settings-daemon.gschema.override
/usr/share/glib-2.0/schemas/10_gnome-shell.gschema.override
/usr/share/glib-2.0/schemas/10_gnome-system-log.gschema.override
/usr/share/glib-2.0/schemas/10_gsettings-desktop-schemas.gschema.override
/usr/share/glib-2.0/schemas/10_libgtk-3-common.gschema.override
/usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override
/usr/share/glib-2.0/schemas/20_ubuntu-gnome-default-settings.gschema.override
$ cat /usr/share/glib-2.0/schemas/10_gnome-settings-daemon.gschema.override
[org.gnome.desktop.wm.keybindings]
switch-input-source=['<Super>space']
switch-input-source-backward=['<Shift><Super>space']
Example of override files use, See How to customize the Ubuntu Live CD? (5. Customization 2: Backgrounds and Themes).
Lock files
Currently, dconf supports only per-key locking, no sub-path lock. User defined values will still be stored in user-db
but will have no effect on applications. dconf/gsettings returns default values instead for those locked keys. Lock files are stored in db.d/locks/
. Example:
$ cat /etc/dconf/db/gdm.d/locks/00-upstream-settings-locks
/org/gnome/desktop/a11y/keyboard/enable
/org/gnome/desktop/background/show-desktop-icons
/org/gnome/desktop/lockdown/disable-application-handlers
/org/gnome/desktop/lockdown/disable-command-line
/org/gnome/desktop/lockdown/disable-lock-screen
/org/gnome/desktop/lockdown/disable-log-out
/org/gnome/desktop/lockdown/disable-printing
/org/gnome/desktop/lockdown/disable-print-setup
/org/gnome/desktop/lockdown/disable-save-to-disk
/org/gnome/desktop/lockdown/disable-user-switching
...
After locks modification, to be effective run:
sudo dconf update
A good showcase: dconf Settings: defaults and locks
Changing Global Settings
The default for gsettings
/dconf-editor
is to edit the user-db
. To change system-db
, write a new override file and recompile schema's.
I couldn't get this to work:
sudo su gdm -c 'gsettings ...'
neither the other answers here Set Default/Global Gnome Preferences (Gnome 3), may be that was for an old release.
Best Answer
If you want real-time monitoring, you could run the
dconf watch
command in a terminal, either to monitor a specific schema pathor the whole tree
which will show a running output as you change values, e.g. toggling the 'Desktop Sharing' security preference checkbox produces
If you just want a list of changes, you could use
dconf dump
redirected to a file to create before and after snapshots that you can then compare withdiff
.