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 :).
Hello folks! And thanks @jtojnar for the detailed answer above, it helped me figure out a bit more how all of this works under the hood!
I’m slowly migrating to NixOS completely, but I’m stuck at enabling gnome extensions…
I took a look at NixOS Gnome chapter about extensions. Have you updated the doc since your last post in this thread?
services.xserver.desktopManager.gnome.extraGSettingsOverrides, from some GH issues (e.g. #216291)What’s remaining to be able to enable and configure gnome extensions declaratively? So I can take a look and try to understand, possibly
The .nix conf I have today that only works for the gnome settings so far, in case I’m doing something wrong (not the extensions) :
{ config, pkgs, lib, ... } :
{
programs.dconf = {
enable = true;
profiles.user.databases = [{
settings = with lib.gvariant; {
# Enable installed extensions (doesnt seem to work yet...)
"org/gnome/shell" = {
disable-user-extensions = false;
enabled-extensions =
builtins.map
(x: x.extensionUuid)
(lib.filter (p: p ? extensionUuid) config.environment.systemPackages);
}
"org/gnome/desktop/interface" = {
color-scheme = "prefer-dark";
gtk-theme = "adw-gtk3-dark";
};
};
}];
}
}
I do not regret having discovered NixOS, except some issues to make it feel home, otherwise everything looks easier from a configuration point of view so far.
Details about my current installation :
Cheers!
Potential interesting links :
No progress so far.
Yes.
Yes, it’s the programs.dconf.profiles.<name>.databases NixOS option.
You can use the NixOS dconf module as well.
extraGSettingsOverrides will work too for enabling extension – it only has issues with configuring extensions (as per #216291) but enabling extensions is done by configuring GNOME Shell, which works fine. Though the caveat about it only changing the default value applies so I would not recommend actually using extraGSettingsOverrides here.
Yes, it will be changing values, not just the defaults, as it should use dconf module internally.
I do not think it is relevant anymore now that we have the dconf module.
The dconf store is hierarchical (see /etc/dconf/profile/user) and will prefer a value from the top-most database (probably user-db in your case). You can try dconf reset /org/gnome/shell/enabled-extensions or even add the key name to locks option.
@Grraahaam As you have already mentioned the corresponding home-manager module: Do you need any help with enabling GNOME extensions using that?