Looking for a "desktop search" app

Question

I am using kde, and I am searching for a desktop search app that uses a database and searches within common filetypes.  I've tried a couple so far, and haven't found what I'm looking for:
kerry/beagle:WAAAY too much bloat; creates ~2gigs of logs per day, once crashed and started loading my filesystem with useless data.
strigi/clucene: tried it, didn't really work, settings kept on resetting to default.
I am looking for something that doesn't have heavy gnome dependencies.
Any suggestions / what are you using?

Answer 1

Next one...
RECOLL
Depends only on Qt and xapian-core (from community).
All its dependencies are in official repos except for libtextcat and xapian-core (both in community, however).
Src download is 850Kb, and since the package in [community] is outdated, I built one of my own:
Targets: recoll-1.90-1 
Total Package Size:   0.9 MB
Total Installed Size:   2.6 MB
Backend:
It also uses the xapian backend.
It can run as a daemon that uses FAM or inotify to provide continuous monitoring/indexing, but the docu says it's probably better to run a cronjob.
While Pinot was using an xml config file, Recoll has a very detailed set of plaintext config files and it can maintain several indexes in parallel (e.g. one with monitoring and one with cronjob indexing).
plaintext, html and email are handled internally, and for other file types you have to resort to external utilities again, of which unrtf is in community, pstotext is only in AUR and I didn't find id3lib/id3info at all.
Again, extension is possible. Here you have several steps which take resources and are slightly more complex to set up than in pinot, but probably allow more fine-grained tweaking: you have a mimeconf configuration where you associate mimetype and filter ('application/pdf = exec rclpdf'), you have an assortment of filters ready in /usr/share/recoll/filters, you have a mimemap config file where you can associate filenames/endings and mimetypes (Unfortunately it uses a different format from e.g. mutt's mime.types, but it also includes special, recoll-only settings - like exclude certain files from indexing or associate files with a certain name with a different mimetype when they're in another direcory)
Search:
Recoll has its own (qt, non-kde) GUI and is only adressable therewith, thus not integrated with any of the other frontends. (Export for pinot, which should be able to access recoll's xapiandb...)
You can use proximity and phonetic search, stem expansion and glob/regex expressions. And you can specify search criteria by metainfo (author, subject, keywords). AFAICT, Recoll does not (yet) understand queries that conform to Xesam specs, neither RDF.
Recoll remembers the last few searches that you performed. You can use a combobox to recall them. However, only the search texts are remembered, not the mode (all/any/file name). (Also documents actually pre-/viewed are remembered.)
Typing Esc Space while entering a word in the simple search entry will open a window with possible completions for the word. The completions are extracted from the database.
Double-clicking on a word in the result list or a preview window will insert it into the simple search entry field.
Search results formatting can be formatted freely with a qt-html expression per default they display several occurancies of the search term along with their respective, (very) limited context. They can be opened either with a mimeview configuration similar to the mimemap file from above or with xdg-open. Or you can view them in an external preview window (which has an incr. search feature). (You have icons for file types but no thumbnails.)
Experiences:
System seemed to me to not be so very sluggish when it did the indexing.
The same directory with ~3100 files, mostly pdf, a few doc and html files, weighing in at 1.5Gb. was indexed in
real    15m13.378s
user    8m47.466s
sys     3m33.439s
and additional stem databases for german and french took another 50 secs.
du -h:
14M     ./xapiandb/stem_english
15M     ./xapiandb/stem_de
13M     ./xapiandb/stem_fr
236M    ./xapiandb
246M    .
Recoll UI started up quickly and results were returned almost instantaneously. (Not a complicated search expression, tho) I have not yet tested for complicated expressions or a test search for a term that occurs only rarely, so I cannot tell if the small db size has its drawbacks.
So these are still open questions:
[*] monitoring-mode performance impact?
[*] search expression options: RDF ?
[*] search results: how accurately?
[*] attitude towards Xesam and offering services to other frontends?
What I find interesting is its configurability, and the small db size (well, as of now I have only pinot to compare it with, so maybe it's not so extraordinary after all).
(Next will be Tracker...)