[WIP] nixos: add environment.gnome3.enableExtensions

[bjornfor]

Motivation for this change

I'd like to enable/disable GNOME3 extensions from configuration.nix. However, when testing this I learned that services.xserver.desktopManager.gnome3.extraGSettingsOverrides, which this is built upon, only provides default values for the system. Users are still able to change settings. And once they have made a change, any change to the system default will be ignored. This is marked WIP since I'd like for this setting to be truly declarative. The first 4 commits would be nice to merge anyway, so one can play with this locally at least.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Fits CONTRIBUTING.md.

---

[hedning]

dconf settings are stored per user (under ~/.config/dconf), so it would be hard to enforce fully I think.

But something like running dconf reset /org/gnome/shell/enabled-extensions as the user on startup might work OK though?

[bjornfor]

dconf settings are stored per user (under ~/.config/dconf), so it would be hard to enforce fully I think.

According to this, one should be able to create lock files that prevent users from doing modifications. In my last fixup commit you can see I try to use it, but it didn't work for me.

Your "dconf reset ..." command sounds good. What setting in NixOS is best for running commands at user login time? (I'd like something shell agnostic.)

[bjornfor]

Well, the commit that tries to create dconf lock files does not do the "dconf update" step. I did that manually.

[jtojnar]

See also #54150

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/recommended-way-to-add-gnome-extensions/5589/3

[bbigras]

Any progress on this?

[bjornfor]

Not from my side.

[bbigras]

What is needed to move this PR forward?

Does #54150 needs to be done first?

[bjornfor]

Does #54150 needs to be done first?

Yep, that's what I'm thinking.

[stale]

I marked this as stale due to inactivity. → More info

[Alizter]

Any news on this?

[bjornfor]

Any news on this?

No, #54150 still needs to land first.

[linsui]

You can use the dconf module now.

[bjornfor]

You can use the dconf module now.

Right, there was another PR (not linked here) that fixed it! Cool!

I'll put this back on my TODO list.

[ulysses4ever]

#54150 has ben merged. Anything else left before this one can land?

[bjornfor]

#54150 has ben merged. Anything else left before this one can land?

This PR needs a rewrite. It's not high priority for me, as I'm using home-manager for my gnome extensions. Someone please make new PR on top of #54150.

[WillsterJohnson]

#54150 has ben merged. Anything else left before this one can land?

This PR needs a rewrite. It's not high priority for me, as I'm using home-manager for my gnome extensions. Someone please make new PR on top of #54150.

How are you doing this via home-manager? I looked at your repo but I see it's been a while since that mirror got an update

[bjornfor]

How are you doing this via home-manager?

Using the dconf module. For example:

{ pkgs, lib, ... }:

let
  # Make widgets smaller to not clip other widgets (default: 100).
  graphWidth = 95;
in
{
  dconf.settings."org/gnome/shell".enabled-extensions = [
    pkgs.gnomeExtensions.system-monitor-next.extensionUuid
  ];

  dconf.settings = {
    "org/gnome/shell/extensions/system-monitor" = {
      # Highlight IO wait with dark red
      cpu-iowait-color = "#a40000ff";

      disk-display = true;
      # In the default color scheme it's impossible to separate reads and
      # writes.
      disk-read-color = "#00ff00ff"; # bright green
      disk-write-color = "#ff0000ff"; # bright red

      cpu-graph-width = graphWidth;
      memory-graph-width = graphWidth;
      net-graph-width = graphWidth;
      disk-graph-width = graphWidth;
    };
  };
}

I looked at your repo but I see it's been a while since that mirror got an update

Yes, I intentionally stopped updating it.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/changing-gdm-gsettings-declaratively/49579/8

[Grraahaam]

Just to update this thread if ever someone is looking for some answers. As mentioned above, the dconf module is now available.

Here's an example on how to install and enable gnome extensions directly with the dconf module (thanks @Electrostasy) :

{ config, pkgs, lib, ... }:

{
  environment.systemPackages = with pkgs.gnomeExtensions; [
    blur-my-shell
    desktop-cube
    native-window-placement
    panel-date-format
    tiling-shell
    unblank
    user-themes
    system-monitor
  ];

  programs.dconf.profiles.user.databases = [{
    settings = with lib.gvariant; {
      "org/gnome/shell".enabled-extensions =
        builtins.map
          (x: x.extensionUuid)
          (lib.filter (p: p ? extensionUuid) config.environment.systemPackages);
    };
  }];
}

Additionally here's a fix to make it work without having to reboot (logout/in only), again thanks @Electrostasy!

  # Normally, when dconf changes are made to the `user` profile, the user will
  # need to log out and log in again for the changes to be applied. However,
  # in NixOS, this is not sufficient for some cases (automatically enabling
  # extensions), because on a live system, the /etc/dconf path is not updated
  # to the new database on activation. This restores the intended behaviour.
  system.activationScripts.update-dconf-path = lib.mkIf config.programs.dconf.enable {
    text = ''
      dconf_nix_path='${config.environment.etc.dconf.source}'
      if ! [[ /etc/dconf -ef "$dconf_nix_path" ]]; then
        ln -sf "$dconf_nix_path" /etc/dconf
        dconf update /etc/dconf
      fi
    '';
  };

Note

If your extensions aren't enabled, run dconf reset /org/gnome/shell/disabled-extensions and dconf reset /org/gnome/shell/enabled-extensions, to make sure dconf follows what's in your config

Since we can enable extensions that way (and through home-manager), is this PR still relevant? @bjornfor @jtojnar

Discussed here

Edit: Gnome extensions now also include their own UUID, so you only have to add them up to your systemPackages to benefit from the dynamic mapping to enable them (or any other array containing the extension packages)

[bjornfor]

Since we can enable extensions that way (and through home-manager), is this PR still relevant? @bjornfor @jtojnar

I still think it's valuable to have a simple interface. Why not turn your code above into a NixOS module with environment.gnom3.enableExtensions = [ ... ] interface?

[Grraahaam]

I still think it's valuable to have a simple interface. Why not turn your code above into a NixOS module with environment.gnom3.enableExtensions = [ ... ] interface?

I agree that having something easier could help.

I have a working local module for this. The config path seems to be environment.gnome.<key> now (e.g. excludePackages).

I'm wondering if I should also add up a module similar to what home-manager does with dconf.settings, and use UUID as keys (or something easier to map an extension to its settings, or keep the dconf way), in order to avoid to write the long programs.dconf.profiles.user.databases.settings + dconf keys, something like :

environment.gnome.extensionsSettings = {
  pkgs.gnomeExtensions.system-monitor.extensionUuid = {
    key = "value";
  };
  pkgs.gnomeExtensions.user-themes.extensionUuid = {
    key = "value";
  };
};

@jtojnar Do you think enableExtensions and potentially extensionsSettings are interesting? If yes I'll continue and open another PR

[jtojnar]

You would need to interpolate it with ${pkgs.gnomeExtensions.system-monitor.extensionUuid}, otherwise the attribute set would contain something like the following:

{
  pkgs = {
    gnomeExtensions = {
      system-monitor = { extensionUuid = { key = "value"; }; };
      user-themes = { extensionUuid = { key = "value"; }; };
    };
  };
}

But I do not think there is a relation between the UUID and schema id for most extensions.

---

Also, I generally prefer generic options instead of creating specific options (in line with RFC42). enableExtensions would probably be fine since we can just redirect it to programs.gsettings.settings."org.gnome.shell".enabled-extensions + programs.gsettings.schemaPackages once that is implemented. It would be harder to do that for random extensions without somehow keeping track of the UUID → package mapping.