GtkSearchEngineTracker

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:

10 comments ↓

#1 Jamie McCracken on 12.07.10 at 3:34 pm

I would make filename matches appear first in the list but include FTS search results afterwards just in case. I guess this can be done easily by making filename hits have a much higher rank.

just my 2p FWIW

#2 mr on 12.07.10 at 4:11 pm

Jamie: Hi :) – we could do that but then we would have to filter duplicates somehow and it gets messy. The FTS side of things already considers title or filename as quite a high ranking attribute, however, if you have a file with “foo” in several other bits of metadata than the title, it rates higher and is shown first. Ratings are 0-10 at this point, it might make sense to really bump the title up so it has more presence.

#3 Karl Relton on 12.07.10 at 4:27 pm

I use FTS in the chooser all the time, and would not like to see it go!

#4 Giacomo on 12.07.10 at 4:28 pm

I know this is usually frowned upon, but wouldn’t this be something that should be enabled/disabled on-the-fly through a checkbox (for example “Search also in the files’ contents”, defaulting to unchecked)?

#5 jared on 12.07.10 at 4:58 pm

I would prefer content of the file as (personally) I do not always do the best names but my content is solid – and that is what I search on.

#6 mathw on 12.07.10 at 5:09 pm

Maybe make it runtime configurable to do FTS or filename-only, and let the user invoke a full-text search if they need it?

#7 Bassam on 12.07.10 at 10:16 pm

One thing that would be cool is to enable searching based on tags – tracker supports tagging files, and this can be done in nautilus currently, but I haven’t found a way in gnome to search for files based on tags in any of the gui search tools.

#8 Peter on 12.08.10 at 2:06 pm

It would be useful if the base tracker (0.9.30+ AFAICT) didn’t depend on both GTK and QT. Possibly have dual UIs that can be subpackaged or something. Its not great on space restricted devices.

#9 mr on 01.19.11 at 11:05 am

I really want to add that, it isn’t trivial to do it in concert with regular searching though when talking about per category searching. Since tags are considered a separate entity, you essentially have to combine $category with optional tags that may exist. It is doable though and I mean to add it soon.

#10 mr on 01.19.11 at 11:07 am

Giacomo: Searching using FTS is done in the first view, the second 2 alternate between filename and content.