KDE Plans 'Google-like' Search Capabilities

CoolFX writes "Developers of KDE have announced plans to simplify searching for files on the open-source Linux desktop environment by adding a Google-style search feature. The next version of KDE, which will either be called 3.4 or 4, is expected to include the new search feature... Aaron Seigo, a KDE developer, said the community has already been discussing and writing code for the new search engine at the KDE Community World Summit."

Comments

Re:How will this work?

[barcodez]

Now, how is this going to work? First off, when I do a search on google there are dozens if not hundreds of PC's involved in various aspects of the search. I get my results in under a second. My computer - although fairly decent itself - is only a mid-tower. There is no way I can support even one PC to assist in searching.

Having played with and done some work on the open source Nutch search engine I know from experience that you can return search results from ~10,000,000 pages in much less than 1 second on a mid-range desktop. It's all done with indexes in much the same way as relational DB have been doing it for years.

Re:Actual Conference Site

[Geiger581]

Relevant presentation overviews here and here.

Google is fast, but not the best for the desktop

[orasio]

What I would like to see, is the speed of google, adapted for the user. The web metaphor justifies going to a text-box, and hitting Enter, but I'm not willing to do that just to look into a page. That's why incremental search is so successful. Maybe it would be nice to implement better metodologies, that have already been proposed. Just because the Google interface is good for the web, it doesn't mean it's good for the local machine. Maybe it would be nice to go to one of the sources of recent improvements (incremental searching) and implement what he suggests, in its full form.

from Jef Raskin's
The Humane Interface


Part II: WHAT INTERFACES SHOULD HAVE

A useful starting set of solutions to the problems outlined above includes

* A better text search methodology, effective both within a local document or system and with respect to extremely large data spaces such as the web
* A method of eliminating all modal aspects of the basic human-machine interface, a method that is readily learned by newcomers and which is habituating
* An improved navigation method, as applicable to finding your way around within a picture or memo as within a collection of images, documents, or networks; a method which makes use of inborn and learned human navigational skills
* A set of detail improvements to some existing mechanisms that make them consistent with the goals and principles of the rest of the design.

Better text searching requires that the search be extremely fast (the next instance appears within human reaction time), interactive at the typed character (or spoken morpheme) level, and not based on dialog box interaction. You should be able to change the pattern (what you are seeking an instance of) at any time, including during a search. The results should be shown in context and not as a list of documents or sites. A search mechanism that is sufficiently fast and powerful also can serve as a cursor positioning mechanism in text. Such a cursor positioning tool can be significantly faster than graphical pointing devices and can unify local and internetworked information retrieval.



-------------

Well, maybe KDE is not the right project to do that, and I should shut up and help with the project Jef Raskin himself has started, and is slowly being developed, The Humane Environment .

Re:Like Spotlight?

[sultanoslack]

Well, this idea was from my talk at the KDE developers' conference. I actually submitted it just a few days before Spotlight was announced.

Similar, but more pervasive and based on some pretty different models for data collection and ranking. Unfortunately this article hits at a time when there really isn't any reasonable resource for what the plans are, but that should show up somewhere on public mailing lists in the next week or two.

The important differences are that it will be based on a generalized idea linkage inside of the desktop and that it won't be a stand alone tool, but a framework that can be used for having search-centric UIs throughout the desktop.

It was mentioned that this is similar to KMail and JuK at the moment; while I wrote the search code for both of those and that got some of the ideas rolling in my head, this is a pretty big jump from both of those.

Re:Beagle?

[OmniVector]

you basically got it right. i just wanted to chime in on one thing. i think apple's solution with tiger is rather inventive. basically there's a low-level system api that hooks into the file system so that changes can be tracked. whenever a file is moved, created, renamed, or changed an event is sent upwards to the mdimporter system. mdimporters basically are little programs that implement a single function which takes a filename, and returns an NSDictionary (i.e. a map, or hash). the mdimporter can register itself with the system for certain file formats.

the coolest thing about this is, you get live updates. so for example, if you have the spotlight search open in the top right and you've searched for "kansas," you can then go into a microsoft word doc and type kansas, then save the file. the file will instantly appear in the spotlight search.

i don't think linux has a solution just yet for live-updates, which is important for the integrity of the indexed data.