Migrates from the deprecated toCommandLineShell to toCommandLineShellGNU.
This changes the output format from space-separated short options
(-c /path) to concatenated GNU-style options (-c/path). Both formats
were verified to work correctly with redshift and gammastep.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Migrates from the deprecated toGNUCommandLineShell to toCommandLineShellGNU.
This changes the output format from space-separated short options
(-t 3500) to concatenated GNU-style options (-t3500). Both formats
were verified to work correctly with wlsunset.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Replace deprecated lib.cli.toGNUCommandLine with lib.cli.toCommandLineGNU.
Should support the GNU style of convention.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Currently, if cfg.network.listenAddress is set to "any", MPD_HOST causes
partial evaluation which fails the sanity check while trying to build a
home-manager generation. Hence make a separate attrset for MPD_HOST
which will be evaluated conditionally and then concatenated.
Signed-off-by: Amneesh Singh <natto@weirdnatto.in>
From the code-review, buildScriptPackages was deemed unnecessary and so
has been removed. The ghc package with dependencies was not needed when
building without a custom build script so this build dependency has been
made contingent on the presence of a custom build script. The install
command is used instead of cp and chmod. Finally, an example has been
added for the documentation.
If you need to change ghc args, or maybe want to use cabal or stack to
build xmonad, a way of doing this is write a script called build which
overrides xmonad's default build behaviour.
This patch adds two extra (optional) config options to xmonad:
- buildScript, a path to said build script
- buildScriptPackages, any additional dependencies it may need
In the code base, there are lots of configurations locally guarded by
`stdenv.hostPlatform.is(Darwin|Linux)` despite the targeted options
already being guarded. Examples for these targeted options are:
- `systemd.user.*`: globally guarded by `systemd.user.enable`.
- `launchd.*`: globally guarded by `launchd.enable`.
- `lib.hm.darwin.assertInterval`: only effective on Darwin.
These local guards are an antipattern since they weaken the global
guards. Furthermore, they hamper readability. This series of commits
remove instances of these local guards.
Add systemd service ordering dependencies to prevent EasyEffects from
starting before the Wayland compositor is ready.
**Problem:** EasyEffects would crash during login with "Failed to create
wl_display (No such file or directory)" if started before the Wayland
display server was fully initialized.
**Solution:** Declaring the "After" property ensures EasyEffects waits
for the graphical session to be fully ready. The "PartOf" properly stops
EasyEffects when logging out. Got the tip from
https://github.com/wwmm/easyeffects/issues/1310.
Tested on NixOS 25.11 (Xantusia, 20251223.76701a1) and Home Manager 25.11
(0999ed8) with GNOME 49 on Wayland.
Since PR #8099, the module sets `$SSH_AUTH_SOCK` through shells' options
for interactive shell initialization instead of
`home.sessionVariablesExtra`. The replacement was not faithful, however,
since `home.sessionVariablesExtra` is sourced also in non-interactive
shells. With this commit, the shells' profile options (where
`home.sessionVariablesExtra` is sourced) are used to set
`$SSH_AUTH_SOCK`.
Fixes#8129.
The `herbstclient` alias in the generated `autostart` made it impossible
to use bash functions.
This makes the `herbstclient` alias optional by adding an extra
`herbstclientAlias` option on the herbstluftwm configuration. The new
option defaults to `false` as to not confuse newcomers to the
herbstluftwm module, which is not a breaking change because it was only
an optimization.
The defaultEditor option sets {env}`EDITOR` however strictly speaking
{env}`EDITOR` is intended for editors that are fully compatible with
teletype terminals (ex: `ed` or `vi`'s `ex` mode).
The {env}`VISUAL variable is intended for modern "visual mode"
terminal editors (ex: `vi` or `emacs`).
Technically speaking editors that are assigned to {env}`EDITOR` should
be configured to operate in teletype compatible mode (see `vi -e` and
`vim -e`).
We don't do this currently because for most users this would be
unintuitive behavior when a script or program mistakenly checks
{env}`EDITOR` instead of first checking {env}`VISUAL`.
In the future it may be worthwhile to introduce an additional option to
these modules to configure {env}`EDITOR` in a strictly conforming manner
(i.e. using the teletype/`ex` mode flags or unsetting {env}`EDITOR`
entirely).
Related Issue: #8314
Signed-off-by: Jacob Abel <jacobabel@nullpo.dev>
If snixembed is enabled and you try to use the waybar tray the two tools
conflict with eachother and often waybar's tray will not show any icons.
This adds a warning about it, as the problem can be difficult to
diagnose.
With swayidle one can configure two different kinds of hooks:
- Idle timeouts are executed after the session has been idle for a
specific amount of time.
- Events are executed when systemd notifies us that for example the
user session is locked or that the device is about to suspend.
While not obvious, there is a significant difference between how these
two kinds are configured: there can be several timeouts with separate
commands to be executed, but each event can only be specified once. If
an event is specified multiple times, then the last command wins.
This can be very easy to miss in swayidle's documentation. Furthermore,
because the config is a list of `{ event = "..."; command = "..."; }`
attrset, we double down on this confusion and make it seem like having
multiple handlers for an event was actually supported.
Fix this by converting from a list of "event" submodules to an attrset
where the key is the event name and the value is the command to be
executed. This makes it impossible to specify multiple commands for a
single event by accident.
If a user _does_ want to have multiple commands executed on any event
they can for example use `pkgs.writeShellScript` and manually chain the
commands in that script.
