GTK+ has had support for Tracker for a while as a backend search engine used in the GtkFileChooser. At GUADEC this year, the Tracker team were asked to update the backend at the GTK+ team meeting. I found time this week to add support and push my changes to the tracker-with-libtracker-sparql branch.

For now, I have dropped support for all older versions of Tracker because it really is a mess to maintain and GTK+ 3.0 should really be using the latest and greatest APIs anyway. The other change I made was to support searching by filenames not the content of files. There is a #define in the .c file (FTS_MATCHING) which allows switching between using FTS (Full Text Search) and filenames (which are usually part of an FTS search anyway). For me, finding a file based on the name itself seems more intuitive for the GtkFileChooser and tends to yield results I am really looking for better than the FTS matching. In most cases, I don’t want to find a file based on some content when choosing a file. I would appreciate any comments on this.

A demonstration of the new functionality:

Tracker Needle Update

What is it? Why? Where?
These questions were all covered in my previous blog about tracker-needle.

What’s changed
Well, a number of small changes have been going on based on user requests and making sure all the tracker-search-tool old features are covered. Specifically:

  • History is saved using a nice new editable combo box
  • Tags can now be seen (though that’s about it for now, more work is needed here)
  • A progress spinner has been added when queries take longer than the user might expect
  • Support for Emails has been added

You can see all these new features in the latest video:

What’s next?
I would love to get tags working better, allowing adding/removing and searching by them. Generally, searching by tags isn’t hard, what is hard is making the search categories include tags and identifying them with files. It can be done, but doing it in a fast way is not quite so trivial. I already have a patch I am working on for this.

Tracker: branches branches branches

Recently, there has been so much work going into Tracker master. For a while now we have been averaging between 1 and 2 branches a week being merged into master. So I thought I would highlight some of the sweet work going into Tracker at the moment:

Dropping libinotify
For some years, we have been using an imported version of libinotify in our source tree to do the things not available in GIO’s monitoring API. One of the main reasons we didn’t move to GIO’s API was that the model we were using didn’t fit the model GIO used. In Tracker, if you monitored a directory and it moved to another location, we moved the monitor to that location. With GIO, if you monitor a directory it doesn’t move, which makes sense. Thanks to Aleksander Morgado, we have now merged his drop-inotify branch into master. It is so nice to be able to remove that imported library now.

D-Bus with file descriptors
We are always trying to reduce the memory footprint of Tracker. Recently Adrien Bustany finished implementing support for DBUS_TYPE_UNIX_FD in Tracker. The nice thing about this, is that we now don’t copy masses of memory from one place to another just for pushing the data between two processes. Adrien and Philip have previously blogged about this, but more recently, Adrien finished support for this by also implementing this for the tracker-miner-fs and tracker-extract communication. Effectively the same data is transported between those as tracker-miner-fs and tracker-store, with the difference that tracker-store also receives file specific information appended to the SPARQL message (like size, modified dates, etc).

To use this you need D-Bus 1.3.1, it is nice to see these sort of performance improvements in Tracker. Great work Adrien thanks!

Direct access
Bastien reported a bug not so long ago about adding support for direct access to the databases via a library API. This week, we started a branch to get this work under way. While we do this, we are considering re-writing the libtracker-client API using Vala and improving the old API substantially.

Git branch management
Due to the high number of branches we create, I decided to do some sort of clean up. I created a script to list all the branches and relevant information about them to be able to email the mailing list and check if everyone was happy with removing old branches. I thought this might be useful to other projects. Here is the script I used:


if ! git rev-parse --git-dir > /dev/null; then
        echo "This is not a git directory"
        exit 1

if test $# -lt 1; then

git ls-remote $remote | while read LINE; do
        commit=`echo $LINE | sed 's/ .*//'`
        name=`echo $LINE | sed 's/.* //'`

        if [ -z $name ]; then

        case $name in
                shortname=`echo $name | sed 's@.*/@@'`
                if ! git log --max-count=1 --pretty=format:"Branch '$shortname' -- last commit was %ar by %an (%h)" $commit 2>/dev/null; then
                        echo "Your checkout doesn't contain commit `echo $commit | sed 's/^\(.......\).*/\1/'` for branch $shortname"
                        exit 1

