After reading the following Q&A:
I want to do something similar in a declarative manner. I noticed the most related NixOS option is: services.xserver.desktopManager.gnome.extraGSettingsOverrides. Is there a way to do that for GDM? Or for an arbitrary user? (which will be gdm for this usecase of course).
This is how I declaratively configure gnome:
programs.dconf.profiles.user = {
databases = [{
lockAll = true;
settings = {
"org/gnome/desktop/interface" = {
color-scheme = "prefer-dark";
clock-format = "12h";
clock-show-weekday = true;
};
"org/gnome/desktop/media-handling" = {
automount = false;
automount-open = false;
autorun-never = true;
};
"org/gnome/settings-daemon/plugins/power" = {
sleep-inactive-ac-type = "nothing";
};
"org/gnome/mutter" = {
edge-tiling = true;
dynamic-workspaces = true;
experimental-features = ["variable-refresh-rate"];
};
};
}];
};
I believe you can configure GDM with the same sort of thing, but with the gdm profile rather than the user profile.
That is correct, and we have already discussed that in Gnome power button behavior when session is locked - #3 by doronbehar
But disabling suspend, specifically, has its own option: services.xserver.displayManager.gdm.autoSuspend
@jtojnar of course I remember our previous conversation - indeed this thread is a continuation. In my case I am not interested in disabling autoSuspend, but rather to reduce the idle-delay timeout.
What’s not clear to me, is the relation between gsettings and dconf: The implementation of services.xserver.displayManager.gdm.autoSuspend uses programs.dconf.profiles.gdm.databases and I’m not sure about the relation between a gsettings argument such as org.gnome.desktop.session > idle-delay and the dconf path. Should I do something like this:
programs.dconf.profiles.gdm.databases = [{
settings."org/gnome/settings-daemon/plugins/power" = {
# 30 seconds until automatic suspend
idle-delay = lib.gvariant.mkInt32 30;
};
}];
? Perhaps it’d be a good thing to document (the relation between dconf and gsettings)? Also, now I thought that it’d be nice to mention both available dconf / gsettings options of gdm in the documentation of the services.xserver.displayManager.gdm.settings option…
OK so my idle-delay attempt didn’t work, but this did:
programs.dconf.profiles.gdm.databases = [{
settings."org/gnome/settings-daemon/plugins/power" = {
power-button-action = "suspend";
# 10-20 seconds until automatic suspend is enough
sleep-inactive-ac-timeout = lib.gvariant.mkInt32 20;
sleep-inactive-battery-timeout = lib.gvariant.mkInt32 10;
};
}];
Still this topic is lacking documentation IMO. Both in terms of the upstream documentation for available dconf options, and also Nixpkgs’ lack of support for declarative gsettings, and the available declarative way to set dconf settings.
GSettings is a part of GLib library for handling application settings. It supports multiple storage backends, one of which is dconf database. This is a general Linux knowledge and we also briefly mention it in the NixOS manual.
GSettings is a bit more high level and it ensures the keys are set to correct values according to a schema. In contrast, dconf database will just store whatever GVariant value you give it.
dconf organizes values into a tree of named nodes. The inner nodes are called directories and leafs are keys. The root has an empty string as a name. Keys are GVariant typed values and can be referred to using paths, which consist of the sequence of names of nodes starting at the root, separated by /.
Each GSettings schema has an id and a slash-separated path, which maps directly to a dconf directory path. Though, gsettings command will expect you to just use schema ID for non-relocatable schemas, and will derive the path for a key as follows: /${builtins.replaceStrings [ "." ] [ "/" ] schemaId}/${keyName}.
There is no such key in that schema.
Perhaps you meant org.gnome.desktop.session. Though note that its type is uint32.
The plan is to eventually add GSettings module, which will provide validation against schemas to warn against wrong use like this.
We should definitely document the new programs.dconf.profiles.<profile>.databases in GNOME chapter of NixOS manual. It is on my to do list but I have not gotten around to it yet. I want to finish Support NixOS module · Issue #85 · nix-community/dconf2nix · GitHub first so that I can mention it there. It is also tied into the deprecation of extraGSettingsOverrides in favour of declarative dconf databases, which I want to do after proper documentation is ready.
GDM itself has no GSettings schemas, those are all from other GNOME components that only run as gdm user, which uses the gdm dconf profile.
The /etc/gdm/custom.conf controlled by that NixOS option has nothing to do with any of that. <rant>This is why I do not like NixOS options for settings, they often abstract away what is actually being set, reducing the transferability of general Linux knowledge.</rant>
Thanks @jtojnar for the details answer! Very much appreciated.
I too feel that. That’s why I tend to think that NixOS options should also document a bit more details about the documentation, something that some people tend to object to - that will help users figure out by themselves how to connect between general Linux knowledge and NixOS modules. But that’s a topic for another discussion :).