Re: [PATCH] profiles: Add 'hicolor' and 'HighContrast' icon theme hooks.

[宋文武]

Ludovic Courtès <address@hidden> writes:

> 宋文武 <address@hidden> skribis:
>
>> This is WIP.
>>> * guix/profiles.scm (gtk-icon-theme-hook): New function.
>>>   (%default-profile-hooks): Add `(gtk-icon-theme-hook "hicolor")' and
>>>   `(gtk-icon-theme-hook "HighContrast")'.
>
> Looks nice!
>
>>> +(define (gtk-icon-theme-hook name)
>>> +  "Return a profile hook that unions all NAME icons from manifest entries 
>>> and
>>> +rebuilds the 'icon-theme.cache' file for the NAME icon theme."
>>> +  (define gtk+
>>> +    (module-ref (resolve-interface '(gnu packages gtk)) 'gtk+))
>>> +
>>> +  (lambda (manifest)
>>> +    (define build
>>> +      #~(begin
>>> +          (use-modules (guix build utils)
>>> +                       (guix build union))
>>> +          (let* ((icon-dir (lambda (base)
>>> +                             (string-append base "/share/icons/" #$name)))
>>> +                 (destdir  (icon-dir #$output))
>>> +                 (icons    (filter
>>> +                            file-exists?
>>> +                            (map icon-dir '#$(manifest-inputs manifest))))
>>> +                 (update-icon-cache (string-append
>>> +                                     #+gtk+ "/bin/gtk-update-icon-cache")))
>>> +            ;; mkdir -p $out/share/icons
>>> +            (mkdir-p destdir)
>>> +            (rmdir destdir)
>>> +            ;; Unions all the icons and update the 'icon-theme.cache'.
>>> +            (union-build destdir icons)
>>> +            (system* update-icon-cache "-t" destdir))))
>>> +
>>> +    (gexp->derivation (string-append (string-downcase name) "-icon-theme")
>>> +                      build
>>> +                      #:modules '((guix build utils)
>>> +                                  (guix build union))
>>> +                      #:local-build? #t)))
>> When to exclude this derivation?
>>
>> 1. the best would be whether icon dir exists or not
>>    but is this posibble to implement? and how?
>
> Currently this is not possible.  The builder could depend on all the
> manifest entries and scan them for share/icons directory, but at this
> point it’s already too later because the build has to depend on GTK+.
Does it mean we can't scan them (manifest-inputs) out of the builder,
because they may haven't be realized?
>
>> 2. whether we have a gtk+ package in profile
>
> That’s no usually the case.  For instance, I have Evince and GIMP in my
> profile, but not GTK+.
>
> What could be done is to check whether GTK+ appears and an direct or
> indirect dependency of the packages being installed.
>
> Currently manifest entries can contain either a package object or a
> store path.  In the former case, one has to use package->bag and then
> look for GTK+ in the bag’s transitive inputs.  In the latter, case, one
> needs to call ‘references’ to check whether the store item, which is
> already built, depends on GTK+.
>
> When none of the manifest’s packages depends on GTK+, then the hook can
> just return #f, like ghc-package-cache-file does.
>
> Does that make sense?
OK, I'll try this way.

And, which GTK+ we should use to do the icon update?
How about choose the one referenced by manifest entries
(either gtk+-2 or gtk+-3) instead of the latest gtk+-3 deployed?

So, we can avoid downloading the new GTK+.
(IMO, this is useful for GHC too)
>
>>>  (define %default-profile-hooks
>>>    ;; This is the list of derivation-returning procedures that are called by
>>>    ;; default when making a non-empty profile.
>>>    (list info-dir-file
>>>          ghc-package-cache-file
>>> -        ca-certificate-bundle))
>>> +        ca-certificate-bundle
>>> +        (gtk-icon-theme-hook "hicolor")
>>> +        (gtk-icon-theme-hook "HighContrast")))
>> Does these 2 enough?  I think in practical, it does.
>> Or (better) as Federico Beffa said in:
>>
>>   http://lists.gnu.org/archive/html/guix-devel/2015-01/msg00108.html
>>
>> We should rebuilds all the icon themes?
>> If so, I think the code will be more complex...
>
> Let’s have an incremental approach and start with the simple yet helpful
> approach that you propose.  We can improve later.
>
> Thoughts?
Sure, thanks your review!
>
> Thanks,
> Ludo’.