Sometimes services can fail. Failed services will generally not be
restarted by systemd. To start previously failed services we can
just reset their failed state before starting our session target.
GNOME and Plasma do the same thing.
See: https://github.com/alebastr/sway-systemd/pull/11
Helps avoid successful build but Sway failing to start.
To meaningfully test this, I had to actually use `pkgs.sway` in the
test rather than the stub, but left all other tests using the stub and
changed them to skipping the test.
We need to pass `--unsupported-gpu` as Sway checks for `nvidia` in
`/proc/modules`, and the Nix sandbox has `/proc/modules` available.
The `exec` command does not do any shell parsing and does not
understand the `&&` which is how the extraCommands are added after
dbus activation. There doesn't seem to be a reason for `exec` here
anyway so just remove it and allow shell parsing.
workspace 10 is part of upstream's default config, but was missing in home-manager.
The initial "sway: add module" PR (02d6040003) went through multiple iterations and had workspace 10 included for a brief moment.
Until the author removed it in a force-push commenting
> Have removed the last change which added bound ${modifer}+0 to workspace number 10 as this messed up workspace numbering in sway.
The reason might have been, that sway used to sort the workspaces in the order they appeared in the config.
Attribute sets in nix are sorted, but not "naturally sorted", meaning `bindsym Mod1+0 workspace number 10` comes before `bindsym Mod1+0 workspace number 1`.
It's unclear if that's what really happened. A workaround would have been to use `lib.lists.naturalSort` in `keybindingsStr`.
But I cannot reproduce this anymore in any way.
I assume this has been fixed many years ago by now.
upstream config: 020a572ed6/config.in (L113-L134)
The previous syntax (`plugin:name { ...settings}`) is not working with
more than one plugin. There is no documentation for this, just the
source code [1].
With this update the plugins paths aren't generated together with the
full config (so the "plugin" field is not "important" anymore) and the
plugins settings are generated like the other fields.
[1] 4d403dac32/src/config/ConfigManager.cpp (L1574)
The plugin setting in the Hyprland config is used both for defining
plugin paths and configuring the plugins. This fix removes the
silent override of the plugins settings converting them to the
`plugin:<name> { ...settings }` syntax.
DBus activated services such as mako use the XCURSOR_THEME and
XCURSOR_SIZE environment variables to decide how to show the cursor,
so without these, the cursor may not match the rest of the desktop
when hovering over (in this example) mako notification surfaces.
Add the option sourceFirst to the hyprland module. When this option is
enabled source entries will be put near the top of the file, so that
the variables declared in other files can be used by the other
configuration entries.
Add "source" to the list of important prefixes when the former option
is enabled.
Resolves#4729
Allows users to customize which environment variables to import in DBus
and SystemD user environments, and to specify which commands will be run
after the environment activation.
Fixesnix-community/home-manager#4488
The default config for sway generates a bar block with tray_output primary. But wayland (or sway, take your pick?) has no concept of a primary display so this just results in no tray anywhere.
A better default is "*" which puts the tray on every monitor, since sway can do so without issue.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
* hyprland: prioritize variables and beziers
The `settings` key now handles `$variables` and `bezier`s differently,
putting them at the top of the file.
Also, proper indentation has been implemented.
* Update modules/services/window-managers/hyprland.nix
Co-authored-by: Naïm Favier <n@monade.li>
* hyprland: add animations & beziers test
---------
Co-authored-by: Naïm Favier <n@monade.li>
* sway: add support for XDG autostart using systemd
Using the option wayland.windowManager.sway.systemd.xdgAutostart, users
can now choose to start applications present in
$XDG_CONFIG_HOME/autostart when starting their sway session.
This change also renames wayland.windowManager.sway.systemdIntegration
to wayland.windowManager.sway.systemd.enable;
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
* sway: add Scrumplex to maintainers
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
---------
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
Without this, even if you configure a preference for Electron apps to
use Ozone by setting `NIXOS_OZONE_WL=1`, GUI apps launched through
systemd user services use XWayland, since the variable is not set in
their environment.
This fixes that issue by importing it, like we do other variables.
The previous implementation tried to rename the tag named "default" to
the first tag in `cfg.tags`. This was a wrong approach because if a
tag with the same name already existed, the renaming failed and the
default tag would continue to exist.
The looking up of the default tag also contained a bug because it
should have used `by-name` in the path.
The default value for `xsession.windowManager.herbstluftwm.tags` is an
empty list, but the config file uses `builtins.head` on it, which causes
an error upon evaluation. With this change the tags configuration is
skipped if the list is empty.
- The `XDG_SESSION_TYPE` environment variable is used by some applications and frameworks to
detect wayland sessions (i.e qt5/6, electron/chromium). It is set by wlroots since version 0.13.0 [1].
- Propagating `XDG_SESSION_TYPE` to the systemd user environment is necessary when processes launched by
services (e.g emacs) need to inherit the environment variable.
[1] - 90c8452959
If set to true, desktops configured in `monitors` will be reset every time
the config is run.
If set to false, desktops will only be configured the first time the config is run.
This is useful if you want to dynamically add desktops and you don't want them
to be destroyed if you re-run `bspwmrc`.
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.
This option provides a more convenient way to overlay dummy packages.
It also adds a function `config.lib.test.mkStubPackage` that can,
e.g., be used for `package` options.
