GNOME Bugzilla – Bug 740025
Missing folder icons
Last modified: 2016-09-07 14:11:13 UTC
Created attachment 290528 [details] screenshot 1. Scan a folder - it has an icon 2. Exit baobab 3. Run baobab - the folder now have a 'missing' icon baobab-3.14.1-1.fc21.x86_64
It seems that for some reason the theme doesn't provide anymore an icon for the mimetype "inode-directory", except in the symbolic variant.
(In reply to Stefano Facchini from comment #1) > It seems that for some reason the theme doesn't provide anymore an icon for > the mimetype "inode-directory", except in the symbolic variant. What do you use to get the icon from the mime-type? You should be fixing that instead of working around it in shared-mime-info.
$ gvfs-info . standard::icon: folder standard::content-type: inode/directory standard::fast-content-type: inode/directory standard::symbolic-icon: folder-symbolic, folder [...] The icon for the mime type inode/directory is folder.
The problem is that baobab uses GtkRecentInfo (https://git.gnome.org/browse/baobab/tree/src/baobab-location.vala#n155), which in turn calls g_content_type_get_icon() directly to obtain the icon (see https://git.gnome.org/browse/gtk+/tree/gtk/gtkrecentmanager.c#n2039). On the other hand, gvfs goes through GFileInfo, which has a special case treatment for the inode/directory type (see https://git.gnome.org/browse/glib/tree/gio/glocalfileinfo.c#n1629). What is the correct fix here, adjusting baobab or introducing a special case in GtkRecentInfo, too?
I was looking at this bug too and found that g_content_type_get_icon was used by GtkRecentManager so it was not affected by the workaround in GLocalFileInfo. Rather than adding a special case to g_content_type_get_icon I added a generic icon for inode/directory to shared-mime-info: https://bugs.freedesktop.org/show_bug.cgi?id=89150 This fixes the bug and makes [0] unnecessary since the code path leads through g_content_type_get_icon as well. So it could be reverted once the new shared-mime-info has been released (+ some time for distros to pick it up). Alternatively I also have a patch that adds the special case to g_content_type_get_icon so it would cover GtkRecentManager as well as GLocalFileInfo. [0] https://git.gnome.org/browse/glib/commit/?id=90025254fd0047d61fe5c1de84b905da842c43f0
Created attachment 296957 [details] [review] Patch against glib to use the "folder" icon for the "inode/directory" mime type
It seems the problem persists also in Fedora 23. I don't know the current state in other products, but it might be good to make some workaround in Baobab, before it will be fixed in other products... I suppose recent locations are always folders and therefor it is always "inode/directory". Thus recent_info.get_gicon() is redundant, because it should return folder icon always. Am I wrong? (File info has to be used instead if we want to see e.g. folder-video.)
Created attachment 311336 [details] [review] Location: Set folder icon for recent locations
My patch to shared-mime-info has been accepted an merged but there has not been a new release since then, neither has it been backported to Fedora. Once either of these happen, the bug should be fixed. If we want to work around this on the gnome side, I would still say we should go with my glib patch rather than adding a workaround in baobab.
shared-mime-info 1.5 is now released: http://www.freedesktop.org/wiki/Software/shared-mime-info/ We usually release in lockstep with GNOME and distribution releases, about once every 6 months.
I can confirm that the issue is fixed with shared-mime-info 1.5 on Fedora 23 (baobab-3.18.0-1.fc23.x86_64). Thanks a lot!