Home manager module

[Theaninova]

Resolves #60

I'm marking this as a draft as I feel like it warrants some discussion.

I've made this sorta the most minimal home manager module possible.

Settings are exactly the way they are documented for toml (just nix here), and the file gets placed via home manager.

There's definitely both an argument for defined options like you usually have, though in this case you'd have to always make sure they're up-to-date, keep flexibility, etc. This is usually done though something like an extraSettings option from what I've seen.

Example config

programs.matugen = {
  enable = true;
  settings = {
    config = {
      reload_apps = true;
      set_wallpaper = true;
      wallpaper_tool = "Swww";

      custom_colors.red = "#ff0000";
      custom_keywords.padding = 14;
    };

    templates.kitty = {
      input_path = ./kitty.conf;
      output_path = "${config.xdg.configHome}/kitty/theme.conf";
    };
  };
};

A wrapper script is not part of this, I feel like this is out of scope. I make mine like this

home.packages = [
  (pkgs.writeShellApplication {
    name = "matugen-wrapper";
    runtimeInputs = [ pkgs.matugen ];
    text = ''
       matugen wallpaper ${./wallpaper.png}
    '';
  })
];

(for reference, this is my home manager setup)

[InioX]

I'm fine with removing the wrapper script, it would still be nice to provide a very basic example in the README or somewhere inside the wiki though.

[Theaninova]

I'd be happy to make contributions to the wiki regarding that (as well as the recent custom color changes), though I've not been able to figure out how to do that.

[DaniD3v]

oh sorry for taking so long I just started writing my own module.

Instead of doing this

reload_apps = true;
set_wallpaper = true;
wallpaper_tool = "Swww";

home-manager modules usually just use tomlFormat.generate with a settings options. The way my module works rn is

programs.matugen = {
    enable = true;

    settings = {
      config = {
        reload_apps = false;
        reload_apps_list = {
          gtk_theme = true;
          dunst = true;
        };
      };
    };
  };

and with a submodule

 programs.matugen.templates.firefox = {
    input_path = ../../external/templates/colors.json;
    output_path = "${config.xdg.cacheHome}/wal/colors.json";
  };

This is way more flexible and doesn't change much on the user side of things. Give a bit more time I'll make both of them work (also declaratively generating everything)

Also I'd leave the wrapper script in. That way it can automatically remove the symlinks from home-manager when re-generating and makes it possible to have a default declerative wallpaper and a imperative wallpaper by calling the program.

[Theaninova]

The first thing you made looks really similar to what I did.

I don't know about the wrapper, that feels outside of the Nix module's responsibility. If you think that there should be a default wallpaper option, it should probably be an option for everyone in the matugen toml config, which would also automatically solve the issue for Nix users.

I'm also a bit confused about the non-home-manager module, what's the purpose of that? Usually people who are interested in setting up per-user configs have or should have a home manager setup, the current implementation seems really hacky.

[DaniD3v]

I'm also a bit confused about the non-home-manager module, what's the purpose of that? Usually people who are interested in setting up per-user configs have or should have a home manager setup, the current implementation seems really hacky.

agreed I dislike the osCfg part.

I made a PR with the module I wrote at #68 if you want to take a look at the code or smt I also explain why I'd like the wrapper script there

Really sorry for making a duplicate PR. I didn't realize you made one

[Theaninova]

No worries. I think the template part is unnecessary in your pr, and I still think the wrapper should probably not be part of the module, but either of the PRs should work fine. I'm using my branch right now in my NixOS config.

[AtomicTroop]

Hi, considering this PR hasn't moved in a few months but seems to be in a pretty good shape, is there a chance to get this finalized for the 2.4.0 release?

I could use the feature myself so I can pitch in some effort if there's anything I could help with.