guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#35305] LightDM service


From: Ricardo Wurmus
Subject: [bug#35305] LightDM service
Date: Wed, 20 May 2020 22:51:21 +0200
User-agent: mu4e 1.4.4; emacs 26.3

Hey,

I’m very sorry for the delay.

What took me so long is that I’m conflicted about how to move forward.
On one hand I really don’t want to delay this.  I think your patches are
a great and important addition to Guix.  On the other hand I feel that
the relationship between these new components isn’t quite right.

It still doesn’t feel quite right to me that there’s a
lightdm-service-type and an independent
lightdm-gtk-greeter-service-type.  I know that there can be any number
of greeters, but only one will be used with lightdm-service-type
dependent on the string value of greeter-session.  This leads to
potential misconfiguration as we don’t (and can’t) validate this string.

It also feels wrong to me to have a global directory as the only
location for greeter desktop files, which means that all greeters must
be installed globally.

What I envision is something like this: we only have a single
lightdm-service-type and it has a field “greeters”, which by default is
a list of just one item: a <greeter> record containing the
lightdm-gtk-greeter and its configuration.

Other greeters could be added; they would all be record values of type
<greeter> and come with their own extensions of the
ligthdm-service-type.

The lightdm-service-type would go through each of the greeters in the
list and apply their specified extensions to itself.

The reason why I haven’t implemented this yet is because a) I don’t want
to break what already works with your patches and b) I don’t know if
that’s ultimately a clearer implementation.

I feel that this would be a more intuitive configuration and result in
clearer relationships between the display manager and its swappable
components.  It would also allow for better defaults (so less
configuration needed) and avoid the problem of stringy types that are
easy to get wrong.

Maybe we are already really close to this solution, though: maybe the
proposed “greeter” field could simply accept service types like the
lightdm-gtk-greeter-service-type you already defined.

I’m going to play with this a little bit more, but if this doesn’t lead
anywhere I’ll merge the current version.

My apologies for delaying this!

-- 
Ricardo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]