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

[Taiju HIGASHI <higashi@taiju.info>]

Ludovic Courtès <ludo@gnu.org> writes:

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

Thank you. I understand well.
I felt out of place because there was no service that can full
configuration such this one.

> 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 found out what essential services should be.
I'm going to move it from essential services to base-home-services.

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

Yes. I can write the draft, but I may have to ask you to finish it because
I'm not good at writing English.
It would be a waste of time for you to spend a long time correcting my
poor grammar and expressions.

Thanks,
-- 
Taiju