When we are in a sandboxed situation, bump the priority
of the keyfile settings backend above the dconf one,
so we use a keyfile inside the sandbox instead of requiring
holes in the sandbox for dconf.
Stacked databases and locks are dconf features that allow
management software like Fleet Commander to set system-wide
defaults and overrides centrally for applications.
This patch adds minimal support for the same to the keyfile
backend. We look for a keyfile named 'defaults' and a
lock-list named 'locks'.
Suitable files can be produced from a dconf database with
dconf dump and dconf list-locks, respectively.
The default location for these files is /etc/glib-2.0/settings/.
For test purposes, this can be overwritten with the
GSETTINGS_DEFAULTS_DIR environment variable.
Writes always go to the per-user keyfile.
Make it possible to instantiate a keyfile settings backend
without specifying parameters, by turning the arguments to
the new() function into construct-only properties. If no
filename is specified, default to
$XDG_CONFIG_HOME/glib-2.0/settings/keyfile
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
Ignore the keyfile being deleted (ie: by the user) instead of reporting
it to the application as all values being reverted back to their
originals.
https://bugzilla.gnome.org/show_bug.cgi?id=637956
The keyfile backend forms paths like this:
prefix + group_name + '/' + keyname
If the prefix is '/apps/yelp/' and the group name is '/' then this means
that we end up with a key name of (for example):
'/apps/yelp/' + '/' + '/' + 'font-adjustment'
= '/apps/yelp///font-adjustment'
which is obviously not a valid key name.
This patch rejects group names starting or ending with '/' or containing
'//' and also rejects keys containing '/'. This should make it
impossible for invalid keys to be formed.
