hyprlock: new module prevents specifying any other attributes

[kjkent]

With the recent addition of #619 (whoo new module btw, thanks @oscar-schwarz 🥳 ) , I've noticed that any attributes applied to the input-field setting cause a conflict with the Stylix module, e.g:

input-field = [
            {
              size = "200, 50";
              position = "0, -80";
              monitor = "";
              dots_center = true;
              fade_on_empty = false;
              outline_thickness = 5;
              placeholder_text = "Password...";
              shadow_passes = 2;
            }
          ];

I notice that in the HM module's example and in my config, the setting is given as a list, whereas the new Stylix module provides an attrset.

Or, are the examples to mean that multiple input fields can be defined, as I also have this in my config:

image = [
            {
              path = "${avatar}";
              size = 150;
              border_size = 4;
              border_color = "rgb(0C96F9)";
              rounding = -1; # Negative means circle
              position = "0, 200";
              halign = "center";
              valign = "center";
            }
          ];

which I assume means multiple images can be defined and positioned

Perhaps there's some merging strategy that can be used to set the color opts whether they're a list or attribute set?

Edit: I just tested, and changing my input-field from a single-item list to an attrSet has fixed things and the configs have merged without me needing to omit input-field from my config entirely. As the examples on Home Manager have it as a list.... should I close this or leave it open?

[trueNAHO]

I just tested, and changing my input-field from a single-item list to an attrSet has fixed things and the configs have merged without me needing to omit input-field from my config entirely. As the examples on Home Manager have it as a list.... should I close this or leave it open?

If the list functionality has a purpose, we should resolve this. Otherwise, we should submit a Home Manager PR updating the example, and once merged close this issue.

[oscar-schwarz]

The hypr syntax allows any option to be defined multiple times. In Nix language this is translated into the option name as the key and a list with all different values:

# home.nix
wayland.windowManager.hyprland.settings.bind = [
  "$meta, W, killactive"
  "$meta, M, fullscreen, 1"
  "$meta_CTRL, M, fullscreen"
  "$meta, K, togglefloating"
];

;; hyprland.conf
bind=$meta, W, killactive
bind=$meta, M, fullscreen, 1
bind=$meta_CTRL, M, fullscreen
bind=$meta, K, togglefloating

But for some reason you are also allowed to define just one value so instead of the value being inside the list it is just the value of the option. This is whats happening here. I naively assumed that everyone would just define their input_field as an attribute set because it does not make much sense to have multiple input fields on a lock screen.

[oscar-schwarz]

So I did some tinkering and found out that it's totally valid to have multiple input fields in hyprlock. Also stylix can assume that the value of the option is a list because there are zero advantages of using a set over using a list for input-field. So I tried to come up with a way to set the colors to all sets in the list. Quite logically I ran into an infinite recursion. Does anyone have an idea how to implement something like that?

#...
    programs.hyprlock.settings = {
      #...
      input-field = map (x: 
        x // {
          outer_color = "rgb(${base03})";
          inner_color = "rgb(${base00})";
          font_color = "rgb(${base05})";
          fail_color = "rgb(${base08})";
          check_color = "rgb(${base0A})";
        };
      ) config.programs.hyprlock.settings.input-field;
    };
#...

[trueNAHO]

Does anyone have an idea how to implement something like that?

Unless lib.mkOverride could somehow be used as a recursive base case, I cannot directly think of any ad hoc solution. Otherwise, we could try asking Home Manager to add an apply method for this parameter, although they might reject this proposal.

[danth]

So I tried to come up with a way to set the colors to all sets in the list. Quite logically I ran into an infinite recursion. Does anyone have an idea how to implement something like that?

From past experience I don't think this is possible without making changes upstream.

The "ideal" place to implement this would be in the NixOS option system itself, in a similar way to mkOverride / mkForce, but one which transforms the value with a function rather than replacing it entirely.

Or as mentioned, support could be added in Home Manager for this module in particular, but I doubt that would be appropriate unless it would also have a use case for a more general audience.