unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: L  p R n  d n <guix@lprndn.info>
Cc: 35305@debbugs.gnu.org
Subject: [bug#35305] LightDM service
Date: Wed, 20 May 2020 22:51:21 +0200	[thread overview]
Message-ID: <87k116e3ee.fsf@elephly.net> (raw)
In-Reply-To: <87o8qtzd71.fsf@lprndn.info>

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	other threads:[~2020-05-20 20:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-17 14:24 [bug#35305] [WIP] LightDM service L p R n d n
2019-04-18 11:20 ` Jonathan Brielmaier
2019-05-23 11:04 ` [bug#35305] [PATCH] " L p R n d n
     [not found] ` <handler.35305.B.155550391014002.ack@debbugs.gnu.org>
2019-04-18 13:20   ` [bug#35305] Acknowledgement ([WIP] LightDM service) L p R n d n
2019-04-18 16:03     ` L p R n d n
2019-08-26 15:58   ` L p R n d n
2020-03-15 21:50     ` Nicolò Balzarotti
2020-03-16  7:34       ` Efraim Flashner
2020-03-16  8:36         ` L p R n d n
2020-03-19 11:54       ` [bug#35305] LightDM service L p R n d n
2020-04-07 17:06 ` Brice Waegeneire
2020-04-09 16:02   ` L p R n d n
2020-04-12  9:53     ` Brice Waegeneire
2020-04-14  9:38       ` L p R n d n
2020-04-14 13:17         ` L p R n d n
2020-04-22 15:26       ` L p R n d n
2020-05-06 14:05 ` L p R n d n
2020-05-08 22:18   ` Ricardo Wurmus
2020-05-09 15:09     ` L p R n d n
2020-05-10 19:21       ` Ricardo Wurmus
2020-05-11 10:14         ` L p R n d n
2020-05-12  9:59         ` L p R n d n
2020-05-20 20:51           ` Ricardo Wurmus [this message]
2020-05-21  8:28             ` L p R n d n
2020-05-21  9:23               ` Ricardo Wurmus
2020-06-08 15:35                 ` L p R n d n
2022-08-04  5:09                   ` [bug#35305] [WIP] " Maxim Cournoyer
2020-06-19 14:47                 ` [bug#35305] " L p R n d n
2022-08-04  2:19   ` [bug#35305] [WIP] " Maxim Cournoyer
2022-08-31  7:13 ` bug#35305: " Ricardo Wurmus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k116e3ee.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=35305@debbugs.gnu.org \
    --cc=guix@lprndn.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).