Re: symbolic icon fallback failure

[Patrick Welche <prlw1 cam ac uk>]

On Thu, Nov 21, 2013 at 10:07:55AM -0500, Jasper St. Pierre wrote:
> On Thu, Nov 21, 2013 at 9:38 AM, Patrick Welche <prlw1 cam ac uk> wrote:
>
> > Originally I thought that the lack of icons on my system in the post
> > stock-icons age was because symbolic icons are SVGs:
> >
> >   https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html
> >
> > (The request for documentation still stands.)
> >
> > It seems that the problem is somewhat different:
> >
> > 1) scalable gnome icons (e.g. symbolic svg icons) are not searched for.
> > 2) the claim "If a -symbolic icon is missing, the app will fall back to the
> >    regular name." seems to be false.
> >
> > In reverse order, 2) looked as though it should be fixed by commit d25ee710
> >   https://bugzilla.gnome.org/show_bug.cgi?id=708163
> > which was did appear in 3.10.2 despite the last comment in that bug.
> > It seems that fallback is still broken.
> >
> > 1) seems odd: when running e.g. evince --gtk-debug=icontheme (3.10.3), a
> > gtk 3.10.3 system with gnome-icon-theme-symbolic 3.8.3, and gsetting:
> >    org.gnome.desktop.interface icon-theme 'gnome'
> > shows caches found in icons/hicolor and icons/gnome
> >
> > (gtk-update-icon-cache --validate returns 0 for those two directories
> >  so validates OK.
> >  Is there an easy way of dumping the contents of the cache?)
> >
> > Evince then looks for dialog-password in
> >
> > "" <-? builtins?
> > icons/hicolor/..x..      (why hicolor when gsettings says
> > icon-theme=gnome?)
> > evince/icons/..x..
> > icons/hicolor/scalable
> > evince/icon/scalable
> > theme_lookup_icon found dialog-password in dir (null)
> > ? builtin - it apparently didn't look in icons/gnome/..x.. which is where
> > the
> >             PNGs live.
> >
> > Next is go-up-symbolic, which won't be found, and which lives in
> > icons/gnome/scalable/actions
> >
> > It is looked for in
> > ""
> > icons/hicolor/..x..
> > evince/icons/..x..
> > icons/hicolor/scalable
> > evince/icon/scalable
> > (as before, and in addition)
> > icons/hicolor/..x..  (again, interleaved with icons/gnome)
> > icons/gnome/..x..    (because of commit 90dee25e in 3.10.3?)
> > ""
> > icons/hicolor/..x..  (again, with evince/icons/hicolor)
> > gtk_icon_theme_lookup_icon image-missing
> >
> > so icons/gnome/scalable is not searched, and fallback non-symbolic
> > "go-up" is also not searched for.
>
> hicolor is specified as a fallback icon theme in the icon theme
> specification, so that apps can place their app icons there.


I don't understand your comment. evince isn't providing "go-up-symbolic".
It is trying to use it.

icons/gnome/16x16/actions/go-up.png
icons/gnome/22x22/actions/go-up.png
icons/gnome/24x24/actions/go-up.png
icons/gnome/32x32/actions/go-up.png
icons/gnome/48x48/actions/go-up.png
icons/gnome/scalable/actions/go-up-symbolic.svg

live on the system. go-up-symbolic.svg isn't found as for some reason
icons/gnome/scalable isn't searched. non-symbolic fallback "go-up.png"
isn't searched for. Is that clearer?

> > BTW gtkicontheme.c:1658 choose_icon() seems odd: the first block
> > checks for a -symbolic suffix, but appears to do the same as the
> > second block. Was that intentional?
>
> Look closer. In the case of symbolic, it searches all themes for
> icon_names[0] (which is foo-bar-baz-symbolic). In the latter, it tries all
> the icon names (foo-bar-baz-symbolic, foo-bar-baz, foo-bar, foo) for every
> theme in order.

Hmmm - so why isn't at least go-up found?

Cheers,

Patrick