[bug#57963] [PATCH 0/1] Support user's fontconfig.

[Ludovic Courtès]

Hi,

Taiju HIGASHI <higashi@taiju.info> skribis:

> I just sent you the v3 patch.
>
> I have changed only the interface of `preferred-defalut-font` slightly
> from what I suggested the other day.
>
> We configure the service as follows.
>
>   (simple-service
>     'my-fontconfig-service
>     home-fontconfig-service-type
>     (home-fontconfig-configuration
>      (font-directories
>       (list "~/fonts"))
>      (preferred-default-font
>       (default-font
>         (serif "Noto Serif CJK JP")
>         (sans-serif "Noto Sans CJK JP")
>         (monospace "PlemolJP Console")))
>      (extra-config
>       `((match (@ (target font))
>           (edit (@ (mode assign)
>                    (name antialias))
>                 (bool true)))))))

Looks nicer IMO!

>> +(define (home-fontconfig-extend original-config extend-configs)
>> +  (home-fontconfig-configuration
>> +   (inherit original-config)
>> +   (font-directories
>> +    (append
>> +        (home-fontconfig-configuration-font-directories original-config)
>> +        (append-map home-fontconfig-configuration-font-directories 
>> extend-configs)))
>> +   (preferred-default-font
>> +    (home-fontconfig-configuration-preferred-default-font
>> +     (if (null? extend-configs)
>> +         original-config
>> +         (last extend-configs))))
>
> This is the part I am most concerned about, not sure if replacing the
> preferred-default-font setting with the last setting is the proper way
> to go about it.

It’s unusual for a service to receive extensions that are the full
configuration object of that service.  Because then, indeed, you have to
determine how to “merge” those configuration objects.

The common patterns that we have are:

  1. The service accepts as extensions things that represent part of its
     configuration and where merging makes sense.

     For example, nginx can be extended with
     <nginx-location-configuration> objects, but not with a full-blown
     <nginx-configuration>.

  2. Similar, but the service has specific records for extensions.

     The example that comes to mind is ‘home-bash-service-type’, which
     accepts <home-bash-extension> records as its extensions.

So…

I wonder, should we, as a first commit, move
‘home-fontconfig-service-type’ out of the essential services to a
‘%base-home-services’ variable yet to be defined?

I don’t see any good reason to have it here (“essential” services should
be limited to those that may not be replaced or removed; in (gnu
system), this includes services that depend on information available in
<operating-system>).

Once we’ve done that, perhaps we can forget about extensions, at least
for now, and let users who need to configure things write:

  (modify-services %base-home-services
    (home-fontconfig-service-type
     config => …))

WDYT?

> I wanted to write a test as well, but since it was to be handled by
> gexp, I could not figure out how to write a test that would validate the
> gexp result using only exported methods. (I would like to write tests
> for serialized functions that are private functions.)

Hmm.

Once we’ve settled on an interface, the commit that makes this change
should include an update of doc/guix.texi.

Thanks!

Ludo’.