Just a little preview. It’s not done yet, but will be shortly. What you see below is a small python module, a useful command line utility (well, that’s not shown, but if you check the gallery these are in there will be a full-size screenshot showing one), and plugins for Nautilus, GNOME-VFS, and Deskbar. There are plans for Beagle support in the near future, and to make the system more robust.
Stay tuned. There should be a release soon.
YES !!! HA HA HA !!! FINALLY !!!
I’ve been waiting for something like this for ages. Mac OS X *almost* gets it right,
with its “Spotlight comments” thing, but it’s not really it. Looks like you’ve nailed it.
Looks fantastic. Although the number of tabs in the file properties is growing a bit too big. Do you think that tags and emblems should be merged somehow? They are very very similar in function. I could see perhaps allowing the user to set an emblem for a tag, and removing emblems altogether, so that to add an emblem you simply add a tag. “Important” tags would have emblems and unimportant ones would not, generally.
Pingback: soeren says » Blog Archive » Tagging and the GNOME Desktop
why don’t merge tags and emblems ?
Nice, but I think the Tags tab should just be a freeform field with autocomplete rather than a two-stage thing. The idea is that you’re meant to have a zillion tags with a power distribution, which would be unmanageable with that interface. It would also spare you from having a whole tab for them, pref tabs being The Devil Itself (and nifty new widgets being your apparent speciality).
– Chris
This is fantastic. How about giving sets of tags, say images, documents, music, with each file being able to add any tag, but defaulting to the most likely set according to mime type. So images could contain me, family, holidays or whatever and music contain relaxing, intense, dance without the UI getting bogged down with hundreds of possible tags.
Chris: Yeah, the UI is far from being set in stone, and I plan to work on a widget that is more like the tagging interfaces found on del.icio.us and other places. This is only a couple days worth of work spread across two people. It has a ways to go, but it’ll get there 🙂
Whaa! That’s awesome!
I’m really curious – how hard was working with Nautilus? I’ve got some things I’d love to do that would require Nautilus integration…
Ok, how about right clicking on the tag and choosing “Make into Graphic Tag” and then you get the chance to associate an emblem with the tag? That way you could ditch the Tags tab. You would then be able to tag either by emblem (requires 1 to 1 emblem-> tag) or by typing music and watching your tag turn into an icon.
–Rob
Shouldn’t tagging like this be merged with the Emblems support already in Nautilus? A tag is just an “emblem” without an icon. Or an emblem is a tag with an icon. There really probably shouldn’t be two systems for this.
It would be nice if the system is connected with f-spot database
Especially, I would really love to see the fspot’s tags on the nautilus’ tags column
This looks a lot like Epiphany topics, there’s some exciting stuff happening w.r.t. topics currently, be sure to check it out.
By the way, it would be nice if tags/emblems could be set from processes outside of nautilus (for instance via d-bus).
Hi,
Tags don’t scale well. Why don’t you use facets and tags? Makes much more sense IMHO.
Check out libtagcoll, by Enrico Zini. While this was written for handling Debian packages, it can be applied to just about any data.
Try out http://debtags.alioth.debian.org/cgi-bin/search.cgi (sorry, this often is really slow – LDAP is killing the poor alioth box)
Reinout,
You could take this whole thing a bit further and implement bookmarks using .desktop files in the filesystem for bookmarks, and tags plus beagle for the bookmark view. Crazy people could arrange bookmarks hierarchally using nautilus. That would be cool.
dave
This is awesome, I believe that Emblems and Tags should be merged however, as they perform the same function (or near enough). The currenlty existing emblems available in gnome could be converted to tags, with their respective emblem. For user created Tags there should be an option to assign user specified emblems to them.
Keep up the excellent work
I see a lot of people have already suggested merging this with the emblems. I think some work needs to happen towards consolidating the metadata available in Nautilus, for so long now, none of it has had any real use (although I do use emblems to locate files and folders I commonly want to click on).
How are you storing this metadata? There are points to be awarded if I can still see my tags over SFTP!
Now push those tags to Extended Attributes and we’re talking.
Kim~*
Davyd: Right now, it’s based on local paths. I plan to move to using URIs though. Still requires some thought.
Kim: I won’t be moved to Extended Attributes. Everyone is quick to suggest this, but you must take into account 1) you won’t be able to tag things you don’t have permissions for, and 2) unless you prepend a UID or something (which has its own problems), tags will be system-wide.
if you use paths, you must make sure that moving/renaming files won’t loose the tags. being system-wide doesn’t seem like a problem to me.
emmanuel: we have plans for that. Tags being system-wide instead of per-user *ARE* a problem. It defeats the entire purpose of tags. We’ve discussed this and thought about it quite a bit. So at this point, I’m putting my foot down and saying we are not using Extended Attributes for tags. While they are a neat thing, it limits us way too much for what we want to do. Suggestions for this whole system are very much welcome in general, but we’re not using extended attributes.
I want to second what everybody else has said: Tags and Emblems should be merged IMO.
Erich: I don’t think using facetted tags are the way to go. It’s a rather hard concept to grasp and in my opinion we should look for a system that everybody can use instead of one that in the end only a small elite of users will use. Facetted tags are perfectly okay for Debian, since tags are assigned by a rather small group of people (developers) and facetted tags lend themselves better to automatic processing, another aspect that is important for a packaging system. This aspect is not very important to GNOME. Basically all you want to do with these tags is stuff like: “Find all items that are tagged ‘Friends’, but not the ones tagged ‘Holiday’.” Tagging should come naturally: Just type the “label” you have in mind and off you go. No need to setup an elaborate tagging and categorization scheme beforehand.
For automatic processing there are other systems available, like MIME types.
– Sebastian
I did some extensive tagging with extended attributes some month ago and wrote a little gtk+/ruby application for that task. I hoped that beagle and/or nautilus would support searching EAs in the furture, who knows…
First, thanks for this awesome work !
Now, I think it would be great to modify the open / save dialogs so that you can associate tags when saving a file in the save dialog, and search for files associated with given tags in the open dialog.
Finally, in Star Trek future, we could remove the navigational part of the open/save dialog and just use tags to save and then load tagged files. And, of course, most of Nautilus could then die too 🙂
> It would be nice if the system is connected with f-spot database
> Especially, I would really love to see the fspot’s tags on the nautilus’ tags column
I think f-spot should move to this system (it looks like some server, is it not?) so several applications could integrate into it.
> It would be nice if the system is connected with f-spot database
I think f-spot should move to this system.
> Especially, I would really love to see the fspot’s tags on the nautilus’ tags column
Do you mean the f-spot icons? Yeah, that would be cool.
Pingback: Mike’s Mart » Blog Archive » Tag This!
Another problem with using extended attributes for this is that they don’t allow fast queries. If listing all files with a particular tag requires crawling the entire filesystem, it makes a lot of things (like that deskbar integration) pretty useless. If you’re already using a database for queries (and a fall-back for files you don’t have permission to xattr), what’s the point of duplicating the information in xattrs?
It looks really interesting, but why are you implementing this just for nautilus. A gnome wide tag database, which is utilized by nautilus, f-spot, beagle, maybe even the open dialog would be a big step forward. An application developer could use this as easy as libnotify or the evolution-dataserver libraries and users would find their tags everywhere.
Tagging would be a killer feature for gnome 2.14, nice work.
Lots more comments. I’ll try to address a few of them.
I want to start by clearing up a misconception. This system is not developed only for GNOME, and it’s not developed only for Nautilus. This is a very simple system for tagging on the command line. The database portions were split out into a module. As such, we’ve been able to interface with this database using Nautilus, GNOME-VFS, and Deskbar, but it’s certainly not limited to this.
So, alex, we’re not implementing this just for nautilus. That’d be silly. We’re not making it just gnome-wide. That’d be silly. There’s no reason to limit ourselves that way. I wrote libnotify, so trust me to make this just as generic 🙂
As David Trowbridge said, we’d still have to index extended attributes, and so we need a database anyway. They’re not useful for our purpose.
As for the current interfaces, yeah, they may not be very good but let me reiterate that this program is only a few days old and we haven’t even worked on it every day. It’s very very young and will take time to reach maturity. This is why we haven’t released anything or announced where the code is. Work will be done on it.
We want to merge tags and emblems. It’s on the TODO list.
I should blog all this, because I’m going to hear these questions a lot..
YES! But let’s not merge emblems and tags. Let’s ditch emblems in its incarnation. Emblems should really not be applied by humans, but should be dealt with automatically for stuff like symbolic links, CVS/SVN status, unreadable, unwritable itmes etc.
Oh and you want to look at how F-Spot deals with adding/assigning tags. I have yet to see a more efficient way.
http://jimmac.musichall.cz/demos/f-spot/tags-fspot.ogg or http://jimmac.musichall.cz/demos/f-spot/tags-fspot.avi
I love how F-Spot does it, and originally I was working on making it work like that. The problem is that nautilus extensions cannot add submenus, only menu items. So for now, the best we can do is a dialog… *sigh*
Pingback: … is down but not out » Blog Archive » 16 shopping days ’til Christmas
Sweetness. I’m looking forward to it. As others have mentioned and you’ve addressed, it does need a text entry field. For me, that’s one of the best things about tags is that there’s no “tag management”, you just tag. Great work.
Sebastian:
Facets aren’t much more than the proper way to group tags (i.e. try to make stuff as mutually exclusive and complete as possible). The implementations don’t really enforce that, since there are sometimes reasons not to do all of that.
And having the tag “john” be part of the tags group “friends” should be easy to grasp for all users… 😉
@Jakub: I disagree with you. While some emblems should in fact only be used by the system in the way you proposed, there is still a lot to gain in letting users emblem files and folders for themselves the way they want it.
Emblems are great because they don’t take away the original icon, a folder is still a folder with a picture emblem on it, it just indicates it has something to do with pictures.
Emblems are an incredibly great tool to use spatially. I think many people will agree with me that emblems should be used more, not less in the desktop.
Agree that having both tags and emblems seems redundant.
I don’t understand why tags would *not* be system-wide. When I right-click -> Properties an object, those are the object’s properties — its name, type, permissions, and so forth are not just “my view”, they’re the Properties of that Object.
If you’re going to have some parts of the Properties window be system-wide, and some be user-specific, you really need some way to make it super-clear what’s what, or I’ll be so confused when some things don’t seem to “stick” that I’ll mentally file them under “unreliable” and avoid them. (I don’t know if it’s possible to show this clearly, but I’ll reserve judgement until I see what people come up with.)
As has been written before, on the (classic) Mac OS, the finder *was* the computer — no user would say “this finder icon represents a file” — to anybody, the finder icon *was* the file. So I applaud Nautilus’ recent efforts to be as good as the old Mac finder, and any features which force you to know the difference between “this file” and “the icon I see here” will undermine that.
Jed: You misunderstand what tags are for, then. Tags are a way for individual users to organize content in any way they see fit, Making them system-wide defeats the whole purpose. You don’t have to agree, or use it, but that’s just how tags are 🙂 This system will not have support for system-wide tags.
If that’s what tags are, then you really need to come up with a way to show this, because I (as a fairly advanced Linux geek, even) misunderstood, upon seeing them. (If I was feeling cynical, I might even go so far as to suggest that you don’t understand what a file’s “Properties” are for, or what spatial Nautilus is.)
If some of the things on “Properties” are system-wide, and some are user-specific, (a) how would one realize this?, and (b) if one realized this, how would one know which are which? And even (c) why would you design something that has the potential to confuse people so horribly? Also, note that they look very very similar to the Mac’s labels, but work completely differently; isn’t this the very definition of “asking for trouble”?
This could cause a lot of headaches…
Jed, it’s not my fault that you aren’t following the whole “tag craze” and misunderstand the purpose. I mean, I’m not the first one to do this. See Amazon, Flickr, last.fm, del.icio.us, F-Spot, and a half dozen other things that other people seem to have been able to keep track of. I’m developing something that I want to use. I know others want it too, so I’m making it public. It’s not done! I can’t believe how many times I’ve repeated that.
You don’t have to like this. I know you won’t. Others will. Those are the people I care to design this for right now. Them and myself.
Jed: Emblems, window positions and window backgrounds are per-user, not system-wide, yet they share the same properties dialogs — what’s the difference?
This is exactly what I have been wanting to write for a couple years and never got around to find time to do it. Best of all I understood it is python code. Any chance we get a look at the code and try it ? Thanks in advance.
Pingback: The R Zone
There’s a response to this controversy here:
http://rudd-o.com/archives/2006/02/15/common-reasons-to-turn-down-extended-attributes-for-tags-and-rebuttals/
Pingback: david’s bloggy journal! » GNOME API documentation
I realize this may be a big wish, but I would love to see this implemented at the shell as well–if we were able to do something along the lines of:
/t/gra
/t/graphics/a
adidas anthro apple
/t/graphics/ap
And see all the files with these tags?
Imagine!
Evidently it didn’t like my < or >’s in the previous message…
We were looking for
/t/gra<tab>
/t/graphics/a<tab>
adidas anthro apple
/t/graphics/ap<tab><enter>