Re: symbolic icon fallback failure
On Sun, Nov 24, 2013 at 08:31:21PM -0500, Morten Welinder wrote: rsvg-base.c:2194:5: error: implicit declaration of function 'canonicalize_file_name' This patch (used for Win32, but there isn't anything win32 specific in there) with minimal editing should get you going. https://git.gnome.org/browse/gnumeric/tree/tools/win32/patches/librsvg-portability.patch Actually - what's wrong with posix realpath() ? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote: On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche pr...@cam.ac.uk wrote: On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found) That was what I was worried about in: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html I have libpixbufloader-svg.so and an svg entry in loaders.cache. Given that there were no replies, I assume that that is the complete checklist. Your librsvg may be too old to render symbolic icons. See BTW - if my librsvg is too old, any thoughts on why the non-symbolic png icon is not found? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote: On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche pr...@cam.ac.uk wrote: On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found) That was what I was worried about in: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html I have libpixbufloader-svg.so and an svg entry in loaders.cache. Given that there were no replies, I assume that that is the complete checklist. Your librsvg may be too old to render symbolic icons. See https://git.gnome.org/browse/librsvg/commit/?id=b864307868d3977dfa5e127ff95d7efded854850 and the bug referenced there. I have now tried with librsvg 2.40.1, and evince still doesn't find its icons. I managed to build librsvg with the attached patch. Cheers, Patrick --- rsvg-base.c.orig2013-05-11 09:19:07.0 + +++ rsvg-base.c @@ -2190,8 +2190,7 @@ _rsvg_handle_allow_load (RsvgHandle *han dir = g_file_get_path (base); g_object_unref (base); -/* FIXME portability */ -cdir = canonicalize_file_name (dir); +cdir = realpath (dir, NULL); g_free (dir); if (cdir == NULL) goto deny; @@ -2200,8 +2199,7 @@ _rsvg_handle_allow_load (RsvgHandle *han if (path == NULL) goto deny; -/* FIXME portability */ -cpath = canonicalize_file_name (path); +cpath = realpath (path, NULL); g_free (path); if (cpath == NULL) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
Actually - what's wrong with posix realpath() ? In my case, not available. And if the aim is portability, see BUGS in the man page. M. On Mon, Nov 25, 2013 at 3:54 AM, Patrick Welche pr...@cam.ac.uk wrote: On Sun, Nov 24, 2013 at 08:31:21PM -0500, Morten Welinder wrote: rsvg-base.c:2194:5: error: implicit declaration of function 'canonicalize_file_name' This patch (used for Win32, but there isn't anything win32 specific in there) with minimal editing should get you going. https://git.gnome.org/browse/gnumeric/tree/tools/win32/patches/librsvg-portability.patch Actually - what's wrong with posix realpath() ? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote: On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche pr...@cam.ac.uk wrote: On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found) That was what I was worried about in: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html I have libpixbufloader-svg.so and an svg entry in loaders.cache. Given that there were no replies, I assume that that is the complete checklist. Your librsvg may be too old to render symbolic icons. See https://git.gnome.org/browse/librsvg/commit/?id=b864307868d3977dfa5e127ff95d7efded854850 and the bug referenced there. Indeed: I am using librsvg 2.36.4 as per the referenced email. I just had a go at building 2.40.1, but: rsvg-base.c:2194:5: error: implicit declaration of function 'canonicalize_file_name' ? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
rsvg-base.c:2194:5: error: implicit declaration of function 'canonicalize_file_name' This patch (used for Win32, but there isn't anything win32 specific in there) with minimal editing should get you going. https://git.gnome.org/browse/gnumeric/tree/tools/win32/patches/librsvg-portability.patch On Sun, Nov 24, 2013 at 8:04 PM, Patrick Welche pr...@cam.ac.uk wrote: On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote: On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche pr...@cam.ac.uk wrote: On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found) That was what I was worried about in: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html I have libpixbufloader-svg.so and an svg entry in loaders.cache. Given that there were no replies, I assume that that is the complete checklist. Your librsvg may be too old to render symbolic icons. See https://git.gnome.org/browse/librsvg/commit/?id=b864307868d3977dfa5e127ff95d7efded854850 and the bug referenced there. Indeed: I am using librsvg 2.36.4 as per the referenced email. I just had a go at building 2.40.1, but: rsvg-base.c:2194:5: error: implicit declaration of function 'canonicalize_file_name' ? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
Le vendredi 22 novembre 2013 à 12:56 +, Patrick Welche a écrit : On Thu, Nov 21, 2013 at 10:40:42AM -0500, Jasper St. Pierre wrote: On Thu, Nov 21, 2013 at 10:35 AM, Patrick Welche pr...@cam.ac.uk wrote: 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 pr...@cam.ac.uk wrote: (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?) Is there a way of validating gnome/icon-theme.cachegnome/index.theme further? I'd put a print statement inside the for loop near that if statement that prints the theme name, e.g. g_print (searching theme %s\n, theme-name); It sounds to me like the gnome icon theme isn't being properly added. Maybe also put lots of print statements in insert_theme. Is that being called with gnome as a theme name? Is it bailing out at some point before it's supposed to? At least g_key_file_load_from_file() is not giving an error with icons/gnome/index.theme Probably why icons/gnome cache was found in earlier post? If there were a problem, found cache for ...icons/gnome wouldn't have been printed? gtk_icon_theme_lookup_icon dialog-password theme_lookup_icon: searching theme hicolor for dialog-password ... theme_lookup_icon found dialog-password in dir (null) I don't see searching theme gnome for dialog-password yet it is found. gtk_icon_theme_lookup_icon go-up-symbolic theme_lookup_icon: searching theme hicolor for go-up-symbolic ... theme_lookup_icon: searching theme gnome for go-up-symbolic ... theme_lookup_icon look for go-up-symbolic in dir .../hicolor/48x48/actions theme_lookup_icon look for go-up-symbolic in dir .../gnome/48x48/actions ... BUT not in icons/gnome/scalable/actions Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found). My two cents ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found). That was what I was worried about in: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html I have libpixbufloader-svg.so and an svg entry in loaders.cache. Given that there were no replies, I assume that that is the complete checklist. Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche pr...@cam.ac.uk wrote: On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found) That was what I was worried about in: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html I have libpixbufloader-svg.so and an svg entry in loaders.cache. Given that there were no replies, I assume that that is the complete checklist. Your librsvg may be too old to render symbolic icons. See https://git.gnome.org/browse/librsvg/commit/?id=b864307868d3977dfa5e127ff95d7efded854850 and the bug referenced there. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Thu, Nov 21, 2013 at 10:40:42AM -0500, Jasper St. Pierre wrote:
On Thu, Nov 21, 2013 at 10:35 AM, Patrick Welche pr...@cam.ac.uk wrote:
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 pr...@cam.ac.uk wrote:
(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?)
Is there a way of validating
gnome/icon-theme.cachegnome/index.theme
further?
I'd put a print statement inside the for loop near that if statement that
prints the theme name, e.g.
g_print (searching theme %s\n, theme-name);
It sounds to me like the gnome icon theme isn't being properly added. Maybe
also put lots of print statements in insert_theme. Is that being called
with gnome as a theme name? Is it bailing out at some point before it's
supposed to?
At least g_key_file_load_from_file() is not giving an error with
icons/gnome/index.theme
Probably why icons/gnome cache was found in earlier post? If there
were a problem, found cache for ...icons/gnome wouldn't have been
printed?
gtk_icon_theme_lookup_icon dialog-password
theme_lookup_icon: searching theme hicolor for dialog-password
...
theme_lookup_icon found dialog-password in dir (null)
I don't see searching theme gnome for dialog-password yet it is found.
gtk_icon_theme_lookup_icon go-up-symbolic
theme_lookup_icon: searching theme hicolor for go-up-symbolic
...
theme_lookup_icon: searching theme gnome for go-up-symbolic
...
theme_lookup_icon look for go-up-symbolic in dir .../hicolor/48x48/actions
theme_lookup_icon look for go-up-symbolic in dir .../gnome/48x48/actions
...
BUT not in icons/gnome/scalable/actions
Cheers,
Patrick
--- gtk/gtkicontheme.c.orig 2013-11-11 13:53:39.0 +
+++ gtk/gtkicontheme.c
@@ -1098,6 +1098,8 @@ insert_theme (GtkIconTheme *icon_theme,
priv = icon_theme-priv;
+ GTK_NOTE (ICONTHEME, g_print (insert_theme %s\n, theme_name));
+
for (l = priv-themes; l != NULL; l = l-next)
{
theme = l-data;
@@ -1136,11 +1138,15 @@ insert_theme (GtkIconTheme *icon_theme,
g_key_file_load_from_file (theme_file, path, 0, error);
if (error)
{
+ GTK_NOTE (ICONTHEME,
+g_print (Error loading %s: %s\n, path, error-message));
g_key_file_free (theme_file);
theme_file = NULL;
g_error_free (error);
error = NULL;
}
+ else
+GTK_NOTE (ICONTHEME, g_print (Loaded %s successfully\n, path));
}
g_free (path);
}
@@ -1634,6 +1640,10 @@ choose_icon (GtkIconTheme *icon_th
icon_info = g_object_ref (icon_info);
remove_from_lru_cache (icon_theme, icon_info);
+ GTK_NOTE (ICONTHEME,
+ g_print (choose_icon: found %s in cache\n,
+ g_strjoinv (,, icon_info-key.icon_names)));
+
return icon_info;
}
@@ -2813,6 +2823,10 @@ theme_lookup_icon (IconTheme *t
min_difference = G_MAXINT;
min_dir = NULL;
+ GTK_NOTE (ICONTHEME,
+g_print (theme_lookup_icon: searching theme %s for %s\n,
+ theme-name, icon_name));
+
/* Builtin icons are logically part of the default theme and
* are searched before other subdirectories of the default theme.
*/
@@ -2822,8 +2836,13 @@ theme_lookup_icon (IconTheme *t
size, scale,
min_difference);
+
if (min_difference == 0)
- return icon_info_new_builtin (closest_builtin);
+{
+ GTK_NOTE (ICONTHEME,
+g_print (theme_lookup_icon found %s in builtins\n,
icon_name));
+ return icon_info_new_builtin (closest_builtin);
+}
dirs = builtin_dirs;
}
@@ -2836,7 +2855,7 @@ theme_lookup_icon (IconTheme *t
dir = l-data;
GTK_NOTE (ICONTHEME,
- g_print (theme_lookup_icon dir %s\n, dir-dir));
+ g_print (theme_lookup_icon look for %s in dir %s\n,
icon_name, dir-dir));
suffix = theme_dir_get_icon_suffix (dir, icon_name, NULL);
if (best_suffix (suffix, allow_svg) != ICON_SUFFIX_NONE)
{
@@ -2926,11 +2945,18 @@ theme_lookup_icon (IconTheme *t
min_dir-subdir_index);
}
+ GTK_NOTE (ICONTHEME,
+ g_print (theme_lookup_icon found %s in dir %s\n, icon_name,
min_dir-dir));
+
return icon_info;
}
if (closest_builtin)
-return icon_info_new_builtin (closest_builtin);
+{
+ GTK_NOTE (ICONTHEME,
+g_print (theme_lookup_icon found (close to) %s in
builtins\n, icon_name));
+ return icon_info_new_builtin (closest_builtin);
+}
return NULL;
}
Re: symbolic icon fallback failure
On 11/21/13 15:38, Patrick Welche 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. Just in case: are you running the latest GLib (2.38.2) as well? I don't know how icons are loaded in your case, but they could come from glib and the fallback to non-symbolic icons was only added there in 2.38.2 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. Can you shed light on what is meant to happen? Cheers, Patrick 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? Attached is a patch to 3.10.3 I used to spew more debugging output. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
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 pr...@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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Thu, Nov 21, 2013 at 10:40:42AM -0500, Jasper St. Pierre wrote: On Thu, Nov 21, 2013 at 10:35 AM, Patrick Welche pr...@cam.ac.uk wrote: 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 pr...@cam.ac.uk wrote: (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?) Is there any more I can do to check that icons/gnome/index.theme icons/gnome/icon-theme.cache are OK? (Given Gtk 3's --enable-gtk2-dependency, it shouldn't matter if gtk 2.24.20 created the cache?) I'd put a print statement inside the for loop near that if statement that prints the theme name, e.g. g_print (searching theme %s\n, theme-name); It sounds to me like the gnome icon theme isn't being properly added. Maybe also put lots of print statements in insert_theme. Is that being called with gnome as a theme name? Is it bailing out at some point before it's supposed to? Thanks for the pointer - more soon... Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Thu, Nov 21, 2013 at 9:38 AM, Patrick Welche pr...@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. Can you shed light on what is meant to happen? Cheers, Patrick 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. Attached is a patch to 3.10.3 I used to spew more debugging output. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Thu, Nov 21, 2013 at 10:35 AM, Patrick Welche pr...@cam.ac.uk wrote: 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 pr...@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. You seemed confused why hicolor is searched. It's normal for it to be searched as a fallback. I'd put a print statement inside the for loop near that if statement that prints the theme name, e.g. g_print (searching theme %s\n, theme-name); It sounds to me like the gnome icon theme isn't being properly added. Maybe also put lots of print statements in insert_theme. Is that being called with gnome as a theme name? Is it bailing out at some point before it's supposed to? 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 -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Thu, Nov 21, 2013 at 04:14:13PM +0100, Olivier Brunel wrote: On 11/21/13 15:38, Patrick Welche 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. Just in case: are you running the latest GLib (2.38.2) as well? I don't know how icons are loaded in your case, but they could come from glib and the fallback to non-symbolic icons was only added there in 2.38.2 Thanks for the note - I was running 2.38.1, but just tried 2.38.2 and there is no change: evince is asking gtk to look for the icons... Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
