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 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 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
On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote: > On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche 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 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
> 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 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 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
On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote: > On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche 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
On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche 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 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
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 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 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 Thu, Nov 21, 2013 at 10:40:42AM -0500, Jasper St. Pierre wrote:
> On Thu, Nov 21, 2013 at 10:35 AM, Patrick Welche 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 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 NUL
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 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:35 AM, Patrick Welche 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 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 9:38 AM, 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. > > 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:40:42AM -0500, Jasper St. Pierre wrote:
> On Thu, Nov 21, 2013 at 10:35 AM, Patrick Welche 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 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 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
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
