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."
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.
Aside from the logistics problems, where the heck am I going to get the pigeons anyway?
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
Just as long as they don't call it Koogle.
Not only for KDE's but also googles? For example, will they scan inside my oowriter doc for the keywords I'm searching for? What about email? If not, I don't really see the advantage over things like find.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
Who said they're adding it to the windowing environment? They're not adding it to KWin.
It'll be part of KDE - where DE stands for Desktop Environment. KDE is much more than a window manager, it's an entire desktop system, so this is the perfect place to add it.
Kornhorn.
What exactly is a Google-like search feature? I'm assuming they mean something like Spotlight.
So, what's the deal? I actually RTFA'ed, but did I miss something? What will KDE do that ht://Dig and mnogosearch and the like don't? User-friendly setup and use, I suppose.
the spotlight is really on KDE right now.. hmm..
The war with islam is a war on the beast
The war on terror is a war for peace
Somebody wake me up when this has been integrated with various useful reiser4 plugins.
doesn't work unless you remember to name files consistently.
Relevant presentation overviews here and here.
It's a whole system, the Google/InterNet/Authors... you can't have parts of it standing alone.
--Mike--
Please somebody tell me that they will cooperate with the Beagle project on this and don't reinvent the wheel yet again. It would be a real pain in the ass to have too indexes wasting your hd space which basically do the same thing.
That's the main question ... in my opinion features like this should be developed as close to the FS as possible ...
And if they want to create something like this on a higher level (meaning FS independent and all that stuff ...) why not just create a simple GUI for locate?
I mean it's clearly a similar indexing feature and IMHO the work involved shold rather be invested in future FS development ...
Never underestimate the power of idiots in large groups
If you don't want to use it, it will likely be possible to disable it. Voila, no bloat. On the other hand, I've always wanted a good way to search within documents / metadata on Linux (KDE in particular) that's integrated with the environment. And yes, before anyone mentions it, I do know about grep and use it daily in my coding but it's not the same. grep can't search through formats other than text, of which there are a lot of (OpenOffice, KOffice, etc formats come to mind). Also I'm sure this feature will be able to utilize KDE's Kfile framework to allow you to search for different characteristics of different file types. Far from being bloat, I think this sounds USEFUL above all. Going out on a limb here, but I think if you combine this with the up and coming ReiserFS4 and its plugins and metadata support, you could have a *really* powerful way to organize your files. But hey, if you don't want that, don't use it. It is OSS after all, there's plenty of choices in desktop environment and applications.
Don't tie it to KDE! Make it KDE independant!
Make it so it can be used from the command prompt. Make it so it can be used from GNOME. Make it so it can be used by other non-de X apps. Make it so it can be used by Apache, or Samba, or anything else running under UNIX.
Even better, make it compatible with Spotlight. The search API's are diagrammed at a low enough level that it might be a part of Darwin and not Aqua and thereby released as Free Software. But if it isn't, Apple is pushing Spotlight very hard and they want developers to get behind it and use it, so the specification should be pretty open and reproducable.
Okay. I think this is a great idea. Everyone that has seen how windows will work post-longhorn, how OSX works today, can see that the filesystem hierarchy metaphor is, thank god, on its way out.
But, this has to be done well. I mean, this has to be not desktop implementation centric, but filesystem/kernel centric. That is, in order for this to work really well, you need a filesystem that can categorize files and search through them efficiently (almost like a database).
Reiser4 may be able to do this, WinFS will do this (will have a mssql core), and if this all means a neat kde interface to locate or an extra indexing service, it will suck on linux.
So. It would be really cool if they put it up in freedesktop.org as an RFC so that the whole community may get involved. This cannot be the sole effort of KDE if it is to work well.
NO SIG
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 .
It actually points out that rather than just searching files by name, the new search would let you search something the way you search on google...
i.e. I want to configure my ftp server, so I type in "configure ftp server" and it returns an appropriate help document, or I search "foo" and it will search through my files for that phrase.
that's how I see it working, in any case, not just "find -name filename" because that would be reinventing the wheel...that's what slocate and find are for, or "find files" on the K menu for gui stuff.
it is quite pretty--mmm, gradients--but every link on the page is light brown on white, and article title is in a gradient, which is dark enough at the top but winds up being white-on-light-brown by the bottom. White + light brown = low contrast. Maybe my monitor's a bit bright, maybe my gamma is off, or maybe my eyes are bad, but like you said, I'm hardly alone. No sense mentioning people with actual visual disabilities.
Even Apple, supposed masters of great design, recognize a loser when they see one--after all, they eventually dumped that round mouse, right?
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
There is a nice whitepaper on the future of reiserfs and other filesystems for Mac* and Win* OS. The question is: at what level do you need to implement efficient search capabilities ? Filesystem ? Userspace ? Both ?
You would think, but these are the same admins who a) don't bother to check for dupes before posting and b) refuse to make valid HTML in the first place. I mean, c'mon, the work has already been done.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
"Searching for files is fundamentally a user interface feature"
/keyword/"unix file search"
No, programs do it too.
"What other project could it possibly go under?"
It would be nicer if it were part of the filesystem. "Everything is a file" is a powerful concept.
find
Why "google like"? What separates google from other engines is its page-rank algorithm. I hardly think KDE is applying page-rank to local disks (wouldn't make sense). So then, the headline should just read "KDE plans search capability". Whoopdy do.
or BBN had some interesting natural language parsing projects going in the early 90s, but google has shown that "semantic nets plus keywords" winds up being a better way to search hyperlinked data. The problem that I see is that my hard drive isn't hyperlinked, so I don't really WANT a google-like search capability.
--
I always wanted an iPod how about you?
Duke Nukem: now with Google-style weapons lookup!
Norton Antivirus: Now with Google-style virus lookup!
AutoCad 2005: Now with Google-style component lookup!
Crazy world. Next thing you know they'll be hooking up lava-lamps to build machines.
Yup ... Google Deskbar
From the article:
Paul Salazar, the European marketing director at Red Hat, said his company has chosen to focus on Linux on the server rather than on the desktop, due to the fact that it cannot compete with Microsoft's research and development budget.
This is a pretty odd statement coming from a corporation with all its eggs in the Open Source basket. One would normally expect a company to believe in the superiority of its chosen business model.
Surely it's an article of faith that the "virtual equivalent R&D budget" of the FOSS community is hundreds of times greater than Microsoft's corporate R&D budget, and our R&D manpower is thousands of times larger. What FOSS lacks (comparatively) is strong product focus, but many would say that that is a good thing.
Is RedHat having second thoughts, or was this just an unfortunate individual comment from a marketting droid?
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
To be honest it looks like a gimmick. The reason for the commands in Googles search is because your narrowing down literally billions of pages of crap. You dont particularly need that flexability with an O/S search facility. I have found pretty much all I need with current functionality. Whats more important is the speed of the search being attempted but they are building on top of the standard search facility. If anything it may even slow it down.
As for its comparison to WinFS if MS get it right. Which is more likely than many would have you believe (especially cause they get bitched at with good reason for there current facilities.) WinFS is built from scratch and will likely be superior to this project. If only in the way that it far surpasses there current search.
Well, thank you for your insight.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
Yes, I'm a little unsure why they mentioned "google like" search. My point was that there is a place for more advanced search than just find.
Well. I dont think it should be as close to the files system as possible. .ps.gz files and scan them, using the newest pdf library to index pdf files, read the compressed staroffice format, ect...
I want to search engine to index my html files, expand
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
That whole text searching, no-dialogs blurb sounds a lot like The Remembrance Agent, as it plugs into emacs.
I had started coding up a Java-based front-end which monitored the X clipboard buffer, but didn't get very far - lack of time. What little code I did write can be found here.
--The more you know, the less you know.
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
The article in N&T is based on ideas by Scott Wheeler (and Till Adam, and Aaron Seigo and others). See Beyond Hierarchical Data: Search and Meta Data as Fundamental Interface Elements, Scotts lecture on query-based interfaces at aKademy.
"Google like" here means just "searching", but the result will in fact be more like WinFS than Google in that it is using file data and file metadata to index and find things. Interface-wise expect more quicksearch bars like the one in Kmail 1.7 (KDE 3.3.0, Till Adam) and JuK (Scott Wheeler).
See also a Blog entry of mine (german language) in the same vein.
This idea, while it sounds neat, also suggests that it's trying to keep up with the Spotlight feature of OSX Tiger and Longhorn's whatever-you-call-it. I'm not at all bashing the project, but what I'm curious about is why we haven't seen Linux leading in more advanced features, stuff that would be really advanced out-of-this-world concepts that will, eventually, someday, really advance our idea of computing.
I'm sure that it's being done to some extent, I would think that if you're a Phd doing advanced windowing research, you'd want your platform to be Linux so that you can code it the way you want.
While Linux is the natural choice to use for the breakthrough concepts, I really don't know of any. While Linux has *great* technology, and is definately an OS par excellence, it feels like it's more-or-less keeping up with the Joneses, instead of leading in new ideas and technologies. It's said that everyone waits for Apple to come up with something so that it can be copied. Well, why wait for them?
Maybe there isn't as much research going on as I would think (not being in Academia), or it's more of the "faster-smaller" variety, but when the "next big thing" happens in computing, I hope it is on Linux *first*.
IMHO, KDE should be moving toward better functionality and ease of use for the desktop then writing Google into it. I understand the desire to dominate the world, but I don't think the basics are quote covered yet.
:)
The functionality of the K-apps and how loosely they integrate (and don't integrate with anything else) is at about MS Office 95 level.
I see searchings importance on a scale of 1 to 10 at about a 3. Most users I know have everything in one folder, maybe a couple of nested folders and that's it. Not too hard to find stuff if there's one or two places to look.
-m
PS: Was there an article to read?
http://www.invisik.com
This is a classic case of journalists picking up on keywords (Google) and jumping on them. The article had us screaming with laughter here at akademy the KDE conference. The point is just that it is easier to find things on the web than on your desktop. Files and settings should use search because they have outgrown the heirachical setup. However this is just vapourware for now .
By the way the next version of KDE will be KDE 3.4, branching to KDE 4 when Qt 4 beta is available at the end of the year.
Transcripts from all the talks I went to are at http://conference2004.kde.org/sched-devconf.php.
Jonathan Riddell
"KDE goes for IPO selling 145,233 shares at 1059,342euro each giving KDE a higher market capitalisation than Microsoft and AOL combined."
* note: not actually random, void where prohibited...
This is where file storage, at least at the level where users interact with it, should be headed. I think file managers should be more like Google.
/home/user/photos/Christmas should be distinct from /home/user/Christmas/photos. I should be able to type in either path and get the same result set.
Hierarchical trees are horrible ways to manage data, especially if it's a bunch of data that can be classified multiple ways and you typically won't remember everything you save.
There's no reason why
This would solve a lot of the hassle of organizing files. The only choice I'd have to make is how specific I want to get when choosing file names and directories.
Indexing of file contents is an added plus, but not even necessary for a huge gain in organization.
If moderation could change anything, it would be illegal.
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.
Let's see, after GIMP, GNU, Ogg-Vorbis, and all the other really badly chosen names for good software, what will this one be named?
:)
Possible names that will sound cool only to the geekly-enabled:
- Dingo
- Dingus
- HeadCheez
- Buffy
- MK-47
- FUALL V56.34
- All-seeing crystal of Gompfor (unique artifact)
- STDcipher
Seriously, someone call a professional here...
Simple solution: put all your files into your public_html folder!
KDE is an open project. If some people want to work on a new feature, how does that have a negative effect on the rest of the environment? It's not like programmers are being "stolen" away from what they are doing to work on this -- it's open source for crying out loud!
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.
Apple did it by putting into place an extremely clever and elegant hack. MS is attempting to do it by rewriting the entire filesystem.
It's the classic agile and fast mindset vs the monolithic authotarian mindset.
evil is as evil does
Better desktop searching is welcome, but how about something that imposes some order and structure on the data on my machine?
Not in terms of a filesystem, and not in terms of a tool that indexes everything and points a search engine at the index. Rather, I want something that overlays all that and imposes structure and organization on the information and knowledge that is recorded in all the those data.
Having done that, give me the tools to browse and manipulate it.
Gnome's Dashboard seems to be sniffing around the edges of this notion. But I'm thinking of something more significant, something that might potentially represent the user's concept of the machine, relegating filesystens, files, and data formats to lower and less relevant levels.
I.e. computer users do not need to be aware of the actual structure of their hard drive, or how their chips and circuit boards operate, because the OS and other software abstract all that out of the way. Why not bump it up?
-- Slashdot: When Public Access TV Says "No"
'goo-gleh' (noun)
googler ('goog-lay'), v.t.
shouldn't that be ... Duke Nukem: *coming soon* with Google-style weapons lookup!
peterrenshaw ~ Another Scrappy Startup