[PD] Browse/Search plugin update

[Jonathan Wilkes]

----- Original Message -----

> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: PD List <pd-list at iem.at>
> Sent: Wednesday, October 31, 2012 11:46 PM
> Subject: Re: [PD] Browse/Search plugin update
> 
> 
> On Oct 31, 2012, at 2:20 PM, Jonathan Wilkes wrote:
> 
>>  ----- Original Message -----
>> 
>>>  From: Hans-Christoph Steiner <hans at at.or.at>
>>>  To: Jonathan Wilkes <jancsika at yahoo.com>
>>>  Cc: PD List <pd-list at iem.at>
>>>  Sent: Tuesday, October 30, 2012 10:38 PM
>>>  Subject: Re: [PD] Browse/Search plugin update
>>> 
>>> 
>>>  On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
>>>>  I updated my search plugin by adding a progressbar:
>>>> 
>>>>  http://puredata.info/Members/jancsika/searchandbrowseplugin/view
>>>> 
>>>>  It also prints out the number of files it searched.  There were 
> some
>>>>  reports of a search taking over a minute, but with GNU/Linux and
>>>>  winxp I'm getting about 3 seconds for a little over 9,000 docs 
> (I
>>>>  think I'm searching two different copies of pd-extended libs so
>>>>  that should be well over what you'd typically be searching).  
> If
>>>>  people are getting long searches please start by telling me how
>>>>  many files you're searching.  Also, the progressbar updates 
> don't
>>>>  start until it's built a list of files and sorted it, so if 
> it's 
>>>  taking a long
>>>>  time when you search before the progressbar appears then that
>>>>  may be the culprit.
>>>> 
>>>>  Now that the interface updates live I don't really think 
> there's 
>>>  much
>>>>  need to build an index.  You can start reading the first results
>>>>  immediately and even scroll the list as it finishes printing the 
> results.
>>>>  (I guess I can also add a "Cancel" button, too.)
>>>> 
>>>>  Let me know if there are any bugs.
>>>> 
>>>>  -Jonathan
>>> 
>>>  Looking very good!  I consider this something everyone should install 
> now.
>> 
>>  It's UI is designed to be a drop-in replacement for the ctrl-b 
> browser.  You should
>>  be able to browse all the same locations, plus the user gets descriptions 
> of
>>  all the libdirs which makes browsing them much more meaningful.  There is
>>  zero delay when browsing docs.  (Well, aside from a small delay on winxp
>>  with the libdirs because of another lsort -command, but I'll be 
> removing that
>>  soon.)
>> 
>>  You can use ctrl-minus and ctrl-plus (or ctrl-equals) to make the text 
> larger or
>>  smaller, just like every web browser and word-processor I've ever used, 
> so it
>>  has more accessibility than the ctrl-b browser.  Additionally, clicking the 
> folder
>>  icon to bring up the containing folder is easier to discover than however 
> you
>>  do that in the ctrl-b browser (which isn't documented).
>> 
>>  Finally, displaying a description for the content of pd files encourages 
> devs to
>>  actually describe the content of their files.  I know "No DESCRIPTION 
> tag" looks
>>  ugly but the fix is to add descriptions and improve the documentation.
>> 
>>  If there's interest in this replacing the ctrl-b browser I'll do 
> some work to make it
>>  an actual drop-in replacement instead of a plug-in.  (So for example, you 
> click
>>  ctrl-b and the search/browse plugin pops up.)
> 
> Its definitely a lot more polished than the help browser, and its almost a 
> complete replacement.  Here are a couple things that I spotted:
> 
> * it lacks a clear way to go back a level, I think this would be well handled by 
> standard back/forward buttons like are in internet browsers, file browsers, etc.

You can follow the folder links back.  For initial search you can go back home.
For multiple searches no, you can't.

To rectify this would require caching the state of the text widget-- using
the "dump" subcommand I guess-- for however many levels you want to
support.  It could probably become several megs of data pretty quick, so I guess
it'd have to be cached to a file somewhere, which adds another level of
complexity.

Also, guess what?  There's no matching subcommand for "dump"!  So just like
hyperlinks I'd have to hand craft some way to read the contents back in to the
widget.

If you have an easier suggestion to get this functionality let me know.  Otherwise
I think it's too much trouble.

> 
> * there are a number of libraries that show: "version: no AUTHOR tag or 
> values" while the author: field is filled out.

Which library?  I'll check it out.

Thanks,
Jonathan

> 
> .hc
> 
> 
> 
> 
> 
>> 
>>  -Jonathan
>> 
>>>  The 
>>>  progress bar is a good enhancement.  I wonder if it could somehow fit 
> in to the 
>>>  GUI elements better somehow.  Its fine how it is, but it seems a little 
> out of 
>>>  place.
>>> 
>>>  Looks like there are some debug messages still in it, I get these when 
> hovering:
>>> 
>>>  filename is 5.reference/all_about_arrays.pd
>>>  basedir is 
> /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>>>  filename is 5.reference/loop~-help.pd
>>>  basedir is 
> /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>>>  filename is 5.reference/all_about_arrays.pd
>>>  filelist is 7751
>>>  filelist is 7751
>>> 
>>>  .hc
>>> 
>