[bug#72714] [PATCH v4] home: services: Add 'home-sway-service-type'.

[pelzflorian (Florian Pelz)]

Hello Arnaud.

Arnaud Daby-Seesaram <ds-ac@nanein.fr> writes:
> I will probably define a new variable `%sway-default-packages'
> containing the above packages (minus waybar, ...).  WDYT?

Yes, good idea.

Though some of these commands like dbus and xdg portals are unnecessary
because noone will run them manually from within sway.

Also note that the menu should default to wmenu instead of dmenu
according to swaywm.org release notes for current sway 1.9.  Both are in
$(guix build sway)/etc/sway/config, but dmenu got used, but probably for
compatibility only.

wmenu should be the only menu.

Do we have an API stability guarantee that `%sway-default-packages' will
remain the same?  I guess we better try not to remove packages from it
in the future but get it right from the start.


> I will add a note in the next version of the doc, to hint towards the
> two solutions to use a svg file: adding librsvg to the profile, or
> computing the png and put it in the store using a "computed-file" in the
> configuration (as in the second version of the patch).

Do we need a computed-file example?  Sway’s default background
$(guix build sway)/share/backgrounds/sway/Sway_Wallpaper_Blue_1920x1080.png
is a .png file already.  We need not use guix-backgrounds.  Rationale:

In the computed-file version, note that librsvg needs rust and rust does
not build on i686-linux nor armhf.  I tested in an i686-linux VM and the
rest of your home-sway-service-type works great there (using elogind and
manually running sway, because greetd would need rust).  Using
imagemagick’s convert just gives a bogus pure black .png file.

I still have not found the time to look at `sway-bar' and `point' and
`sway-color' and such details.

Regards,
Florian