home-manager added.

[cernoh]

This pull request adds Home Manager integration for driftwm, allowing users to declaratively configure the window manager via their Home Manager configuration. The main changes introduce a Home Manager module and update the documentation to explain its usage.

Home Manager integration:

• Added a Home Manager module for driftwm in flake.nix, making it available as homeManagerModules.driftwm for import in user configurations.
• Updated README.md with detailed instructions and an example configuration for using the Home Manager module, including available options and a reference to the module source.

[malbiruk]

Thanks for putting this together! Before you invest more in it, I'd suggest a different shape.

A few blockers as-is: window_rules/outputs emit camelCase keys (appId), but the parser is deny_unknown_fields snake_case (app_id), so any rule fails to parse; those submodule entries also leak nulls into the TOML; and package = pkgs.driftwm won't resolve (no overlay / not in nixpkgs).

More fundamentally — hand-typing all ~120 options means this 955-line file has to track every config change by hand forever, and it's already drifted on day one. Neither niri nor Hyprland does that in-repo: Hyprland's HM module is ~16 lines and exposes config as one freeform settings attrset run through toml.generate, with the package defaulting to self.packages.${system}.default. I'd much rather take that version — ~40 lines, can't desync, and keys match config.reference.toml 1:1.

Heads up: @dominicegginton is planning Nix work in #143 too — worth syncing so we land one coherent setup instead of two overlapping ones.

[cernoh]

Thanks for putting this together! Before you invest more in it, I'd suggest a different shape.

A few blockers as-is: window_rules/outputs emit camelCase keys (appId), but the parser is deny_unknown_fields snake_case (app_id), so any rule fails to parse; those submodule entries also leak nulls into the TOML; and package = pkgs.driftwm won't resolve (no overlay / not in nixpkgs).

More fundamentally — hand-typing all ~120 options means this 955-line file has to track every config change by hand forever, and it's already drifted on day one. Neither niri nor Hyprland does that in-repo: Hyprland's HM module is ~16 lines and exposes config as one freeform settings attrset run through toml.generate, with the package defaulting to self.packages.${system}.default. I'd much rather take that version — ~40 lines, can't desync, and keys match config.reference.toml 1:1.

Heads up: @dominicegginton is planning Nix work in #143 too — worth syncing so we land one coherent setup instead of two overlapping ones.

thanks for the reply!! I do see how that would be easier, I thought it might be simpler in the way of exposing them as options for sites like searchix, but thats a better idea :) I'll check that out instead it might be more succinct