[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] profiles: Add 'hicolor' and 'HighContrast' icon theme hooks.
From: |
宋文武 |
Subject: |
Re: [PATCH] profiles: Add 'hicolor' and 'HighContrast' icon theme hooks. |
Date: |
Sun, 10 May 2015 12:55:27 +0800 |
User-agent: |
Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-unknown-linux-gnu) |
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’.