Alexander Larsoon (Nautilus maintainer) has a new Nautilus search implementation with optional Beagle integration via plugins. It is now possible to save the searches as smart folders.
Nautilus Search Ready to Run
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The file manager needs a good way to search *easily*. This appears to be a good start towards that goal. The UI definitely needs some work – I’d expect the “bar” to look a lot more professional come official release, and the additional search refining to take on a more visually pleasing appearance… but apart from that, great work to those involved! Finally, beagle nautilus integration
http://www.flickr.com/photos/62853542@N00/71247144/
Real men do not need anything more.
period.
You just don’t get it. If I knew the name of the file I was looking for, I probably wouldn’t bother searching for it, because I’d know where it was.
Real men obviously prefer inferior methods of search. Stop trying to justify Linux’s relative backwardsness.
I really think he might have been joking! But in your case you’d substitute “*” for <x> and put your search term in <y>. Or use grep -R directly.
CLIs being arcane to use seems pretty standard across OSes to me – out of interest, how does one do the equivalent operation via the Windows command line?
Yeah but do I really want to sit there for 10-15 minutes while grep plows through 200 GB of data? I’ll take an indexed system like Spotlight any day over primitive grep. Grep has its uses, and being a system-wide search tool is not one of them. That was my point.
As for Windows, I believe the grep equivalent is “find”. Try “find /?” — it should give you some information.
If only GNOME devs had the manpower, resources, time of Apple and Microsoft devs. I find it amusing that you should compare and you seem to have all the answers, care to contribute?
Can you convince Steve Jobs to to give his OS-X or spotlight code for free to GNOME?, no I didnot think so. You sure know how to compare apples and oranges dont you!
You sure know how to ignore what you’re reading! Here, let me explain it to you …
Original poster: “Indexed searching is for pansies. Real men use grep.”
Me: “Grep is primitive. It’s not a system-wide search tool. I’ll take Spotlight any day.”
You: “OMG GNOME devs don’t have the resources to develop a Spotlight-work-alike.”
Uhh … ???
Go back to school. You fail English 101.
Where’s the need to wait?
Linux is getting search features much like Apple’s spotlight, beagle for example has been mentioned on OSNews for a while and the one article with videos showed it reacting to changes to the file system almost in real time (there was a second between the file being changed and it’s appearance in the search results).
From what they showed of beagle it looks like it can either already be used from the command line, or at the very least can be used thought an API to write a command line application if you don’t want to use graphical tools. The description of this article even mentions that Beagle can be used in this Nautilus search feature through plugins, so I don’t see why you would think there’d be a long wait between starting a search and getting results.
Arrrrgh. This is like the 5th time I have to explain it. People, please … read the thread before replying to messages. One guy suggested that all anyone would ever need is grep. He suggested that grep is as good as any system-wide indexed search tool.
I said it wasn’t.
That is all.
PS: Yes, Linux has Beagle … but Beagle is nowhere near production-ready from what hear. Good effort, though. It’ll go somewhere.
sort of like this..
cd
dir “filename.extension” /s
(Ooops, wrong reply to the wrong post.)
Edited 2005-12-08 05:15
Are u implying that noone ever recalls a file name without knowing where the file is located?
I Guess Apple has relative backwardsness as well then. And windows is relatively going backwards with the combo of winfs and search tools.
I dont like to pin u for trolling but this time i dunno. File indexing/search IS indeed very useful, and most of the big OSes are realizing that.
I never said it wasn’t useful … I use Spotlight all the time.
What I said was that “grep” was a cheap and inferior “alternative” to real indexed searching. The parent poster suggested grep was good enough, when clearly it is not.
What I said was that “grep” was a cheap and inferior “alternative” to real indexed searching
Try to be less trollish with your comment. “grep” is surely not cheap, and not inferior to real indexed searching. You are comparing apples and oranges. grep is not an indexed searching tool.
Stop using stupid words like “cheap” about a program that can do far more powerful things than indexed searching.
That’s actually indexed searching that is an alternative to grep, given that you can do what indexed searching does using grep with other tools (find, locate, …).
Okay, let me get this straight … are you trying to tell me that grep/find/locate are equally-superior tools to a real indexed search system?
Seriously?
Let’s compare —
Indexed Searching: Results within seconds, contextual results, results in many forms with much information
Grep searching: Results take 1-30 minutes depending on amount of data, results in the form of just relevant lines of text from a file
You’ve got to be kidding me. 😐 Again I’ll repeat it: Grep wasn’t designed to be a system-wide search tool, and it performs badly as one. Don’t be fitting a square peg into a round hole.
Good lord, what a humourless bunch we have in here today. I’d just like to draw the attention of “Linux is Poo” and all the other anonymous posters to the fact that no-one thinks find/locate and grep are suitable replacements for a full desktop-search implementation. It was just a typical computing joke. If you’ve ever looked at it on Slashdot you’ll see the typical format
Story: New app X is launched
Comment
X sucks, real men use [insert ridiculous archaism here].
And then people either laugh, add to the joke, or expand on the [ridiculous archaism] to provide some extra information. After all, as I said elsewhere, when you’re working on remote machines, the commandline may be all you have to work with it, and then such ostensibly ridiculous archaisms can actually come in handy.
Seriously lads, switch to de-caff and grow up: this is exactly the sort of nonsense that gives OSNews posters a bad name.
What’s so special about names anyway? I’m can much easily remember how things looks and how the context looks so I can find it later. Names, I’m not so good with.
It usually takes me a year or two to learn the neames of all my class mates/colleagues, but only about a day or two to learn to find my way around the school/work place.
So I think a way to quickly navigate a stable space would be more welcome than a search for names…
You just don’t get it. If I knew the name of the file I was looking for, I probably wouldn’t bother searching for it, because I’d know where it was.
Real men obviously prefer inferior methods of search. Stop trying to justify Linux’s relative backwardsness.
Jeez if you knew anything about the commandline you would notice that you can put wildcards after the iname option if you remember _part_ of the filename or * to search all files (it’s also case insensitive) and the grep command will look in the file for a search string (or regular expression).
So he’s searching the file content as much as on filename !
Of course he forgot the ” to escape the ; and I would also use the -l option with the grep to print ony the names of matching files.
And that’s supposed to be just as good as Beagle/Spotlight/WinFS/etc?
Yeah, I’ll grep through my data when I have nothing better to do.
And that’s supposed to be just as good as Beagle/Spotlight/WinFS/etc?
Nothing beats Spotlight! But it has it’s use, especially because you can build complex regexp’s and you can do all kinds of cool stuff with those if you know how.
Yeah, I’ll grep through my data when I have nothing better to do.
I only grep through other people’s data, it’s much more fun 😉
I grep through other people’s source code looking for naughty words. 🙂
RE: find /path -iname <x> -exec grep <y>{};
Real men do not need anything more.
period.
Oh how I love that Holier Than Thou-attitude. That’s the spirit! That’s exactly what’s going to make people switch from the fiery pits of Windows-hell they’re in today to a nice, free desktop OS.
Or
find /path | xargs grep -i <query>
Xargs is faster than -exec!
http://sunportal.sunmanagers.org/pipermail/summaries/2005-March/006…
or
find /path -iname <x> -exec grep -i <y> {} +
If the users drive you away from a platform, you’ve got bigger problems than productivity. I mean, if the user community is what’s keeping me on Windows, I must be a masochist.
Actually, I’d say real men use: locate <x> | grep path | grep <y> {};
It’s amazing that no-one ever thought to simply extend locate and updatedb, it’s a fantastic little tool.
It’s amazing that no-one ever thought to simply extend locate and updatedb, it’s a fantastic little tool.
There is a KDE IO slave for locate, see http://kde-apps.org/content/show.php?content=17201
And yes, it’s great for what it does.
stop post stupid alternatives
Desktop Search is not intended to file names
with Beagle backend you can search inside different
file types
pdf html doc oo c c++ python mp3 ogg vorbis txt xml
jpeg png and many others hence nautilus-search is much more powered than esoteric shell commands like grep.
With respect, Mr. Angry Anonymous Person:
1) All the examples above have searched filenames, paths and contents, not just filenames.
2) The original poster was making a joke
3) Myself and some other expanded on that joke a little, providing a bit of information about the Unix commandline that some people might find useful
4) If you’re working on a remote server, and it’s not possible to start an X or VNC session, find, locate, and grep are all you have to work with, making this snippet of commandline knowledge beneficial.
Mainly however, I just can’t figure out why you’re so angry…
No need to rehash the arguments, but it doesn’t seem like Red Hat is ever going to ship Mono. Thus no Beagle backend for this on a RHEL or Fedora box. So what is Red Hat planning for search? Larssen mentions a simple non-indexing backend on the todo list – but surely something more advanced is in the works at Red Hat?
who cares of redhat
now thanks to Alexander Ubuntu OpenSuse and others can implement nautilus-search without any problems
and btw beagle 0.13 really rocks
who cares of redhat
Funny you say that, but
FYI, Alexader Larsson is Redhat employee
As far as i read, this is *pluggable* search – you can plug any backend as you want. It is clearly win-win situation for all, including Beagle guys.
>As far as i read, this is *pluggable* search – you can plug any backend as you want.
Then a ferret plug-in might be of interest to all those that don’t want Mono on their system. It is a free translation (not port or straight rewrite) of Lucene in Ruby.
As far as i read, this is *pluggable* search – you can plug any backend as you want. It is clearly win-win situation for all, including Beagle guys.
See:
http://freedesktop.org/wiki/Software_2fTracker
Edited 2005-12-08 13:50
No source/binary is available at the moment as it is under heavy developemnt.
Um sweet
As the guy writing tracker, I have released a pre-release version of Tracker to interested parties.
Tracker can already do beagle like searches plus it can also do RDF Query searches on any metadata field.
Im hoping to have it as the default search engine for Nautilus search as its written in C and also has very low memory requirements (typically 3-6MB RAM used).
I expect to have it in Gnome VFS shortly…
As far as i read, this is *pluggable* search – you can plug any backend as you want. It is clearly win-win situation for all, including Beagle guys.
The question is – particularly since Larsson is a Red Hat employee – what backend will we see in RHEL and Fedora? One hopes something cool is in the works.
His surname is of course Larsson and nothing else.
Yeah, this is nice to see. Redhat is anyones guess. This is a plugin so they certainly don’t have to implement it, however, they lose if they don’t.
I am anxious to try this out.
“Yeah, this is nice to see. Redhat is anyones guess. This is a plugin so they certainly don’t have to implement it, however, they lose if they don’t. ”
This is being written by Red Hat. So…
… this IS exactly why the Spatial was created. Or should I say this makes using Spatial Windows make sense now.
Has any body tried Ctrl + F on Nautilus. It gives a nice Firefox like search box…But can not use it…I’m using Ubuntu…
“Has any body tried Ctrl + F on Nautilus. It gives a nice Firefox like search box…But can not use it…I’m using Ubuntu…”
This feature is broken for me as well, Nautilus 2.12.1 on Gentoo.
This is certainly a good approach for searching in Nautilus, although there are many needed UI changes. For example, the saved searches should show up with a folder-looking icon, perhaps a blue version of the standard folder or a folder with a “V” on it.
This looks very promising, though. I hope Red Hat plans on implemented something better than Beagle, because most users won’t settle for inferior searching just to avoid using Mono.
Microsoft uses their SQL engine for their searching back end, Apple uses SQLite; so what is GNOME/Novell going to use? or will it be flexible enough so that people can plug in any database they want.
Is there a way to implement slocate so that it index files dynamically or something a long those lines.
Sounds better then putting all those mono packages on my system =(. I dont mind using mono and all……. but i dont want something as large as mono (and all subsequent packages) just to use beagle. Ok i might screw around with monoUML and monoDevelop but after that i really dont know.
The kernel has inotify now, which allows you to track changes on the FS instantly, rather than relying solely on out-of-date static indexes.
So it can be implemented in something other than Mono/C#.
“rather than relying solely on out-of-date static indexes.”
That isn’t entirely true, as there is rlocate, which while it does need database updating, it is up to date when searching.
Interesting progress, even though I doubt I’ll use it because I’ve never found Nautilus that functional. It’d be nice if all the file managers in *nix could work together on such a feature.
FYI, mlocate replaces slocate in Fedora Rawhide.
This seems to consume screen realestate to some degree by dropping the rather large additional toolbars down for refining the search. With all the options out it might get very distracting, I know looking at the screenshots I found the ones with more options unfolded to be less than attractive.
While this is a step forwards for convenience, I would very much like to see a way of having the extra search parameter toolbars reduced in size, or perhaps obscured when they’re not in use. For example how about hiding them when the mouse isn’t over them and having them reappear when the mouse scrolls over a big enough hotspot (such as the first toolbar for example).
…at least if it works as it appears from the screenshots. I havent tried it myself so I may be wrong but it looks to treat the keywords seperately from other search criteria. IMO the search should be implemented to allow ALL possible criteria to be entered as a string (copy google’s syntax, they do it well):
alexander type:text/* location:/home
(or something like that)
Sure you can have the nice dropdowns and stuff, but they should just build the search strings for you thus giving you feedback. After you use it a while it will TEACH you its grammar (just like google does). Once you learn the grammar the widgets are just crutches that you no longer need. That would make the widgets of only secondary importance and you would only need to display them on user request (thus eliminating the bulky unneccessary interface elements). They should also add AND/OR/NOT functionality (if they didnt already). Again, preferably supporting google-like syntax. And maybe regexs, but hey Im a geek
It appears from my rather cursory overview that the files as folders view of the saved search is only in Nautilus, and not exposed via Gnome-VFS? Why, if so?
Try something diffrent :
Store your files in folder with good names, you can also create subfolders !! Then you put a cool name to your file, ok it’s 255 caracters limited but huh ?!
Exemple : do somebody outside of your family store / retrieve your bank accounts sheets – pay bills ?!
It isn’t entirely clear to me if this Nautilus “extension” will need Mono to work or not. I have mixed feelings towards Mono, I’m not sure that tying Nautilus to this technology is a good thing. (Please don’t take this as a pretext to start a flamewar on Mono!).
rehdon
DOWNLOAD WindowBlinds Enhanced 5.0: http://windows.czweb.org/show_article.php?id_article=404
Actually I agree – I’d much prefer to use Kat (KDE-based) or Beagle (Gnome-based) on my filesystem than grepping through documents etc. I only usually jump in with grep to search small portions of source code, or things that I haven’t bothered to index yet.
Side note: Kat is really nice, but I’m eagerly awaiting the user interface improvements in the next version. A properly friendly search interface is currently missing.
Thanks for the Windows tip – I’ll try it on the communal Windows boxes.
Actually I agree – I’d much prefer to use Kat (KDE-based) or Beagle (Gnome-based) on my filesystem than grepping through documents etc.
Errr… That’s because you’re waiting for packages for your distro right ?
When I said apples and oranges, I mean that with grep, you need only, uh, grep to find informations.
With tools like Beagle, and I’m sure like kat too, each specialised app need helpers to pass informations to beagle or kat : you don’t just install Beagle or Kat, you also have to modify every app that understand some specific file format for it to send the content correctly formatted.
I mean, Beagle and Kat are far more invasive than grep.
If all goes well, every useful app will have hooks for Beagle and Kat.
In fact, unless both Beagle and Kat use the same connectors, I have doubt that all apps will be able to send info to both. Which will force you even more to use apps from your environment (Evolution for Gnome instead of KMail for example).
Is there a KDE front end to Beagle? I’ve looked at Kat as a Beagle alternative, but to be honest I find its interface apalling – http://kat.mandriva.com/gallery2/main.php?g2_view=core.DownloadItem…
Something like Best/Holmes would be perfect – only the meaningful information, and easy ways to manipulate the data returned in the results.
Edited 2005-12-08 14:52
1) I wouldn’t use grep to find files
2) Certainly, existing gui file search methods on most linux distros are not very helpful. So more power to Nautilus.
3) Knocking the command line because you can’t be bothered to learn it, or because its not for naive users, or it looks nerdy to you, is stupid. Look at awk. Learn it. You’ll never make dismissive jokes about the command line again.
I’m wondering when these cool features will be integrated in the main stream of the gnome project…
I find the current desktop (and actually internet too) search engines to be quite limited in their uses, in that they miss way too much pertinent documents.
By that I mean, although most of them do normalize their index entries (i.e., they store “été” as “ete”, things like that), they don’t do lemmatization or decompositing.
It means searching for “buy” won’t bring back “bought”. Quite a problem for many languages, where you mostly have to limit yourself to nouns search (and even that will fail in many cases, due to the lack of decompositing).
Being able to easily extend queries to synonyms would be useful, too.
What’s disappointing is that there were tools that were performing all the above transformations (if so desired, of course) more than ten years ago. Things like SearchManager, to name one.
Oh well, maybe in ten years 🙂
Martin
Beagle framework just works
#!/usr/bin/python
import beagle,gobject
def hits_add(query,response):
hits = response.get_hits()
for hit in hits:
print hit.get_uri()
def end_cb(query,response,loop):
loop.quit()
client = beagle.Client()
loop = gobject.MainLoop()
query = beagle.Query()
query.add_text(“something”)
query.connect(“hits-added”,hits_add)
query.connect(“finished”,end_cb,loop)
client.send_request_async(query)
loop.run()
print “Enjoy”
> Errr… That’s because you’re waiting for packages for your
> distro right ?
I compiled mine from source… However, there seems to be a package in (K)Ubuntu breezy, Mandriva ships Kat enabled by default, Debian presumably has one… It’s filtering out into distros but will take a while.
> With tools like Beagle, and I’m sure like kat too, each
> specialised app need helpers to pass informations to beagle or
> kat : you don’t just install Beagle or Kat, you also have to
> modify every app that understand some specific file format for
> it to send the content correctly formatted.
Well, kat uses KDE KFile plugins in order to extract metadata for indexing. For full-text, it uses the a new kind of full text KFile plugin. As far as I can make out, support can be added to index any format that can be stripped down to bare text – usually easily done without modifying the original app (e.g. use antiword for doc files, ps2ascii for postscript, etc).
For straight document indexing, kat supports most document formats you’re likely to have lying around, plus some more unusual formats (Molecular Database Limited, for instance). It doesn’t actually integrate directly with the applications (so far), so it doesn’t give dependencies on what you use with it.
Beagle has some higher-level semantic information like “this text was found in an IM conversation with …”, which I don’t *think* kat can do (yet). Kat just lets you search a really large range of document formats, fast.
Btw, I’m not really saying either is better; I really like the way Beagle is highly integrated, but I use Kat personally.
Nautilus is one of the most unstable pieces of software I have ever used. It’s the prime reason I chose XFCE over Gnome. It’s cool to see Beagle being integrated into it, but it seems it may only enhance the instability. Plus the Nautilus GUI doesn’t lend itself to the addition of a search feature as rich as what Beagle can offer.
I say start over with Beagle at the base. Build an interface that is more like a Type Manger, only instead of organizing only one mime type, it should manage files for the whole system. Imagine something like iTunes only it shows you all the files on your computer. Then the user is in charge of organizing those files the way he or she wants them without the hassles of figuring out the linux file structure. Then the next step would be to hide or disable the view of system related files so that novice linux users won’t get confused. The linux hierarchy can be very confusing to a new user, so a standard file manager (like Nautilus) doesn’t really help any when it comes to file navigation.
I’d really like to see the XFCE development team move Thunar is this direction, but they don’t like to think out side of the box when it comes to file management.
ROTFL kat has an ugly user interface seems to me
a toy program written for sport
This new search method looks really interesting being integrated into nautilus. But, beagle with either Best or Holmes front ends already can show me realtime search results across my entire home directory. Holmes is a lot like Spotlight/Skyos search menu in that results don’t require much filters or having to click “search”. Best requires you click search, but it shows results grouped by types and even queries up browser and gaim logs.
I guess the biggest innovation this brings is virtual folders.
But we don’t need another frontend to search, we need integration (into the file manager) plus the features of a separate frontend in one place. Separate programs only slow down the flow of operation in an operating system environment. Just my 2 cents.
I’ve been waiting for something like this for quite sometime. Beagle just isn’t integrated enough into Gnome yet. This is a step in the the right direction. Whoever posted about UI… Get real man. This is brand new, expect some things to be rough around the edges. Now if only this was in the Ubuntu Dapper repo’s… I could test it and report bugs. Let’s get this project rolling!
These suckers are copying Windows Vista’s Virtual Folder concept.
Because Microsoft never copied anyone… right…
Ofcourse they copy Apple’s MAC OS X but this doesn’t mean that other software communities start copying them only bcoz they copy others. Apple is really a leader in OS development. They put new concepts in their OS which no other had ever introduced.
What is the big deal with this type of searching?
glimpse was doing the same about 10 years ago.
Sure it didn’t have a GUI (but it had
a web interface), and it didn’t reindex files
in real time, but none of these is rocket science.
Browser: Lynx/2.8.3rel.1 libwww-FM/2.14
But we don’t need another frontend to search, we need integration (into the file manager) plus the features of a separate frontend in one place. Separate programs only slow down the flow of operation in an operating system environment.
You’re right, integration is the way. Anyway search in nautilus (or other file manager) should be obviously related to files. If you want to search for IM, mails and everything “social related”, a tiny applet showed by default is IMO more useful.
I did a quick search through the comments, but the screenshots only show it working in spatial mode. I hope it still works in browser mode (ubuntu default)
It does. Running it right now on Ubuntu Dapper.