2.0 introduces some kind of breaking change that results in the cursor
appearing larger than usual, which I haven't been able to find an answer
for. The 1.1 cursor has been great already, so I'll probably stick with
that until further notice.
Simplifies things a bit since my target audience includes those
interested in the Japanese language. Opinionated defaults like this
makes it easier for end-users to be immediately productive without
having to spend time configuring things.
Note that we will continue to use nixpkgs-fmt for the time being here
since nixfmt-rfc-style breaks string syntax highlighting and comments
like `/* this */` get turned into `# this`.
The conversion from lisp-like formatting to something else in flake.nix
is a bit unfortunate, but I'd rather have a singular style for the
entire code base to make things easier.
This change makes it possible to use this nix-config in all the
different ways imaginable (containers, bare metal, tests, and as a
separate flake input) *without* running into infinite recursion
issues with self.
It does this by using a trick similar to JavaScript in which
`var self = this;`, thus enabling the usage of "this" (or self, in
Nix's case) where it wouldn't otherwise be possible.
Note that this *only* works if the input for this repository is named
nix-config. This makes it impractical to combine with multiple
configurations that employ the same strategy.
This change makes it possible to import the modules that are required
from the flake inputs in the output modules themselves, thus preventing
users from having to manually import those modules.
This simplifies things overall and was made possible by the specialArgs
option that allowed these flake inputs to be passed into our container.
Now it's possible to use whatever username you want for your system. The
default value of "user" is good if you're concerned about information
disclosure attacks through things like the username being visible in
logs or other output.
This continues the process of simplifying the available modules for
end-users. The final result would be having a clear set of modules like
"desktop" and "shell" that can be enabled if users want a complete
Hyprland environment or a complete shell environment.
Enabling the stylix module "only" would be a low-tech solution and at
that point it'd likely be better for end-users to take complete control
of their stylix config with their own module.
Thunar is an opinionated file manager that we're using as the GUI
application of choice because it handles directories with large files
*significantly* better than Nautilus. It also supports image previews
for files that have been trashed, as well as a slew of other convenience
features such as a built-in auto-renaming tool.
Long-term this should make it easy to include all the GUI programs with
the desktop module and all the CLI programs with the shell module, as
well as the ability to easily disable sets of unneeded packages.
This is the start of making it possible to include desktop-related
configuration options instead of only hyprland-related ones.
This simplifies things a bit since opinionated configurations can be
hidden behind an option and end users won't have to worry about all
the different possible modules they could import.
Although it would be nice to use a Wayland image viewer, currently all
of them (that I am aware of) suffer from anti-aliasing issues not present
in feh.
Alacritty does not support MapleMono-NF as a font, whereas kitty does.
kitty also has other nice features such as built-in windows/tabs and
image support.
Note that loading a runtime file in ~/.cache/wal is no longer necessary
since configuration is done declaratively through Nix.
Although this has some downsides, such as the lack of "live reloading"
in some applications, this "feature" wasn't present across all
applications anyway.
