Taggable Desktop


Luis: You wanted a taggable desktop? Oh, okay.

Announcing Leaftag, our desktop tagging framework. This is an evolution of the original prototype we created, originally named fstaglib (isn’t leaftag just so much better?).

The main part of Leaftag is a library called (oddly enough) libleaftag, which interfaces with the tag database. It’s GObject-based, and the API is quite small. It can tag anything with a URI.

There’s tagutils, a small app used for working with tags and files. It is able to tag and untag files, list all known tags, list all files with a specified tag, and manipulate tag properties (such as icons and descriptions). It also includes some symlinks that provide shortcuts to common tagutils functions (tag, untag, tagls, tags, and tagprop).

leaftag-python contains Python bindings for libleaftag. It simplifies the already simple libleaftag library.

And then there’s leaftag-gnome, which will contain all future GNOME support for tagging. Currently, it supports only a Deskbar handler. Future releases will hopefully include Nautilus search integration and property pages.

Now, it’s important to point out that the screenshots on my previous blog entry are of the old implementation, and have not been ported over to Leaftag yet. This is largely due to lack of time as of late (because of Galago and VMware Server work, on my part), but it’s also because we want to re-implement this correctly. In the meantime, we’re hoping additional apps will start supporting this.

This is the first public release of the Leaftag framework, so please report any bugs to us. In time, after a server migration, I plan to put together a dedicated Leaftag site and bug tracker.

19 thoughts on “Taggable Desktop”

  1. Does it support facets or some other smart way for handling larger numbers of tags? (e.g. when I want to have a tag per friend I have on my photos it makes sense to group these tags…)
    Like debtags does?

  2. Pingback: The R Zone

  3. I’m not saying that the library should *depend* on a particular EA implementation. But you should seriously consider making a backend that uses them whenever they are available, and detects their availability at runtime.

  4. Pingback: Common reasons to turn down extended attributes for tags, and rebuttals » The R Zone

  5. I see the potential for this to play an important roll in the File Manager. Specifically being able to “Force-tag” files based on thier _file_ type. Think of it, like the metadata returned by the file program, each file is tagged with that file type. Couple those tags with emblems and we get back the contextual visual cues that where lost in the recent update to the Icons.

    Not being too familiar with the inner workings of these respective technologies my guess will be either an extension to beagle that addes that One definitive tag to each file it finds. So basically if not tagged at all each file has at least one tag, its file type.

  6. I have no intentions of adding extended attribute support in the near future. I understand the reasons that a couple of people want this, but it’s not on my roadmap and not something I will be implementing any time soon. I have too many other things to be concerned about in this project and others, and to be honest, I haven’t agreed with all the arguments made. While we’re not ruling it out completely, don’t expect any xattr support any time soon.

  7. I have some problems installing library.
    Have you any public bugzilla (or similar) to report this problems?

    I’m impatient to try your work

  8. If you can show that xattrs really provide a useful advantage without adding a huge amount of code, sure. Having thought it through and listened to various arguments, both Chip & I are pretty well convinced that xattrs aren’t worth the trouble. Code would go a lot further towards convincing us than talk.

  9. Pingback: meneame.net

  10. Pingback: Hola, mundo. » Tags en el sistema operativo

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top