GNOME Bugzilla – Bug 539286
Wrong icon for folder bookmarks
Last modified: 2009-04-28 15:06:50 UTC
The bookmarks inside the places menu seem to be using the wrong icon when a theme like mist (themes inheriting the gnome theme) is used. In this case, bookmarks for special URIs like ssh:/// and obex:/// show the theme's folder icon while file:/// bookmarks only show the gnome folder.
Created attachment 113115 [details] Screesnhot Btw I think this has to do with how icons are handled in recent glib/gtk so this is most likely either a bug in those modules or a matter of adapting the panel to those changes.
Most probably because of GIcon and the hacky way we handle this...
*** Bug 544515 has been marked as a duplicate of this bug. ***
I was about to open a very similar bug.
This bug has been specially annoying, since I develop an icon theme based on GNOME icons. So far, the only solution I've found is to create inode-directory.png/svg icons but that brings about many regressions (folders won't open when you drag n' drop, visited folder icons won't appear either) since it basically forces the plain folder icon onto all folders. Is there a proper solution that doesn't involve creating inode-directory links? That seems to be the solution Ubuntu's using in intrepid for their human icons, but the regressions are clear. I've noticed this bug since the early releases of unstable GNOME 2.23, and it doesn't seem to be fixed even now after the official release.
Ok, I found the reason this happens and a solution for this bug. The latest builds of gnome-icon-theme now include an inode-directory icon. This icon is the culprit here. Since most icon themes inherit from gnome-icon-theme, they will show that icon in many places, and will suffer from the drawbacks of having that icon (there is a reason inode-directory was never included in the past). In Ubuntu Intrepid Beta, removing all inode-directory.png/.svg, logging out and back in will make other icons that inherit from gnome-icon-theme work again.
I obviously verified this same issue with some users who already upgraded to Ubuntu Intrepid Ibex, and therefore, to GNOME 2.24, and I think the best solution would be for GNOME to remove the inode-directory icon from the gnome-icon-theme, unless there is some other workaround, respectful to the user, that I'm not aware of. I'm used to changing the whole icon naming of the icon themes I happen to develop/modify for personal use each time GNOME makes a new release, but this time it seems the issue is quite different.
Is there any chance for this issue to be resolved in the future, by either removing the inode-directory.png/svg icon links in the "gnome-icon-theme" package or by fixing the regressions caused by using such an icon? Casual users really shouldn't be expected to start creating "inode-directory" links to almost every icon theme they download from the internet, or to remove system files in order to use their favorite icon themes properly. In GNOME 2.22 and earlier versions the offending icon was never included in the "gnome-icon-theme" package and I imagine the reasons for doing so were the same reasons that have been mentioned earlier in this report. Is there any reason in particular to keep including these icons in GNOME 2.24, even when they have never been needed in the past and are currently limiting the customization options that the user has?
Also, I forgot to mention it, but maybe this bug report needs to be assigned to the "gnome-icon-theme" package rather than "gnome-panel"? Since that is where the behavior originates from.
Seems to work properly for me now on my unstable test system. Fixed in some other module (glib?) perhaps?
(In reply to comment #10) > Seems to work properly for me now on my unstable test system. Fixed in some > other module (glib?) perhaps? > What OS do you currently use for unstable testing? I can currently notice the bug in the latest development versions of Ubuntu Intrepid, Fedora 10 and Mandriva (as in bookmarks still use the default gnome icon and the folder-drag-accept icon is obsolete). Perhaps, as you say, the bug has been fixed in a more unstable module, so it'd be great to know what you're using so I can give it a try and see if it all works properly.
For me Intrepid counts as "stable" (it's using GNOME 2.24 stuff after all). My unstable GNOME runs on Intrepid, too, but it's completely built from scratch. My guess would be a GIcon change, so glib/gtk or maybe gvfs here.
what do you mean with this sentence. I've seen that it overwrites the foleder-open icon, but I don't understand this. > inode-directory.png/svg icons but that brings about many regressions (folders > won't open when you drag n' drop, visited folder icons won't appear either)
Sorry Victor I've found the answer myself.
*** Bug 555727 has been marked as a duplicate of this bug. ***
i have this trouble too, please do not ignore this bug, gnome team before doing some improvement to the desktop environment, please fix bugs like this
The proper fix for this is to treat "inode-directory" as equivalent to "folder", and completely ignore it when looking up folder-drag-accept or folder-visited.
This bug is also present in Nautilus, and it is caused by a wrong fallback order of icons in libnautilus-private/nautilus-file.c, function nautilus_file_get_gicon, lines 3428-3480. It appends names like folder-drag-accept to GThemedIcon rather than prepending them, and it does so by fetching the name list from the icon into a GPtrArray. This should be done using g_themed_icon_prepend_name.
Created attachment 125751 [details] [review] Patch for Nautilus Fixes wrong fallback order of folder and preview icons (folder-drag-accept, folder-visiting, folder-open, text-x-preview) in Nautilus.
(In reply to comment #19) > Created an attachment (id=125751) [edit] > Patch for Nautilus > > Fixes wrong fallback order of folder and preview icons (folder-drag-accept, > folder-visiting, folder-open, text-x-preview) in Nautilus. > Wow, thanks for all the work you've put into finding and solving this issue. Will your patch be implemented/added to a future stable release?
Please attach the nautilus patch to a nautilus bug, or send it to nautilus-list. Else, it will get lost. Thanks!
Krzysztof: ping - Can you post the bug number here; or was this already sent to the nautilus-list?
Same bug here.
(In reply to comment #22) > Krzysztof: ping - Can you post the bug number here; or was this already sent to > the nautilus-list? > I think the patch was already sent to nautilus-list, here's the page: http://mail.gnome.org/archives/nautilus-list/2009-January/msg00019.html However, no one seems to have replied to it. I've also checked the trunk changelog for nautilus and it hasn't been mentioned at all. Is there any way to get someone to notice?
This should work fine in 2.26.1 (I made gnome-panel behave correctly with GIcon).