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 469317 - Remove user specified emblems
Remove user specified emblems
Status: RESOLVED INCOMPLETE
Product: nautilus
Classification: Core
Component: [obsolete] Backgrounds Emblems and Themes
0.x.x [obsolete]
Other Linux
: Normal enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-08-22 16:52 UTC by Michael Monreal
Modified: 2010-07-19 12:33 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Michael Monreal 2007-08-22 16:52:22 UTC
In bug #335332, which is about LeafTag integration, Alexander Larsson writes: "Emblems are essentially tags already, so just dumping in another form of tags next to it is looking kinda weird."

Well, this is true, but it's not the way to go IMHO.

Emblems can be nice to have for two things:

* Making the user aware of certain attributes (noread, nowrite, link...)
* Helping the user to navigate (photos/music/document folders...)

The first case is handled by nautilus automatically. The second case is also possible currently.

Today it is possible to use emblems as "tags", for example for querying all files/folders with emblem X with Beagle.

It is of note, that having more than one emblem on a given file/folder doesn't really work. In list view, only one (random?) emblem is shown, in icon view this seems to depend on the zoom size... anyway, having more than one emblem tends to look ugly. Plus, the various UIs for setting emblems (properties dialog, emblems dialog, sidebar) are not very nice to use.

Also, having a fixed set of tags (when using emblems as tags) doesn't make much sense...

So here's the proposal: split "emblems" and "tags"!

1.) Simplify the emblems system: key feature would be to only allow one emblem per file or folder. This way, we can make sure it looks good! The UI for setting the emblem would be much simpler than what we have now and could perhaps be integrate with the "set custom icon" feature we have right now, or added as a dropdown menu.

2.) Add support for real tags! Those would be text-only and could for example be used for queries in tools like beagle. Perhaps LeafTag can be used for this, perhaps we need a new implementation...
Comment 1 Michael Monreal 2008-04-06 14:47:39 UTC
Half a year later, some things to add:

- emblems should always be displayed automatically (noread, nowrite, link,
shared, volume encrypted etc)

- special folders should have special icons, like the home folder currently
has. Other candidates: desktop (user-desktop instead of an emblem), XDG
directories (e.g. audio, video, photos folder)

- real tagging system for integration into search apps etc

=> this would cover 95% of the use cases where emblems are currently used for
IMHO. For the rest, there's always possibility to set a custom icon.

There's another very important thing: folders should look the same in the file
chooser as they look in nautilus. Using special folder icons would make this
simple for example.
Comment 2 Allan Day 2010-06-03 22:00:39 UTC
Renaming this bug for clarity. Let me know if I got it right! This is an open design question, I think. I'm sympathetic with the suggestion, but I suspect that there still might be a role for emblems.

Setting to NEEDINFO, since I think there needs to be a wider design discussion about this. I will try and follow up, but feel free to ping me if you don't see any movement on this issue.
Comment 3 Tobias Mueller 2010-07-19 12:33:52 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!