stylix: allow choosing testbed desktop

[mateusauler]

This adds stylix.testbed.ui.desktop which allows the testbed to pick what desktop environment/window manager will be ran inside the VM.

This PR is currently a PoC and I'm open to any suggestions. I'm actively working on it, so everything is subject to change.

Relevant: #1192 (comment)

Things done

• Tested locally
• Tested in testbed
• Commit message follows commit convention
• Fits style guide
• Respects license of any existing code used

Notify maintainers

@danth @trueNAHO @awwpotato @Flameopathic

Who else?

[danth]

This seems a bit overkill IMO. The standard configuration was meant as a default for when the target is an application rather than a DE/WM itself - with the plan that GNOME would eventually be replaced with something more minimal like cage. If testbeds are targeting a DE/WM, or an application which requires something more specific then they should include their own configuration from scratch.

By adding options like this, we risk duplicating a lot of the services.xserver.* options from NixOS as essentially aliases which just enable a couple of things.

[0xda157]

something more minimal like cage

imo cage is too minimal because it doesn't interact well with popups iirc. perhaps we use a minimal wm like river.

[mateusauler]

The reasoning is that:

a) Some applications might be desktop specific, like gnome-text-editor for example. So if we support multiple applications for the same desktop, we end up with a lot of duplicate code and potentially inconsistent setups. If a module needs a more specific setup on top of the desktop, it can handle that.

b) In the case of mako (#1192), for example, I had to replicate basically all of Hyprland's testbed code.
Some other modules we already support that could have this problem are: dunst, hyprlock, hyprpaper, rofi, swaylock, waybar, wpaperd, xresources.

We could limit our selection to a couple desktops for their specific properties (Eg. X11/Wayland, doesn't include a bar, doesn't handle notifications). Right now, I added all desktops we have testbeds for.

[Flameopathic]

When adding testbeds, I was running into the issue of needing different WMs to test different targets. I think this would be a great addition; thank you!

[trueNAHO]

This seems a bit overkill IMO. The standard configuration was meant as a default for when the target is an application rather than a DE/WM itself - with the plan that GNOME would eventually be replaced with something more minimal like cage.

Yes, migrating to the minimal functioning graphical environment would be the ideal solution.

If testbeds are targeting a DE/WM, or an application which requires something more specific then they should include their own configuration from scratch.

I agree that providing interfaces to several graphical environments is arguably overkill. The main benefit of this abstraction is the reduction of the very occasional code duplication:

a) Some applications might be desktop specific, like gnome-text-editor for example. So if we support multiple applications for the same desktop, we end up with a lot of duplicate code and potentially inconsistent setups. If a module needs a more specific setup on top of the desktop, it can handle that.

By adding options like this, we risk duplicating a lot of the services.xserver.* options from NixOS as essentially aliases which just enable a couple of things.

Yes, but providing a graphical environment interface increases the consistency for the same graphical environment across testbeds:

b) In the case of mako (#1192), for example, I had to replicate basically all of Hyprland's testbed code.

Despite this abstraction being arguably overkill, it allows testbeds to target X11 and Wayland individually. However, does XWayland nowadays not cover all our X11 use cases:

We could limit our selection to a couple desktops for their specific properties (Eg. X11/Wayland, doesn't include a bar, doesn't handle notifications).

This solves the problem generally by interfacing all our supported graphical environments:

Right now, I added all desktops we have testbeds for.

However, I agree with danth's stance of this abstraction being overkill. The best solution would be to replace GNOME with something like cage and make everything work there.

Instead of #1192 changing the entire graphical environment, it would be better if it would somehow be able to replace GNOME's notification daemon:

https://github.com/danth/stylix/blob/b66b220fb02cd0713eb93d82dcf36962d04b0d86/modules/mako/testbeds/default.nix#L4

Regardless of this PR being merged, the change in /modules/bspwm/testbeds/default.nix of replacing xsession.windowManager.bspwm.startupPrograms with stylix.testbed.ui.command.text is probably good to keep since it uses our consistent stylix.testbed.ui interface.

[nukdokplex]

+1 wayprompt doesn't work in gnome environment for some reason, i tested it on sway and hyprland, works great on those wms

[panchoh]

+1 wayprompt doesn't work in gnome environment for some reason, i tested it on sway and hyprland, works great on those wms

Ah, the reason is that Wayprompt requires the compositor to support the layer shell protocol, and GNOME doesn’t.

[Flameopathic]

Ah, the reason is that Wayprompt requires the compositor to support the layer shell protocol, and GNOME doesn’t.

That must be the same reason notification daemons won't work on it

[trueNAHO]

However, I agree with danth's stance of this abstraction being overkill. The best solution would be to replace GNOME with something like cage and make everything work there.

Instead of #1192 changing the entire graphical environment, it would be better if it would somehow be able to replace GNOME's notification daemon:

https://github.com/danth/stylix/blob/b66b220fb02cd0713eb93d82dcf36962d04b0d86/modules/mako/testbeds/default.nix#L4

I forgot to mention that I am fine with merging this PR for practical reasons, especially since using cage in our testbeds has been a long standing task that may involve nasty bugs and take longer than expected. In the meantime, more desktops can be supported, simplifying future incremental migrations to cage.

Also, it might be better to to refer to DEs and WMs as "graphical environment" instead of just "desktop".

+1 wayprompt doesn't work in gnome environment for some reason, i tested it on sway and hyprland, works great on those wms

Ah, the reason is that Wayprompt requires the compositor to support the layer shell protocol, and GNOME doesn’t.

Thanks for looking into this.

[mateusauler]

I'm currently unhappy with:

• Each graphical environment module has to check if it should be enabled. (See stylix: allow choosing testbed desktop #1222 (comment))
• The code for autostarting applications in WMs that don't support it is duplicated (See hyprland and bspwm)
• The choice of available environments is somewhat arbitrary (they're the environments we have testbeds for). I think (Gnome ^ Plasma6) & (Hyprland ^ Bspwm) should be enough. Maybe cage as well.

Despite that, I believe this PR is ready for a proper review. So, I'm marking this as ready.

[trueNAHO]

LGTM, except for very minor things.

[0xda157]

LGTM aside from nit + naho's comments

[stylix-automation]

Backport failed for release-25.05, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-25.05
git worktree add -d .worktree/backport-1222-to-release-25.05 origin/release-25.05
cd .worktree/backport-1222-to-release-25.05
git switch --create backport-1222-to-release-25.05
git cherry-pick -x 8c854fe383fda20e8befefc31ecf248988a40bcc