hyprland: add hyprpaper.enable option and improve code

[trueNAHO]

This patchset contains the following commits:

• hyprland: add hyprpaper.enable option
• hyprland: structurally separate unconditional and conditional settings
• hyprland: inline single-use variable
• hyprland: reduce local variable scopes
• hyprland: remove with statement

Closes: #499

---

Note that I have not actually tested this PR, and as such it may contain silly errors.

This PR has been tested:

Yup, just tested on your branch and everything hyprpaper was removed upon rebuilding once it was set to false. And once adding hyprpaper manually, my wallpaper script is working perfect so far. So seems to be working to me.

-- #499 (comment)

[trueNAHO]

It would be nice to have this merged before #519.

[danth]

Couldn't we just use lib.mkDefault when setting services.hyprpaper.enable, then users can override it by setting that to false directly?

[trueNAHO]

Couldn't we just use lib.mkDefault when setting services.hyprpaper.enable, then users can override it by setting that to false directly?

I don't think we have any consistency throughout the project in that regard yet. However, providing a Stylix option in this case has two main benefits:

1. Additional functionality is more explicit to end-users without looking at the implementation.

2. Added functionality may be arbitrarily large (more than just one <OPTION>.enable = stylix.targets.<TARGET>.enable; declaration) and can be toggled with one interface option. For example, the hyprpaper.enable option would toggle the following code block:

   stylix/modules/hyprland/hm.nix

   Lines 42 to 45 in c985b64

   	lib.mkIf cfg.hyprpaper.enable {
   	services.hyprpaper.enable = true;
   	stylix.targets.hyprpaper.enable = true;
   	}

[drishal]

Couldn't we just use lib.mkDefault when setting services.hyprpaper.enable, then users can override it by setting that to false directly?

I don't think we have any consistency throughout the project in that regard yet. However, providing a Stylix option in this case has two main benefits:

1. Additional functionality is more explicit to end-users without looking at the implementation.

2. Added functionality may be arbitrarily large (more than just one `<OPTION>.enable = stylix.targets.<TARGET>.enable;` declaration) and can be toggled with one interface option. For example, the `hyprpaper.enable` option would toggle the following code block:
   https://github.com/danth/stylix/blob/c985b64469b0408eea990fe3c655cf7c010cf206/modules/hyprland/hm.nix#L42-L45

I think having services.hyprpaper.enable = true; might be a bad idea, since I would not want that to always autostart if I have other window managers installed

[trueNAHO]

I think having services.hyprpaper.enable = true; might be a bad idea, since I would not want that to always autostart if I have other window managers installed

This PR resolves this exact issue by providing an interface option to disable all associated hyprpaper behaviour. IIRC, this PR also closes #499.

[trueNAHO]

Changelog

v2: 40bc8db

• Add Link: https://github.com/danth/stylix/pull/501 tag to every commit
• Rebase on top of commit 63426a5 ("forge: init (forge: init #573)")

v1

• I don't remember the specific changes made between v0 and v2. But they should be very minor.

v0: 2aa427c

[trueNAHO]

@danth, IIRC, this PR is ready to merge.

[trueNAHO]

Changelog

v3: 7b5d7cc

• Rebase on top of commit 04afcfc ("gnome: fix GDM theme not applying when Gnome is disabled (gnome: fix GDM theme not applying when Gnome is disabled #598)")

v2: 40bc8db

• Add Link: https://github.com/danth/stylix/pull/501 tag to every commit
• Rebase on top of commit 63426a5 ("forge: init (forge: init #573)")

v1

• I don't remember the specific changes made between v0 and v2. But they should be very minor.

v0: 2aa427c

[trueNAHO]

Merging v3 on top of #608 resolves the merge conflicts.

[trueNAHO]

Merging v3 on top of #608 resolves the merge conflicts.

#608 has been merged, making this PR merge-ready again.

[danth]

Looks good to me. Sorry for the delay, this got buried at the bottom of my notifications.

[trueNAHO]

Changelog

v4: c6547e2

• Rebase on top of commit eb918db ("doc: standardize license formatting (doc: standardize license formatting #661)")

v3: 7b5d7cc

• Rebase on top of commit 04afcfc ("gnome: fix GDM theme not applying when Gnome is disabled (gnome: fix GDM theme not applying when Gnome is disabled #598)")

v2: 40bc8db

• Add Link: https://github.com/danth/stylix/pull/501 tag to every commit
• Rebase on top of commit 63426a5 ("forge: init (forge: init #573)")

v1

• I don't remember the specific changes made between v0 and v2. But they should be very minor.

v0: 2aa427c

[trueNAHO]

@danth, should we merge future patchsets (a series of commits) as a merge commit, as in commit e309d64, or as fast-forward merges? FYI, I do not have permission to do fast-forward merges ("Rebase and merge") through the GitHub UI: