[PD] Browse/Search plugin update

[Jonathan Wilkes]

>________________________________
> From: Hans-Christoph Steiner <hans at at.or.at>
>To: Jonathan Wilkes <jancsika at yahoo.com> 
>Cc: Dan Wilcox <danomatika at gmail.com>; "pd-list at iem.at" <pd-list at iem.at> 
>Sent: Friday, November 30, 2012 2:03 PM
>Subject: Re: [PD] Browse/Search plugin update
>  
>
>
>
>On Nov 30, 2012, at 3:27 AM, Jonathan Wilkes wrote:
>
>Here's an update:
>>
>>
>>http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/scripts/guiplugins/search-plugin/
>>
>>
>>* fixes the color weirdness on OSX
>>* sets some minimum height/width for the window
>>* adds the "filesystem" keyword to Keyword Search
>>* hard-coded normal font color to black
>>
>>... plus the static navigation bar above the results
>>
>>
>>
>>Stuff I don't understand:
>>* grid weight, esp. when frames are involved. i just played with it
>>until it got beat into submission
>>* what tcl is caching that makes all subsequent searches faster than
>>the initial one. no clue.
>
>
>I doubt that's Tcl doing the caching, but very likely to be the OS doing it.  Most OSes these days use spare RAM to cache disk reads.  My guess is that is what's happening here.  I think using xapian is really the best way to solve this issue.  I think we should be able to include pre-built xapian indexes in Pd-extended, and in each library.  Then everything would be loaded at start time.  It would not need to do much indexing at start time since almost everything would already be indexed.  Also, it could save the indexes it generates, and only regenerate them when files change.

How long is the initial search taking for you?
Since the results pop up live, even with the initial 5-10" search the UX is still decent.  In fact I could even
make the click events stop the search loop which would make the initial search sluggishness even less of an issue.
 
Xapian might be worth it if someone who deeply understands search technology wants to implement it and get a
more sophisticated scoring system for better results.  Still, with the poverty of quality documentation I'm not sure how
much better the results could really be:
 
[sig~ 42]
|
[super_complex_filter~]  <-- super-complex-filter the input
|
[tabwrite~] <-- super-complex-filtered output
 
(c) 1999 <query_bouncer at compuserve.net>
 
 
 
>
>
>
>... after using it a bit I instinctively clicked <alt-left-arrow> to go back,
>>so I guess that's my hand telling me it needs some kind of history.
>>(Though it does have a drop-down list of your search terms for that
>>instance of Pd if you click the down-arrow.)
>>
>
>Yeah, well said, that's often how I know certain things need to be done.
>
>
>.hc
>
>