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

[Arnaud Daby-Seesaram]

Hello Florian,

> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
>> I’m still looking at the details of sway, so I could myself push your
>> patch with confidence to guix.git, but would also be happy if others
>> pushed it
> Nice, NB: it is also fine

I meant: it is also fine if you prefer to wait a few weeks for someone
else with commit access to comment/push this patch (as I do not want to
put pressure on you, and you said that you preferred not to take
responsibility for sway in a previous email).


"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
> I still have not found the time to look at `sway-bar' and `point' and
> `sway-color' and such details.
As I have changed these configuration records and the serialisation
function (hopefully making it easier to read and modify) in the v6, I
will send it today.  I will not address your comments from today, but
should contain improvements over the previous code.


"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
> 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.

Yes, indeed.  This week, I will test sway with only (list sway) and
(list sway swaybg) to see what works and what fails in each case.  Then,
I will try to minimise the list of v5 (as users can always provide their
own lists if they want more packages to be available).

> 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.

Noted.  I used an outdated default sway configuration when defining
default variables, my bad.
This will not be modified in the v6 (as I send it right away), but
should be done later; I have added a comment in the code to remind me of
that.

> 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.

Indeed, this would be better.  As mentioned above, I will try to
minimise this list and only keep packages that are necessary for using
sway.  I will try to report on that within the week.


>> 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?  [...]  Rationale: [...]

Thank you for this thorough testing and associated explanation.

I agree with you and have removed this example from the documentation
(only leaving the note that librsvg is needed in the profile in order to
use svg files).


Best,

-- 
Arnaud

signature.asc
Description: PGP signature