GNOME Bugzilla – Bug 752562
Problems loading Icons for svg files in open file dialog
Last modified: 2018-05-24 17:57:39 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).
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.
(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...
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.
What you go to the same folder in Inkscape, how do the icons look?
Created attachment 307665 [details] open file dialog icons gimp 2.8.14 2.inst. vs inkscape 0.91 r13725
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?
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.
If we are sure that this is not a problem in GIMP code, we should reassign the bug.
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?
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)
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.
-- 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.