After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 752562 - Problems loading Icons for svg files in open file dialog
Problems loading Icons for svg files in open file dialog
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
unspecified
Other Windows
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-07-18 11:39 UTC by Simon Müller
Modified: 2018-05-24 17:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
svg icons appear as white sheet of paper (59.36 KB, image/png)
2015-07-18 11:39 UTC, Simon Müller
Details
Some extra information for the mentioned events. (113.31 KB, image/png)
2015-07-18 16:48 UTC, Simon Müller
Details
open file dialog icons gimp 2.8.14 2.inst. vs inkscape 0.91 r13725 (113.73 KB, image/png)
2015-07-18 21:50 UTC, Simon Müller
Details

Description Simon Müller 2015-07-18 11:39:47 UTC
Created attachment 307659 [details]
svg icons appear as white sheet of paper

Whenever I navigate to a folder containing svg-files in gimp's open file dialog, the following happens (recorded with process monitor): 

18:01:29,8346796	gimp-2.8.exe	4932	RegOpenKey	HKCU\Software\Classes\inkscape.svg\DefaultIcon	NAME NOT FOUND	Desired Access: Query Value
18:01:29,8346939	gimp-2.8.exe	4932	RegOpenKey	HKCR\inkscape.svg\DefaultIcon	SUCCESS	Desired Access: Query Value
18:01:29,8347198	gimp-2.8.exe	4932	RegQueryKey	HKCR\inkscape.svg\DefaultIcon	SUCCESS	Query: Name
18:01:29,8347291	gimp-2.8.exe	4932	RegQueryKey	HKCR\inkscape.svg\DefaultIcon	SUCCESS	Query: HandleTags, HandleTags: 0x0
18:01:29,8347422	gimp-2.8.exe	4932	RegOpenKey	HKCU\Software\Classes\inkscape.svg\DefaultIcon	NAME NOT FOUND	Desired Access: Maximum Allowed
18:01:29,8347518	gimp-2.8.exe	4932	RegQueryValue	HKCR\inkscape.svg\DefaultIcon\(Default)	SUCCESS	Type: REG_SZ, Length: 88, Data: "E:\Programme\Grafik\Inkscape\inkscape.exe"
18:01:29,8347617	gimp-2.8.exe	4932	RegQueryKey	HKCR\inkscape.svg\DefaultIcon	SUCCESS	Query: Name
18:01:29,8347692	gimp-2.8.exe	4932	RegQueryKey	HKCR\inkscape.svg\DefaultIcon	SUCCESS	Query: HandleTags, HandleTags: 0x0
18:01:29,8347779	gimp-2.8.exe	4932	RegOpenKey	HKCU\Software\Classes\inkscape.svg\DefaultIcon	NAME NOT FOUND	Desired Access: Maximum Allowed
18:01:29,8347863	gimp-2.8.exe	4932	RegQueryValue	HKCR\inkscape.svg\DefaultIcon\(Default)	SUCCESS	Type: REG_SZ, Length: 88, Data: "E:\Programme\Grafik\Inkscape\inkscape.exe"
18:01:29,8347953	gimp-2.8.exe	4932	RegCloseKey	HKCR\inkscape.svg\DefaultIcon	SUCCESS	
18:01:29,8383893	gimp-2.8.exe	4932	QueryOpen	E:\Programme\Grafik\GIMP 2\bin\"E:\Programme\Grafik\Inkscape\inkscape.exe"	NAME INVALID	
18:01:29,8385007	gimp-2.8.exe	4932	CreateFile	C:\Users\Simon\"E:\Programme\Grafik\Inkscape\inkscape.exe"	NAME INVALID	Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
...

Gimp the proceeds to traverse every folder in my PATH, always with inkscapes executable path attached to the respective path. For some reason it seems to search the PATH for the inkscape executable in order to receive the icon although it already has the complete path to it. The result of gimp not finding the executable is that all svg-icons are displayed as a white sheet of paper (see attachment).
Comment 1 Simon Müller 2015-07-18 16:48:16 UTC
Created attachment 307663 [details]
Some extra information for the mentioned events.

I just found out that it is possible to view the stack trace for the events. Maybe this helps to locate the function that is responsible for the bug.
Comment 2 Michael Natterer 2015-07-18 17:46:10 UTC
(Note: Not a Windows expert here)

