* home.pointerCursor: init
The current architecture for cursor configurations is composed of individual
options for different backends. For example, X specific settings are managed under
`xsession.pointerCursor` and gtk specific settings are managed under `gtk.cursorTheme`.
While this architecture is modular, it causes duplication of similar structures for
each component. In theory, this provides flexibility because the components are independent
of each other which can be arranged in arbitrary ways to achieve the desired result.
However in practice, users wish to have one cursor theme applied to their entire system
The duplication of options correspond to duplication of settings on the user side and it
becomes a burden to keep track of all necessary settings.
This commit is an attempt to unify cursor configurations for different window systems and
GUI toolkits based on https://github.com/nix-community/home-manager/pull/2481#issuecomment-978917480.
`home.pointerCursor` is introduced as the interface for all cursor configurations.
It contain all options relevant to cursor themes with eneral options delcared under `home.pointerCursor.*`
and backend specific options declared under `home.pointerCursor.<backend>.*`. By default, a backend
independent configuration is generated. Backend specific configurations can be toggled via the
`home.pointerCursor.<backend>.enable` option for each backend. This was decided over using a
list of enums because it allows easy access to the state of the backend. Note generating different
cursor configurations for different backends is still possible by defining only `home.pointerCursor`
and managing the respective options manually.
* xcursor: migrate options to home.pointerCursor
- Removed `xession.pointerCursor` as x11 cursor configurations are now handled in `home.pointerCursor.x11`.
- Updated `meta.maintainer` field in `home.pointerCursor` and CODEOWNERS.
Nix permits user level configurations through ~/.config/nix/nix.conf that allow
customization of system-wide settings and behavior. This is beneficial in chroot
environments and for per-user configurations. System level Nix configurations in the
form of /etc/nix/nix.conf can be specified declaratively via the NixOS nix module but as
of currently no counter part exists in home-manager.
This PR is a port of the RFC42 implementation for the NixOS nix module[1]
to home-manager. Non-applicable options have been excluded and the config generation
backends have been tweaked to the backends offered by home-manager. A notable change
from the NixOS module is a mandatory option to specify the Nix binary corresponding
to the version "nix.conf" should be generated against. This is necessary because
the validation phase is dependent on the `nix show-config` subcommand on the host platform.
While it is possible to avoid validation entirely, the lack of type checking was deemed too significant.
In NixOs, the version information can be retrieved from the `package` option itself which
declares the Nix binary system-wide. However in home-manager, there is no pure way to
detect the system Nix version and what state version the "nix.conf" should be generated
against. Thus an option is used to overcome this limitation by forcing the user to
specify the Nix package. Note this interaction can still be automated by forwarding
the system-wide Nix package to the home-manager module if needed.
Three unit tests were added to test the module behavior for the empty settings, the example
settings and the example registry configurations respectively.
[1] - NixOS/nixpkgs#139075
Note, the pubs configuration file uses ConfigObj syntax, which is
similar to the INI files syntax but with extra functionalities like
nested sections. This prevents it from using Nix's INI format
generator. Here is an example of pubs configuration that cannot be
generated using Nix's INI format generator:
[plugins]
[[git]]
manual=False
For this reason, we opted for a stringly-typed configuration since the
use of a structured `settings` option would require a custom parser.
Watson is a CLI for tracking your time.
Two unit tests were added to validate the module behavior for an empty
configuration and the example configuration.
Swayidle is an idle management daemon for Wayland. This modules adds support for
running swayidle as a SystemD user unit and makes it configurable through
home-manager.
Swaynag is a replacement of i3-nag for sway. Swaynag is embedded in
Sway's build process albeit it is not an integral part of Sway,
therefore it has been added under `wayland.windowManager.sway` instead
of `programs`. It can be moved at a later time if necessary.
Two unit tests were added validate the module behavior for an empty
configuration and the example configuration.
