Subject: Re: [bug#77352] [PATCH] home: services: define hyprland home service

From: Andrew Wong <[email-masked]>
Date: Sat, 29 Mar 2025 11:37:36 -0400

Very cool patch! Would it be possible to add functionality for loading 
plugins on startup? I have a pending patch series[1] that packages 
several Hyprland plugins, and it would be nice to be able to enter a 
list of plugin packages to be loaded directly in the config so they 
could be "dependencies" of the service.

Also, how does this cooperate with session managers like the default 
GDM, which launches wayland from its .desktop entry in 
/run/current-system/profile/share/wayland-sessions[2]? If it only 
generates a configuration (i.e. doesn't start the Hyprland process), 
would it be possible to define services that start and run only while 
Hyprland runs? (this would be distinct from what "exec" lines do in that 
the packages are then pulled into the profile by the service, letting 
Guix "understand" the dependency)

The default settings should be the same as Hyprland's auto-generated 
config[3], unless there's some guix-specific requirement. This is 
because users will want to be able to easily transfer the config they 
already use, and to be able to use the documentation and advice that 
already exists that assumes new users have the autogenerated config. 
Users should not have to do extra configuration to get a consistent 
default experience.

To name a few issues, having `extra-config` defined by default would 
require users to go out of their way to use what would otherwise be a 
"last-resort" feature in order to get the default experience. Also, I 
know from experience that settings vrr to anything but 0 can cause some 
monitors to go black unless the vrr matches their (fixed) refresh rate; 
vrr is not a universal feature, the ability for the computer to control 
the monitor's vrr setting even less so.

Perhaps the service could straight-up copy or parse-in the file (which 
would make transitioning from a "traditional" config file easy, too!) 
from the Hyprland package itself to reduce the need for Guix to maintain 
it every time it changes. Off the top of my head, the cheapest solution 
to the problem would be to hardcode the default config's checksum, and 
print an alert asking for maintenance when it changes.

Finally, you should check over your patch with regards to Guix' coding 
style conventions[4]. Most conspicuously, lines should be 80 characters 
wide at maximum. Also, when updating a patch, you should send a v2 
instead of creating a new bug number.

Your patch shows a lot of promise, and it's great to see someone get the 
ball rolling on something I've only been daydreaming about for a while 
now. If you'd like help on any specific part, LMK!

- Andrew Wong

[1] bug#76910
[2] 
https://guix.gnu.org/manual/devel/en/html_node/X-Window.html#index-gdm_002dservice_002dtype
[3] less $(guix build hyprland)/share/hypr/hyprland.conf
[4] https://guix.gnu.org/manual/en/html_node/Formatting-Code.html