Nautilus Search

When you search in a web page you use the search panel to navigate within the document.

When you search like this in Nautilus you create/call up the document using the search panel. It really is much more like the address bar in your browser, and that is normally located above the document frame.

I rather like how Beagle looks. It looks like it was invented in the 21st century. I like a lot of Gnome widgets, but some of the screenshots look 1980-esque. I think the new more modern look that Beagle is inspiring is a good balance between professionalism and eye candy.

Of course the graphicians have to make their way into the thing, before it is officially released. This is more like a "proof of concept" or that stuff.

locate doesn't search the content of a file.

grep --ignore-case --recursive --with-filename pattern /
or just:
grep -irH pattern /

You got to be kidding. This takes like three hours, beagle is a database which does this in milliseconds.

So...you're saying that search functionality in computers isn't really all that useful.

Interesting position.

I take it you're not a developer? Have you ever gone searching for a subroutine in a code tree without the use of grep or find?

Even if you don't use it for that position, what about as a convenience function to group similar docs? What about deeply nested directory names? What about trying to find some config file that gets put in a nonstandard location? What about searching for a song/movie title to save you the trouble of navigating to it?

The uses are endless.

All I was saying that as a normal user and casual developer I don't have any use for features like this. For example searching for something in a long web page is useful, but searching for certain files isn't really that much useful.

And no, I have never searched for any subroutine in a code tree. I just use API docs. Oh, and I do have lots of docs, but I have them all in their respective directories. I have tried Beagle, but I couldn't seem to find any single keyword to search for which would have returned all the desired docs.

All the movies are in one place, and trying to search for something would just take longer time and take more keypresses than simply navigating there myself.

All the songs are in their own directory in my ~/Music, and everything is easily accessible with Rhythmbox.

All in all, I was just saying that this won't benefit me in any way. I just hope other people will find it useful.
-WareKala

One of the smart things with these search-folders is, that you can easily have the same files in multiple folders. A common example is that you can have your pictures sorted in categories: You, your family, your holidays etc. Maybe half of the pictures would contain you, and be in the you folder, but you would still be on a lot of the family and holidays pictures, so the files would be to find there too.

That would be useful, if I organized my pictures like that, and would tag each and every single picture I have. But I don't do that. That would take just way too long time, and Nautilus doesn't provide any facilities for tagging those. Besides, F-Spot is ten times better at handling this sort of categorizing etc that your argument of using Nautilus for that kind of loses its point.
-WareKala

http://www.chipx86.com/blog/?p=140.
--
:wq

The point is that you wouldn't have to categorize the pictures. Just like nobody are categorizing the pictures at google image search.

Have you seen the video at the beagle site? It's actually quite good finding pictures.

This code depends on libbeagle - a C language interface to communicate with Beagle. Libbeagle doesn't depend on Mono, as it is written in C.
Libbeagle is currently shipped in Beagle tarball, but separating it is easy and should be done by package creators.

--
:wq

But if libbeagle is a language interface, made for communication with Beagle, then what is it good for without beagle?

Yes it useless without Beagle. But it allows linking Nautilus with libbeagle without mono burden. So distros like Fedora can provide this feature (not really working) without caring about Mono.
And then user can install some third party mono&beagle rpms and have Nautilus Search working without need to recompile Nautilus.
--
:wq

Perhaps a C backend with a C#/Mono frontend?

Could somebody who knows Beagle clarify exactly what parts of it are written in what languages?

Actually which search features has Beagle got that normal gnome search hasn't? I know that it updates the search, after the search has finished, but that would properly have to be rewritten for those search-folders anyways.

Beagle searches are faster than Nautilus searches (currently) because the former actually searches an index and the latter searches all the relevant files for your search criteria.

The upside of index searches is speed—Lucene (the workhorse of Beagle) searches its indices faster than any brute-force grep-like search can search a set of files. The downside of index searches is accuracy—if the indices aren't maintained, they will quickly go out of date, in which case the results of any search of those indices will probably be worthless.

To make up for this, Beagle also uses inotify to allow the Linux kernel to tell it when a file has been created, removed, or altered. This notification allows Beagle to know when to call Lucene to index a document, remove a document from its indices, or update the information in the indices about a document (respectively). Thus, ostensibly, Beagle can "keep up" with changes and provide both the speed of an index search with the currency of a brute-force search.

One of the coolest advantages is that it updates it's database live. For a demonstration of what that means best have a look at the videos:

http://nat.org/demos/

Anyone have a copy of these movies in a format that can be played with Free Software? It's ironic that Beagle is intended for use on Free Software systems yet the demos can't be viewed without installing a proprietary player program.

I know, but will it work with search-folders?

The mono guys should just make a native compile option, and the problem would be solved (I guess). The best thing would be to port it into C or Python.

Perhaps then Nautilus' current search panel could instead become a Beagle search panel. That is, the same Nautilus search interface could continue to exist, but the searches would be far faster and, thus, more useful in a day-to-day sense. But I'm not sure that Beagle searches can be as detailed as Nautilus searches currently allow.

I would like to see integration and improvement of the features we already have rather than replacement with a totally new UI that doesn't really address the features of the old UI. Particularly not while the old UI still exists, giving the user multiple ways to do the same thing (which, in this context, I believe users will find confusing).

MacOS went through this growing pain, introducing what Apple called "Sherlock" during what is now called "classic MacOS" (I think it was MacOS 9). Now, with the current MacOS X (10.4?), they have indexed searches that chiefly work on keywords. I don't know if Sherlock is still around in the latest MacOS X, but if it is I'd wonder what benefit accrues to the user that outweighs the simplicity of the index search.

Finally, I don't want this new feature at the expense of my software freedom. I'd rather do without bullet-fast Beagle searches (I'd learn to live with brute-force searches) than give up my software freedom. So if Beagle is patent-encumbered due to being implemented with C# or requiring a .Net implementation, I'll be perfectly fine letting that software go to waste and doing without.

Ok, so let's remove the code from CVS. YOU don't want it.

He makes a good point and i can assure you he's not alone... =)

If they compile it nativly, the developers won't have to change language, the users won't have to fulfill deps, and maybe we will even have speed enchantments like eclipse.

Thomas