I voted for "speed", but really the most important thing for me is reliability, meaning if I search for something and the search tool cannot find it, then I know it isn't there. Neither Beagle nor Strigi accomplish this at this time. (I have both tools set up presently.) That means I may give those tools a shot when I'm looking for something, but if they don't give me an answer I keep looking with locate, grep, find etc and usually find what I'm looking for. What is lacking is both completeness and up-to-dateness of the index (files not indexed) and data extraction (some words that a human would say are in the indexed files are not properly tokenized, e.g. for some PDF files).
I realize this may be difficult to accomplish when there are also conflicting criteria, such as not bogging the system down with indexing, but since you asked, there you have it.
You've got a really good point. When I'm using MacOS X I'm always amazed how fast the file index is up to date. Almost instantly. I believe they notify the indexing service (spotlight) when a file is saved, because it's just always there.
The speed + indexing without delays is actually the main reason I've become a fan of desktop search (The MacOS X way that is). Before it gave me feelings of some crappy Windows' indexing service that eats CPU power and doesn't speed up searching at all.
If KDE Desktop Search is able to accomplish this it will be a huge added value. Otherwise I'd probably disable it. ( I've disabled beagle too because my load jumps up to 4.0 when mono apps are running :-| )
The MacOSX tool sounds great if it's that seamless, I do find Beagle a bit of a CPU hog and the Windows one is just rubbish.
But something they all lack, and that I'd really like, is integration with every application. Being able to click on a button and search is great, but it would be much better if KMail used it when searching for emails, if Konqueror can use it to save smart folders, and if other applications can think of interesting things to do with contextual data. I liked Scott's original ideas for KDE4, I just hope somebody has the time and vision to go beyond "use this app to search for your files".
I also hope the UI is as simple and usable as Beagle and Spotlight!
I voted for this also, but it's also the bit I'm least worried about Strigi achieving.
KDE has excelled at integration over and above any environment that I know of for a while now. KParts, KIO, DCOP (DBUS now?) etc. etc. have seen to this and Strigi will be able to utilise all these and whatever else comes in KDE 4 to integrate nicely.
I'm most worried about speed and reliability, and as the above post points out I haven't seen anyone by Apple do this well yet.
Speed, good sense, heuristics => usefulness.
When desktop search will become an essential and natural part of life (like Alt-F2 gg:), then it would have reached its goal.
I totaly agree with last comment. With bigger and bigger hard drives the first one for me would be, without a doubt, "Speed in searching and indexing".
I voted for "integration in all applications", but really, none of these cover what I was hoping to see. The most important thing for me is what GNOME Dashboard once did: live hint-sharing between applications, so my whole desktop knows what I'm currently working on, and suggests useful hints (for example, kontact provides contacts and events, kopete provides recent conversations, etc., all to one sidebar, in realtime from their own storage facilities, rather than from a pre-generated index that is out of date and takes up lots of resources.
I *think* this is what Tenor is aiming for (right?)
As far as file searching goes... I have ONE request, that other tools (grep, htdig, etc.) have yet to make easy. As my desktop of choice is KDE, it may be something that only KDE can help with. That is: can we have some way find specific pages/sections/slides in PDFs and other big documents, and open directly on those? If I could search for keywords in my files (or on a lan webserver), and open PDFs at the page that's most relevant, it'd be a great workflow boost for me, and probably a lot of others :)
Use dbus as ICE equivalent, tunnel DCOP though dbus, sync dbus exactly to DCOP semantics and port DCOP API to map to D-BUS, write a dcop/dbus bridge layer, create a new parallel API similar to DCOP or combination of above. Timeframe would be KDE 4.
This place is a blogging platform for KDE contributors. It only hosts a fraction of KDE contributor's blogs. If you are interested in all of them please visit the agregator at Planet KDE.