-
-
Notifications
You must be signed in to change notification settings - Fork 17k
Description
GLib’s GSettings system stores application settings in one of supported backends and uses compiled schemas (located in $XDG_DATA_DIRS/glib-2.0/schemas/gschemas.compiled
) to determine type and default value of configuration keys. The schemas are compiled from XML files provided by applications and optionally, the default value can be changed by overrides.
Current situation
At the moment, we use GSettings overrides to declaratively change settings for GNOME & co., relying on the overridden default value. While this is great for non-important things like distribution-default background image, it suffers from many problems and inconveniences:
- Since the compiled schemas are looked up in
XDG_DATA_DIRS
on first come, first served basis, we need to make sure our overrides are first in the chain. This is only possible by patching GLib. - Passing the
NIX_GSETTINGS_OVERRIDES_DIR
environment variable to applications is fragile. It does not really work for things like display managers, resulting in issues like GNOME keeps suspending on unstable #42053 - It is easy to change a setting key in the user interface, breaking the overrides.
- Compiling overridden schemas requires packages with matching XML definitions.
extraGSettingsOverrides
option needs to be written in keyfile syntax, it would be much more convenient if we could use Nix syntax.
The goal of this issue is to attack the problem from the other side: modifying the backend.
Going through the backend
On Linux, the dconf backend is commonly used. It will select a profile pointing to a list of binary databases that are used for retrieving settings, see its overview for the gory details. Since the database is binary, the attrsets serialized into keyfiles will need to be compiled with dconf compile
Our dconf module can create profiles, which GDM module is incorrectly taking advantage of. In order to be able to configure application declaratively, we would also need to generate keyfiles and compile them to databases.
We probably do not want people to have to spell everything out
programs.dconf.profiles.user = pkgs.writeText "dconf-user-profile" ''
user-db:user
system-db:nixos
'';
programs.dconf.systemDatabases.nixos.system.proxy.http.host = "172.16.0.1";
It is not clear to me how should we handle locking – do we allow users to change the keys set through the module? Do we add lock control in the module?
Interesting links
Metadata
Metadata
Assignees
Labels
Type
Projects
Status