Re: search branch merged

[Alexander Larsson <alexl redhat com>]

On Fri, 2005-12-16 at 11:13 +0000, Jamie McCracken wrote:
> Alexander Larsson wrote:
> > Today I merged the nautilus-search2 branch to HEAD. The code is not
> > totally done yet but it should mostly work, and I wanted to get
> > it into the 2.13.3 so some people would look at it. Also, the branch
> > contained various memleak and other fixes that I wanted to get in.
> > 
> > The search engine is pluggalble, to the extent that it is internally
> > factored out. However you can't install search engines outside of
> > nautilus atm. I.E you have to actually rebuild nautilus with libbeagle
> > installed to get support for beagle. This is beacuse I'm not ready to
> > export the APIs required to implement search backends outside the tree
> > yet (the code/API is not mature enough for that). If you don't have
> > beagle (or some other indexer) availible at build and running at
> > runtime then Nautilus will fall back to a simpler non-indexed search
> > engine which will work, but be slower and won't search on file
> > contents.
> 
> 
> Can I make a few suggestion to this:
> 
> I'm not sure how to theme the colour but would it make more sense to use 
> the menu bar colour? Themes like Clearlooks always make the menubar 
> stand out and its recommended for themes to do this.

Its possible for themes to set the color, using something like:

style "blah" {
      bg[NORMAL] = "red"
}
widget "*.nautilus-extra-view-widget" style:highest "blah"

I'd like to perhaps use the new color stuff in gtk+ to make this
simpler, but that won't be supported in gnome 2.14.

> Having to put a search term in before filtering further can cause 
> problems and limitations. If you use the simple non-indexed search it 
> kills system performance because its doing a global search before you 
> have a chance to filter. The other problem is there is no easy way to 
> create a vfolder that just shows all documents (the search term you are 
> forced to enter will always filter out some documents!). Maybe show the 
> filtering options when the user clicks the search button? (can be a 
> gconf setting?) and thus make the search term optional?

For non-indexed search we don't auto-refresh when changing stuff, but
add a "go" button, which should help this problem. I'm not sure not
being able to search for all documents on the system is a huge problem.
That is probably a much less likely operation than easily searching for
something by a string.

> Supporting more filter types. As you know Tracker supports a vast array 
> of metadata (as per the freedesktop spec) which neither Beagle nor the 
> simple non-indexed search supports atm so I think we need some query 
> capability call in the backends. Tracker also supports operations 
> (equals, contains, <>, >, <, between) which are more relevant depending 
> on the metadata type being searched (ie a date would use between, =, <, 
>  > as would an integer based one like filesize). AFAIK Beagle also 
> supports date ranges. Are you happy to support this if I create a patch?

The plan was always to support more filters. So, any sane ones that most
backends can support would be accepted. Of course, its a little
problematic if its not possible for the "simple" backend to support
them.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a Nobel prize-winning coffee-fuelled vampire hunter fleeing from a secret 
government programme. She's a foxy belly-dancing widow with a song in her 
heart and a spring in her step. They fight crime!