This produces output like:

Branch 'album-art-to-libtracker-extract' -- last commit was 3 months ago by Martyn Russell (d1f1384)
Branch 'albumart-quill' -- last commit was 8 months ago by Philip Van Hoof (a397a0f)
Branch 'anonymous-file-nodes' -- last commit was 5 months ago by Carlos Garnacho (60658be)
Branch 'async-queries' -- last commit was 2 months ago by Carlos Garnacho (88358dd)
Branch 'async-queries-due' -- last commit was 10 weeks ago by Jürg Billeter (52634ce)

Thanks to Sven Herzberg for some of the improvements to the original script. Most importantly, the use of git ls-remote. This makes sure that local branches are not used which may have been removed in the origin repository.

Tracker Release Candidate 1

Today we released 0.7.28. We are considering this our last unstable release for 0.7 before we do 0.8. So long as there are no major regressions, this time next week, we hope to have our first stable release with the super shiny stuff we have been working on for over 6 months.

Using tracker-sparql
Recently I added support to list classes which we notify of changes in the database. This is generally quite useful and a common question on IRC:

$ tracker-sparql --list-notifies
Notifies: 23
   Continue reading →

Tracker 0.7.20 Released

Managed to get 0.7.20 out of the door. Not long now before we start 0.8 releases. I want to start doing this within the next few weeks if possible.

Tracker is looking great right now though. The core team has been exemplary in recent weeks.

Roll on 0.8 :)

Tracker + Totem

Bastien has been complaining that the Tracker plugin for Totem doesn’t work any more since 0.6. So I decided to see how quickly I could update it today. All in all, it only took me a few hours and here it is. You will have to excuse the crappy file naming and video tests I have to play with – normal users probably title these a bit better I think :)

On another note, we released 0.7.1 on Friday gone with some really nice fixes since the first release. We plan on doing another release this Friday too.

Tracker Update


So Carlos and I have been working on libtracker-miner for the last few months. Since tracker-store (formerly known as trackerd) is now handling all reads/writes from/to database and doing it much faster than ever before with a much more expressive language to query with (SPARQL), we had to merge the old tracker-indexer and parts of trackerd from the 0.6 branch into one binary that could crawl the file system, insert file specific metadata and call tracker-extract for file type metadata (for example: none “file” data, but actually data like image height, width, etc.).

As we had to do this anyway, we took the opportunity to refactor the parts we were unhappy with and to make libtracker-miner a library which other “data miners” could use. This gives the following things:

  • DBus integration for free
  • An API to find other miners both available and running
  • An API to get/set status, progress, name and description for each miner
  • An API to pause/resume each miner
  • Signals to know when all miners or specific miners start/stop/pause/resume/error/progress.

More recently, Adrien Bustany has been working on “bridges”, which in fact are the same principle, they are miners of data but for web applications like:

  • Facebook
  • Flickr
  • Twitter
  • etc.

We are working together to integrate this into the “miner” framework we already have set up in master right now and it is quite exciting to see integration in other areas than just desktop applications.

Additionally, Philip is making Evolution use the same miner API so we will have support for 3 miners as standard out of the box for:

  • Email data
  • File data
  • Application data


Formerly known as tracker-applet, this has been refactored by Carlos recently to work with the new miner API too, so now you can see (much like the network manager) a list of miners and their state/progress. It also allows pausing/resuming of ALL or single miners at a time which is very useful.


The tracker-preferences application was also really out of date. The whole configuration system has changed since 0.6 so we decided to use Vala and GtkBuilder to build the new dialog. This dialog only services tracker-miner-fs preferences right now because they are really the only settings that make any difference to the user at this point. There is some polish that is needed here, but it looks good so far:


0.7 Development Release

The current roadmap is mostly done now with a few exceptions which we have decided to not worry about for the 0.7 release. Next Friday we plan on doing this release now that most of the UIs are in reasonable states and people should be able to start using it normally now all the big features have been integrated. This has been put off by 2 weeks already but we don’t want to delay any further. So look out for a new version of Tracker next week!