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:

Leave a Reply

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

Comments are closed.

  1. Jamie McCracken says:

    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 says:

    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 says:

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

  4. Giacomo says:

    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 says:

    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 says:

    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 says:

    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 says:

    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 says:

    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 says:

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