From: Thorsten Wilms <t_w_@freenet.de>
To: guix-devel@gnu.org
Subject: Re: Updates on the guix home manager
Date: Fri, 20 Sep 2019 11:31:15 +0200 [thread overview]
Message-ID: <20190920113115.7256a0515033145f55cc32ae@freenet.de> (raw)
In-Reply-To: <20190919232257.671511bb@sybil.lepiller.eu>
On Thu, 19 Sep 2019 23:22:57 +0200
Julien Lepiller <julien@lepiller.eu> wrote:
> I you have a color-theme-home-type that extends all terminals, color
> themes would be configured in all terminals, but because of the
> extension, a mate-terminal-home-type would be instantiated.
>
> My version of services introduce the notion of an extension point: all
> three terminal services would implement a color-theme extension point
> that could be targeted by another service. When it targets an
> extension point, a service does not need to specify what service is
> extended. In that case, no service is implicitely instantiated, and
> any service with that extension point is extended. This is exactly
> what we want to do here: by using the extension point, without
> specifying a target service, both gnome and xfce4 terminal
> configurations are updated with your color theme, and
> mate-terminal-home-type is not instantiated.
OK, let me try to put that in different terms:
An application-configuration may contain placeholders. A
generalized-configuration may declare that it fills in a specific
placeholder. This happens automatically, if the
generalized-configuration is used, while any
application-configuration with such a placeholder is also in use.
So basically like having an inherits-from, but with one level of
abstraction that allows to swap in the thing to inherit from?
So far, in my own practice, what I have been missing is a way to manage
defaults and customizations. I'd like to keep track of it, in terms of
"these are the defaults the application has been installed with",
"these are the changes I applied". Then, when an update of the
application does anything to the defaults, I want to be able to get to
a diff and the option to apply my changes as a patch, or see where
conflicts are.
Adding a mechanism to generalize settings, I can only imagine a graph,
consisting of generalized-settings-producers, translators, patches and
combiners. Actually, generalized-settings-producers could be patches
(from nothing to something).
--
Thorsten Wilms <t_w_@freenet.de>
next prev parent reply other threads:[~2019-09-20 9:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 21:22 Updates on the guix home manager Julien Lepiller
2019-09-20 9:31 ` Thorsten Wilms [this message]
2019-09-20 14:39 ` Julien Lepiller
2019-09-20 11:50 ` Maxim Cournoyer
2019-09-24 7:56 ` Ludovic Courtès
2019-09-25 9:41 ` Konrad Hinsen
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=20190920113115.7256a0515033145f55cc32ae@freenet.de \
--to=t_w_@freenet.de \
--cc=guix-devel@gnu.org \
/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).