treewide: artificially extend hot reloading support

[trueNAHO]

As mentioned in https://github.com/nix-community/stylix/discussions/371, https://github.com/nix-community/stylix/issues/447, and https://github.com/nix-community/stylix/issues/530, hot reloading support is application dependant.

However, Omarchy artificially extends its hot reloading support with additional code. Trivial implementations include:

# Trigger alacritty config reload
touch "$HOME/.config/alacritty/alacritty.toml"

# Restart components to apply new theme
pkill -SIGUSR2 btop
omarchy-restart-waybar
omarchy-restart-swayosd
makoctl reload
hyprctl reload

-- github:basecamp/omarchy, /bin/omarchy-theme-set:42

Stylix could do the same to some extent with activation scripts when running nixos-rebuild switch or home-manager switch. Ideally, these restarts happen only on rebuilds and not on startups.

[trueNAHO]

On second thought, it might be better to upstream (NixOS, Home Manager, nix-darwin, and Nix-on-Droid) this as general config hot reloading. If that is the case, we should close this issue as "not planned" an open upstream issues, while linking to this issue.

I suppose the Home Manager implementation would look something like:

• # Core logic.
  
  lib.hm.mkReloadOption = name: lib.mkOption {
    default = null;
    description = "Config hot reload script for ${name}.";
    type = with lib.types; nullOr lines;
  };
  
  home.activation.reloadConfig = builtins.concatStringsSep "\n\n" (
    # For performance (while keeping the nice builtins.filter output), it might
    # be better to do the following:
    #
    #     builtins.filter (reload: reload != null) (
    #       map
    #       (cfg: if cfg.enable && cfg.reload != null then cfg.reload else null)
    #       (/* Recursively (or somehow else) get top-level module options. */)
    #     )
    builtins.filter (reload: reload != "") (
      map
      (cfg: lib.optionalString (cfg.enable && cfg.reload != null) cfg.reload)
      (/* Recursively (or somehow else) get top-level module options. */)
    )
  );
  

• # Consumer: /modules/services/window-managers/hyprland.nix
  
  options.wayland.windowManager.hyprland.reload = lib.hm.mkReloadOption "Hyprland";
  config.wayland.windowManager.hyprland.reload = "hyprctl reload";
  

[danth]

Yes, I think it makes more sense to implement this upstream. A small number of Home Manager modules already have this. There's an onChange option for files which can be used to trigger the reload only when a relevant file has changed, rather than on every activation.

[trueNAHO]

A small number of Home Manager modules already have this. There's an onChange option for files which can be used to trigger the reload only when a relevant file has changed, rather than on every activation.

Indeed. I forgot about onChange, considering how rarely it is used:

$ git checkout --quiet f35703b412c67b48e97beb6e27a6ab96a084cd37 && # Home Manager: 2025-09-02
    rg 'onChange =' | wc --lines
20

In that case, this issue (or a new one) should be converted to a tracking issue about which Stylix modules implement onChange upstream.

Until we start working on the following feature, it might be better to wait with the tracking issue to avoid maintenance burden of keeping it up-to-date:

• [ ] (7) Support automatic polarity switch based on sunset and sunrise
  • https://github.com/nix-community/stylix/issues/447#issuecomment-2351837256

-- https://github.com/nix-community/stylix/issues/534