This looks like you at some point had Inkscape which had installed
itself as handler for .svg, including an icon. Now it probably does
some registry lookups where some leftover garbage from the Inkscape
installation is found, then it fails using that garbage...
Comment 3 Simon Müller 2015-07-18 20:36:13 UTC
Yes, you are right - I have Inkscape and it is installed as handler for svg (sorry, I forgot to mention that in my original report).

But the path from the registry is not "some leftover garbage" - Inkscape actually IS located at E:\Programme\Grafik\Inkscape\inkscape.exe. 
So the behavior I would expect is gimp directly going to E:\Programme\Grafik\Inkscape\inkscape.exe, extracting the icon from the exe and using it for the svg files (as it does with the standard icons for . 

But instead of doing this, gimp takes all the paths from PATH and just appends "E:\Programme\Grafik\Inkscape\inkscape.exe" to them. Then it tries to open for example C:\Users\Simon\"E:\Programme\Grafik\Inkscape\inkscape.exe" - what is total nonsense. 


I just found a difference to all the other Icons that are loaded when opening the open file dialog: all the other paths from the registry have some offsets added to them - for example "%SystemRoot%\System32\imageres.dll,-72" or "E:\Programme\Grafik\GIMP 2\bin\gimp-2.8.exe,1". Inkscape has the only path without an offset. Maybe gimp/gtk gets confused when this offset is missing (some kind of regex-problems, ...)? By the way: Windows Explorer displays the icons nevertheless - so in my opinion gimp should not have a problem with it either.
Comment 4 Michael Natterer 2015-07-18 21:29:39 UTC
What you go to the same folder in Inkscape, how do the icons look?
Comment 5 Simon Müller 2015-07-18 21:50:57 UTC
Created attachment 307665 [details]
open file dialog icons gimp 2.8.14 2.inst. vs inkscape 0.91 r13725
Comment 6 Michael Natterer 2015-07-18 22:36:31 UTC
Thanks but unfortunately that looks like a windows native file dialog,
that won't help us to track down the issue.

The code that gets the icon seems to be in g_content_type_get_icon()
in glib/gio/gcontenttype-win32.c, so we're dealing either with a GIO
bug, or with an Inkscape installer bug (whatever registry misconfiguration)

Since you are on Windows, could you try tracking that down?
Comment 7 Simon Müller 2015-07-18 23:45:10 UTC
I guess it's both: on one hand the inkscape installer should do the same as every other application and simply add the icon offset to the path in the registry and on the other hand, glib should maybe use the first icon available in a binary file, if there is no offset given - windows seems to do the same. 

As you can see in the comments of g_content_type_get_icon, the author did not even think about what happens when the offset is missing. Unfortunately I can't figure out where exactly the actual icon is retrieved. g_content_type_get_icon seems to just get the executable's path from the registry and save it in a hashtable for later use. As I'm pretty new in C/C++ and never worked with such a large project, I lost track at the return statement in g_themed_icon_new from gthemedicon.c.
Comment 8 Michael Schumacher 2015-07-21 15:28:57 UTC
If we are sure that this is not a problem in GIMP code, we should reassign the bug.
Comment 9 Michael Natterer 2015-07-25 18:03:24 UTC
Yeah let's reassign it to GIO.

GIO folks, see comments 6 and 7.

Simon, can you paste the output of gimp --version --verbose here so
we can see which GLib version is being used?
Comment 10 Simon Müller 2015-07-26 14:01:32 UTC
This is the output of gimp-2.8.exe --version --verbose:


GNU Image Manipulation Program Version 2.8.14
git-describe: GIMP_2_8_12-2-ge62e6fe

verwendet GEGL Version 0.2.0 (gebaut gegen Version 0.2.0)
verwendet GLib Version 2.40.0 (gebaut gegen Version 2.40.0)
verwendet GdkPixbuf Version 2.30.8 (gebaut gegen Version 2.30.8)
verwendet GTK+ Version 2.24.24 (gebaut gegen Version 2.24.23)
verwendet Pango Version 1.36.5 (gebaut gegen Version 1.36.5)
verwendet Fontconfig Version 2.11.1 (gebaut gegen Version 2.11.1)
verwendet Cairo Version 1.12.16 (gebaut gegen Version 1.12.16)

(verwendet = using; gebaut gegen = built/compiled against)
Comment 11 Matthias Clasen 2015-07-26 19:20:10 UTC
The code that interprets these 'themed' icons is here:

https://git.gnome.org/browse/gtk+/tree/gtk/gtkicontheme.c#n1748

Feel free to point out anything that might be wrong with it.
Comment 12 GNOME Infrastructure Team 2018-05-24 17:57:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1061.