[L2Ork-dev] Improving the help browser (help index)

[Jonathan Wilkes]

I'd say go ahead with the per-instance indexing of the paths for the
externals we ship.

Then perhaps we can build on that later to do per-install index
caching, per-instance spidering
of local Purr paths and/or currently open patches, etc.

I don't remember-- does index-building block the entire GUI, or just
the search window interaction?

And did I put visual feedback for index-building?

-Jonathan

On Tue, Mar 20, 2018 at 1:45 PM, Albert Graef <aggraef at gmail.com> wrote:
> I've discussed this with Jonathan on the issue tracker before, but this
> deserves more eyeballs.
>
> Don't get me wrong, the Purr Data help browser is really nice, but its
> keyword search is currently rather limited because it's confined to the help
> patches in the doc/ hierarchy. Thus if I go looking for, say `packosc` from
> mrpeach or `seq` from cyclone then it turns up nothing.
>
> One reason for this limitation is that constructing the keyword index is
> noticeably faster that way. But it also makes finding stuff in extra much
> harder, because you always have to go through the help browser's integrated
> file browser to find stuff. I find that rather tedious. If I don't know
> *exactly* what external and object I'm looking for then I'm basically lost
> in the sea of files that lives under extra. So the keyword search fails me
> when I need it the most. I bet that most serious Purr Data users out there
> have run into this issue before. I know that my students run into it quite
> frequently as well.
>
> Now it isn't a big deal to make the help browser scan all of lib/pd-l2ork
> when it constructs the index. In fact, it's just a few trivial changes in
> the JavaScript code in dialog_search.html, you can find the necessary
> changes here: https://bitbucket.org/agraef/purr-data/commits/90f7c755
>
> To my great delight I found that on Linux, this doesn't really slow down the
> help browser much on startup at all any more. I've been testing that branch
> for a few hours now. I hardly notice the added delay and I do enjoy that I
> can search for stuff in extra/ now, as the screenshot attached below readily
> proves. I'm thinking hard about adding this patch to the JGU packages so
> that my students can benefit from this as well, even if Jonathan doesn't
> merge it into mainline.
>
> Unfortunately, the help browser *does* become much slower on the Mac when it
> is patched up like that (it needs some 10 secs until it's done building the
> index -- that's on an oldish 2013 MB Pro, but my Linux box isn't much
> beefier either). I don't understand why that is. Could it be that the
> node.js file operations are *that* much faster on Linux? That would be at
> least an order of magnitude, which seems ridiculous.
>
> What are everybody's thoughts on this? Would you prefer a help browser
> that's slow on startup but then offers a better keyword search? Or maybe
> anyone has an idea on how to speed it up some more on the Mac? Jonathan,
> maybe the index could already be constructed once in the background while
> Purr Data is loading, so that it's ready to go when it's needed?
>
> Any and all comments and ideas are very much appreciated. I really think
> that this is an important area where Purr Data definitely needs to be
> improved.
>
> Albert
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email:  aggraef at gmail.com
> WWW:    https://plus.google.com/+AlbertGraef
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev