Slashdot Mirror
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."
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.
----
Relevant presentation overviews here and here.
I've been waiting for a decent search engine app for the desktop - for both Linux & Windows. Grep is fine, but it's not always the best tool for the job. Alta vista had a decent app for the Windows desktop a few years back, but I don't know if it supports newer Windows OS's. (And not having RTFA, I don't know if my example even applies.)
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 .
Yup ... Google Deskbar
not to be pedantic (or a karma whore) but 'google' is not a word. Googol, however, is a word representing the number 1 followed by 100 0's.
This signature is a waste of 42 characters
No to be even more pedantic, but as the parent noted, the action of 'googling' or 'to google' was indeed added to the last revision of the Oxford English dictionary, and therefore by definition it is a word.
#include "disclaimer.h"
Gnome already has similar plans and looks good alreadyt tp://www.nat.org/dashboard/
http://www.gnome.org/projects/beagle/
h
This problem has been solved by GNOME Storage. It is not very GNOME Dependant, it could be utilised by KDE without problem (write KIOSlave equvialent of gnomevfs module and even obsolete apps can use it).
:wq
Redhat's business model is:
That's they're business model and they aren't changing it. They're just focusing their market. In the desktop market, parts 1&2 don't allow them to compete with MS. The features needed to compete don't exist in the OS, and RH doesn't have the man-power to add them in itself.
In the server market, which RH is currently targetting, they can very effectively compete. So RH is expending it's limited resources to help in compete in this market instead.
KDE's "enhanced browsing" has allowed this feature for years. In any Konqueror window or by pressing ALT+F2 for the "Run" dialog box, you can specify a search provider and keywords.
...and making more is incredibly easy: just go into Control Center and configure enhanced browsing.
Examples:
imdb:Rob Malda (Internet Movie Database)
gg:lucky (Google)
dict:sphygmomanometer (Merriam-Webster)
For more information, click here.
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.
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.
- tristan
That's partly how my system (POPsearch) does it. The search ranking is determined by a file's popularity.
Somebody else suggesting just using "find / -exec grep -H pattern {} \;" but that would be a terrible solution. It isn't indexed. To find a unique pattern, it forces a scan of half the drive on average. Come on. Looking at half the data on the drive just to find a specific pattern that exists in only one place? Why not just jump to the place it's at?
This is what indexes are for.
'goo-gleh' (noun)
googler ('goog-lay'), v.t.
When was escalator ever a brand?
:) Have a look at the third hit, esp. the last paragraph ...
Did you even bother to try googling for it??
"Over the years, Otis dominated the escalator business, but lost the product's trademark. The word escalator lost its proprietary status and its capital "e" in 1950 when the U.S. Patent Office ruled that the word "escalator" had become just a common descriptive term for moving stairways."