This post is about an upcoming feature in Zeitgeist 0.3.3 and is so far only available in checkouts from trunk or our PPA. It is expected to be released within the next weeks.

Some weeks ago I implemented a new feature in Zeitgeist and I figured I’d drop some lines about it. I’m talking about a data-source registry.

You may be wondering, «what the hell is that even, a data-source?». So Zeitgeist is a database, a global event log, but it doesn’t do any magic indexing or monitoring by itself;  the information it logs needs to come from somewhere – be it applications sending it to Zeitgeist themselves, daemons, plugins for applications, etc. Any such entity is called a «data-source».

Having a register of all data-sources interacting with Zeitgeist provides some benefits, like for example:

Screenshot of tools/gtk/zeitgeist-data-sources-gtk.py

Prototype of a data-source management user-interface

  • Having a list of them. Lists are nice :).
  • Being able to disable data-sources from a centralized place instead of requiring each to write its own preferences dialogue.
  • Being able to set up a blacklist rule considering which data-source the information comes from as a condition (not implemented yet).

More details

When they register, data-sources will need to provide the following information: an unique ID, a name (may be localized), a description (may be localized) and optionally a template specifying what sort of events it logs. Additionally, the last timestamp the data-source was seen by Zeitgeist, whether it is running right now and whether it is enabled will also be available.

It is important to note that registration is not compulsory; while it is highly encouraged for data-sources to use it, is it still possible to anonymously insert information into Zeitgeist (for example from a shell script). The event template is also only informational, and will not be enforced by Zeitgeist at this time.

Avoiding duplicates from GTK Recently Used

You may know that zeitgeist-datahub provides basic support for applications which have no direct Zeitgeist support but do use GTK’s RecentManager, which is not as detailed as we would like, but it is better than nothing. However, until now we had a problem: when applications had support for both, GTK’s Recently Used and Zeitgeist (be it native or as an extension), it was possible for duplicate events to be inserted or other sorts of conflicts between both data-sources. Now that we have the information from the registry available, we’ve been able to solve this modifying our Recently Used data-source to ignore any events concerning applications which already have another data-source logging the same types of events.
 


In case you don’t care at all about what I’m talking here and you just want to see fancy interfaces, go check this out.