So, Gnome Shell is moving to a document centric model, and is starting to leverage new components, like Zeitgeist or Tracker to make finding documents easier. And an interesting issue stems from the fact that the concept of “Document” is much broader than the good old concept of “UNIX file”. Both Zeitgeist and Tracker deal not only with files, but also with resources such as conversations, emails, people, bookmarks… And both allow the user to find those items.

Finding the items… and what?

So, you found what you were searching for. Now, what do you do with it? Is it a pdf document? Easy, fire up the PDF viewer! An image? Fire the image viewer! A contact? An email? How do we identify those? What do we do with them?

The identification problem is already solved if you assign a URI to each resource, so for example if your contacts are in Tracker you just pass the URI of the contact, and done. Same for an email. However, what application can deal with a contact? Files have MIME types, resources don’t…

If you use Tracker, then you can use the RDF class(es) as an extension to MIME types, which is what libcontentaction does (libcontentaction was developed for the Harmattan operating system, where all the user resources are stored or exported in Tracker). Since Tracker, Zeitgeist, and KDE’s semantic system all revolve around RDF, RDF classes seems like a good candidate to extend traditional MIME types in a cross desktop way.

I believe this problem will become increasingly relevant for Gnome Shell, and I hope the work done for libcontentaction (which is a Qt lib) will be used as a base as much as possible, and hopefully end up as a XDG standard, since our KDE folks also have a pretty advanced semantic desktop system. The upcoming Desktop Summit (where I’ll likely not be this year 🙁 ) would actually be a great place to discuss this.

An example – the email case

Tracker has been indexing your emails if you’re using Evolution for some time now, and my work on Thunderbird has recently been merged, Needle, the Tracker search tool has supported email searching for some time now too. However, we’re still unable to actually do anything useful with an email result, since there is no standard mechanism to associate an action with those resources.

If you are trying the Thunderbird plugin, there is actually something you can do (but I don’t know if it works with the evolution miner too):

Create a thunderbird.desktop file (or alter the existing one) and make sure those two lines are inside:

Exec=thunderbird -mail %u
MimeType=x-scheme-handler/imap-message

This works because the emails are stored in Tracker with the URL scheme imap-message:// that Thunderbird understand directly. I have no idea how standard this is, but eh, it’s quite convenient 🙂

More thoughts…

Another very interesting problem is “how to expose the relations between resources”, that is, how to go behind the old treeview/table models and present related information in a more efficient way… But that’s another broad subject.

8 Responses to ““Launching” resources in a document oriented world”


  1. Standards for URLs in E-mail:

    http://www.faqs.org/rfcs/rfc5092.html
    http://tools.ietf.org/html/rfc2384

    No idea why Thunderbird uses imap-message:// etc :-\

    For mailbox there’s something similar that goes like mailbox://folder/messageid-ish-something

    For mbox it’s something like mbox://mboxfilepath/ID

    Etc

  2. mccann Says:

    GNOME isn’t moving to a document-centric model. See https://live.gnome.org/Design/Apps/ for current plans.

    • amazari Says:

      Even if the entry points remain applications in those applications mockups, the data is accessed through highter abstractions than files (Music, Documents, Contact …) from what I might gather.

      So you are doing somekind of “document-centering” without noticing in a way 😉

      Even applications in g-s are more than mere binaries path. They have metadata, icons, exposed, file/resource-type association, behaviour via GtkActions etc…
      Good candidates to be indexed and provided by tracker to g-s, maybe.

  3. amazari Says:

    I wonder if the application resource type relationship couldn’t be stored in tracker itself.

    Tracker indexes .desktop files, right ?

    A semantic link between resources classes and applications might allow to get the right viewer using SPARQL.
    Dunno if that sounds good or even possible, anyway 🙂


    • Tracker has an application miner yes. The information has to come from somewhere though (in that case, the desktop file, though it’d be easy to add a new key there). And also, there is some work on the applications side, so they know how to handle the URI…

  4. Todd Says:

    So, basic question: Now that your work has been merged, ow do I get tracker working with Thunderbird 5? Is this only with the latest source? I’ve got over 30Gb of Thunderbird emails (going back to 2000) and would love to figure out how to get tracker to index them. Any place I can find instructions or an FAQ for getting this working?

    Thanks!


Comments are closed.