[PD] Browse/Search plugin update

[Hans-Christoph Steiner]

On Nov 1, 2012, at 12:35 AM, 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: 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.

It would help to make the folder links more apparent, they are quite small and easily overlooked, at least for impatient people like me ;)

For back/forward buttons, couldn't you just store a reference to each page?  Basically you have two stacks, one for the back and one for the forward.  Each time you click on a link, you add the current page to the back stack.  Each time you click back, you add the current page to the forward stack.  Clicking a new link clears the forward stack.

>> * 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.

A few of them, I just opened up the libraries view and skimmed the list.

.hc


> 
> 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
>>>> 
>>