On Nov 1, 2012, at 12:35 AM, Jonathan Wilkes wrote: > ----- Original Message ----- > >> From: Hans-Christoph Steiner <[email protected]> >> To: Jonathan Wilkes <[email protected]> >> Cc: PD List <[email protected]> >> 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 <[email protected]> >>>> To: Jonathan Wilkes <[email protected]> >>>> Cc: PD List <[email protected]> >>>> 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 >>>> >> _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
