GNOME Bugzilla – Bug 321660
Emblems do not appear in the "Places" sidebar
Last modified: 2012-07-30 15:23:00 UTC
If you open the tree sidebar in nautilus, emblems will appear on top of folders which have them. In you open the places sidebar, there's no emblem on any folder, even if they should have one.
Created attachment 54842 [details] screenshot of the tree side pane There is an emblem on the "Images" folder.
Created attachment 54843 [details] Screenshot of the "places" side pane There is no emblem on the Images folder
Thanks for your bug report!
Created attachment 72199 [details] [review] Prelim. patch implementing (somewhat) this functionality Has some issues: * Doesn't update the emblem icons very often. Only when you close then open side pane/nautilus, or rename a bookmark. * Probably leaks memory. I'm not sure whether this is the right way of going about this, tips would be appreciated.
*** Bug 523836 has been marked as a duplicate of this bug. ***
Hi Henry, I'm marking your patch as "needs-work" because Nautilus has been ported from gnome-vfs to the new GIO infrastructure during the 2.21 development cycle, so many things have changed in the codebase and your patch does not apply anymore. If you plan rewriting your patch, you may want to post it to the Nautilus mailing-list [1] where it can get proper review. Thanks! [1] nautilus-list@gnome.org
*** Bug 477470 has been marked as a duplicate of this bug. ***
Duplicate bug #477470 has a patch for this bug too, you can find it at http://bugzilla.gnome.org/attachment.cgi?id=95677&action=view
Is there any progress with this bug?
mehdi abaakouk's patch works perfectly well.
*** Bug 496073 has been marked as a duplicate of this bug. ***
This problem also appears in the Places menu, the taskbar, and at the bottom of a `spatial' Nautilus window.
If mehdi abaakouk's patch works perfectly well, why hasn't it been used after a year?
(In reply to comment #13) > If mehdi abaakouk's patch works perfectly well, why hasn't it been used after a > year? > It worked with 2.22, now it needs to be updated. Anyway, I really doubt any of the nautilus devs will see your message. If you want to get their attention, write to the nautilus mailing list or send them e-mails directly.
(In reply to comment #13) > If mehdi abaakouk's patch works perfectly well, why hasn't it been used after a > year? If you go to the duplicate report which contains Mehdi's patch, you will see the reason is that the patch also contained some unwanted changes, such as a separate zoom level for the sidebar. I asked Mehdi to split the two parts of the patch, but he never replied. I'll try to update the patch myself before 2.28.
Is this bug still relevant for 3.0? NautilusCellRendererPixbufEmblem is gone for good...
(In reply to comment #16) > Is this bug still relevant for 3.0? NautilusCellRendererPixbufEmblem is gone > for good... Yes... NautilusCellRendererPixbufEmblem is obsoleted, as you can just use a GEmblemedIcon on a GtkCellRenderer and it will do the right thing. Even though we don't support setting custom emblems anymore on files, extensions can still do that (e.g. Dropbox), and we should display those in the sidebar.
Created attachment 202704 [details] [review] Preliminary patch using GEmblemedIcon Tested with: $ jhbuild shell # To get the proper dbus/gvfs $ mkdir test $ gvfs-set-attribute test -t stringv metadata::emblems new urgent Seems to work allright. Only works for items that actually have an URL, it should cover all the meaningful cases I think. No support for emblems_to_ignore, because I don't know what should make it to the places-sidebar and what not (all emblems seem to convey some form of useful information to me :-) ). The code is blatantly copied from nautilus-icon-view-container.c. BTW, with this patch, there are ~4 copies of this code in nautilus. I guess it could use some sharing. :-) Some global function like: NautilusIconInfo * nautilus_get_emblemed_icon_info_for_{file, url} (...) would work?
Review of attachment 202704 [details] [review]: Looks nice, with some minor points to fix. ::: src/nautilus-places-sidebar.c @@ +368,3 @@ + emblems_to_ignore = NULL; + emblem_icons = nautilus_file_get_emblem_icons (file, emblems_to_ignore); + g_strfreev (emblems_to_ignore); emblems_to_ignore is not an "out" parameter for nautilus_file_get_emblem_icons(), so if you don't want to exclude anything, just pass NULL to the function and remove the variable. @@ +370,3 @@ + g_strfreev (emblems_to_ignore); + + g_list_foreach (emblem_icons, f, NULL); Leftover? @@ +398,3 @@ + + if (emblem_icons != NULL) { + g_list_free_full (emblem_icons, g_object_unref); You can fold this in the previous block.
(In reply to comment #18) > The code is blatantly copied from nautilus-icon-view-container.c. BTW, with > this patch, there are ~4 copies of this code in nautilus. I guess it could use > some sharing. :-) Some global function like: > > NautilusIconInfo * nautilus_get_emblemed_icon_info_for_{file, url} (...) Sure, why not? I think this could be a method of NautilusFile, or maybe even a value of NautilusFileIconFlags.
Created attachment 202754 [details] [review] Second attempt Fixed as per Cosimo's comments. I think the g_assert (NAUTILUS_IS_FILE) there is harmless, but perhaps it would be better to just drop it.
Review of attachment 202754 [details] [review]: Looks good to commit with this comment fixed. Thanks! ::: src/nautilus-places-sidebar.c @@ +362,3 @@ + + file = nautilus_file_get_by_uri (uri); + g_assert (NAUTILUS_IS_FILE (file)); Is there a reason for this assert? At least nautilus_file_get_emblem_icons() does a similar check immediately, so things will fail immediately afterwards anyway.
(In reply to comment #22) Mmm, for some reason it doesn't work for the trash and networks entries, something goes wrong in the (uri != NULL) path. I'm looking into it.
(In reply to comment #23) > (In reply to comment #22) > > Mmm, for some reason it doesn't work for the trash and networks entries, > something goes wrong in the (uri != NULL) path. I'm looking into it. Looks like file->details->icon is NULL for those items, so nautilus_file_get_icon () returns "text-x-generic". Should I special case them in nautilus-sidebar.c? (I don't like special cases, but the alternatives imply much more work.)
Created attachment 203066 [details] [review] Third attempt, special-case special files. Yeah. Special case "file:///", "trash:///" and "network:///" URIs. Unless special items (trash, computer, filesystem, etc.) can be bookmarked, it would be also safe to only apply emblems to the bookmark section.
Thanks for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME. Note: the emblems functionality has been removed from nautilus. The nautilus extension at https://github.com/agonzalezro/gnome3-emblems restores this functionality. Please report bugs there, if you encounter any