On Nov 1, 2012, at 12:35 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@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.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@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