On 6 September 2017 at 09:24, Björn 'besser82' Esser
<besser82@xxxxxxxxxxxxxxxxx> wrote:
[..]
> That is NOT true for gtk-update-icon-cache. There is currently no trigger
> for it, at least when I look at the recent information on the wiki [1].
OK. Just started working on add this (I see a lot other things which
can be improved in gtk3.spec).
> Setting automatic triggers for this might be tricky, since we simply have
> more icon sets as just hicolor; there are plenty of others among just that
> one. For that reason the automatic triggers would need to iterate over all
> direct subdirs in %{_datadir}/icons and run the update for all of them,
> like:
>
> ```
> for _dir in $(find /usr/share/icons -mindepth 1 -maxdepth 1 -type d) ; do
> /bin/touch --no-create $_dir &>/dev/null || :
> /usr/bin/gtk-update-icon-cache $_dir &>/dev/null || :
> done
> ```
>
> to make sure all possibly changed icon sets are covered.
>
> For that reason, I think, there are still no automatic triggers for the icon
> cache.
Correct any of my below thinking if anything is wrong.
1) It is not possible to use only icon theme without actual switching
to other theme.
2) If it is correct updating theme icons cache should be placed in
main package installing theme.
3) As long as hicolor theme is default theme updating its cache can
still be in gtk-update-icon-cache package.
What happens with other directories than /usr/share/icons/hicolor is
in this case secondary and can be treated as an exception.
Running above script will make updates oft the hicolor theme
potentially longer and only occasionally it will be possible to save
some time.
if yes let's allow update other themes caches to packages installing
those themes).
If above is kind of wrong you script is correct.
BTW. Looks like now when "Settings" application has been changes to
much less readable list view looks like change theme gone and now it
is not possible to switch to other theme without installing some
extensions :/
In this situation number of people experiencing any issues with
incorrect icons caches has been "dramatically reduced" ;-)
And yet anther "small" issue:
$ rpm -qf /usr/share/icons/*
adwaita-cursor-theme-3.25.91-1.fc28.noarch
adwaita-icon-theme-3.25.91-1.fc28.noarch
fedora-logos-26.0.1-3.fc27.x86_64
libXcursor-1.1.14-10.fc27.x86_64
gnome-icon-theme-3.12.0-7.fc27.noarch
fedora-logos-26.0.1-3.fc27.x86_64
gnome-themes-standard-3.22.3-4.fc27.x86_64
file /usr/share/icons/locolor is not owned by any package
fedora-logos-26.0.1-3.fc27.x86_64
Hmm why libXcursor has its own settings witin icons themes directories?
defailt points to Inherits=Adwaita but I don't see how with this
hicolor is linked?
Is this all correct?
On first looks what is currently is a bit messy (?)
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
