<div dir="ltr"><div dir="ltr">On Mon, Mar 29, 2021 at 7:16 AM Gabriela Bittencourt <<a href="mailto:gabrielabittencourt00@gmail.com">gabrielabittencourt00@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> - Merge results from the help file and the file
itself;<blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
</div>
</blockquote>
<div><br>
</div>
<div>I'm not sure what this bullet point means. What does
"the file itself" refer to here?<br>
</div>
</div>
</div>
</div>
</blockquote>
<p>Let's take the example, when we search for "metro", we get the
following results:<br>
</p>
<p><img src="cid:1787ee58f29fb40ea372" alt=""></p></div></blockquote><div><br></div><div>That second "metro" links to "metro.pd" which is definitely an outlier. It appears it got added here:</div><div><br></div><div>```</div><div>commit 721fe32c2a83110020bfd772aacd83d62d245e5f<br>Author: Albert Graef <<a href="mailto:aggraef@gmail.com">aggraef@gmail.com</a>><br>Date: Mon Nov 28 14:13:07 2016 +0100<br><br> Replace antique non-pddp metro help patch with latest version from vanilla.</div><div>```<br></div><div> </div><div>That commit doesn't make much sense, because metro.pd *is* a non-pddp help patch.</div><div><br></div><div>Albert-- any info on what you were trying to achieve here?<br></div><div><br></div><div>Anyway, most core objects have a single help file. For external binary libraries, the binary itself is not included in search results.</div><div><br></div><div>Abstractions are tricky. If there's an abstractionName-help.pd patch, we want to show that in the search results instead of abstractionName.pd. However, if there's an abstraction with no help patch, we probably want to show abstractionName.pd in the results since the user can open it and inspect the implementation. (Generally, everything should have a *-help.pd but there are probably many undocumented abstractions in externals/.)<br></div><div><br></div><div>Try doing a search on "rev1" to see a pretty bad case. We are somehow shipping the *-help.pd in two different directories!<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p></p>
<p>The first is "metro-help.pd" and the second is "metro.pd". My
proposition is to merge both files into one index, gathering more
info in the same index item. In the browser documentation we could
always link to the help file (when present), and in the
autocomplete dropdown we could link to the object.pd. What do you
think?<br></p></div></blockquote><div><br></div><div>Ignoring undocumented abstractions for the moment-- in the common cases you should be able to get the autocomplete string from the *-help.pd filename.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>(b) Integrate it in the search engine of the
documentation browser:</p>
<p> - Dynamically refreshing search results while
typing <br>
</p>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p> </p>
<p>(c) Integrate it into a friendly drop down menu to be
used when editing objects.</p>
<p> What do you think?</p>
</div>
</blockquote>
<div><br>
</div>
<div>It sounds doable for sure.<br>
</div>
<div><br>
</div>
<div>The tasks of "a" above are mostly pure javascript, and
I don't *think* it requires any changes to the currently
used node.js methods. So that is probably subject to quick
iteration and improvement.</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>For "b", the index has already been generated so this
is pure javascript and also subject to quick iteration.</div>
</div>
</div>
</div>
</blockquote>
<p>I've implemented the task "b" and second bullet of task "a"
(hierarchy of priorities) as a proof of concept, merge request
#715.</p></div></blockquote><div><br></div><div>Oh, ok. I'll have a look as soon as I get a chance.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>"c" would have the most work in terms of UI changes and
getting the UX right. But again, pure javascript <br>
</div>
<div>and HTML5 so quick iteration here, too.</div>
<div><br>
</div>
<div>With that in mind, I think it's worth investigating the
current search indexing method and leveraging that to get
an initial list of object creator names, and to stay in
the domain of pure JS (including any pure JS libs if those
are needed).<br>
</div>
<div><br>
</div>
<div>Hint-- It has been a long-standing rule that it's a bug
to ship an external binary without a help patch. So most
should have an objectName-help.pd patch, and the outlier
externals (as well as outlier core objects) can be dealt
with as a handful of special cases.</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div> <br>
</div>
<div>A few other ideas:</div>
<div>* dealing with object arguments and message box
content. I love the way DevTools will remember entire
commands, even across instances. So perhaps a way to add
previously entered box content</div>
</div>
</div>
</div>
</blockquote>
That sounds feasible.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>* a way to automatically add docs in index when the
user adds a new path, either globally through <br>
</div>
<div>preferences or by instantiating a `[declare]` with a
path or lib. Although this could get tricky and may be out
of scope for this particular project. (I.e., requires
crossing between GUI and backend wrt `[declare]`)</div>
</div>
</div>
</div>
</blockquote>
<p>Cool, it would improve the robustness of the feature! I would ask
more help for this bullet than the previous ones, but I'm excited
to do it and learn in the process!</p></div></blockquote><div><br></div><div>That sounds great.</div><div><br></div><div>One word of warning-- I'm talking mainly from the experience of previous years of GSoC where the project duration was longer. What you've written so far seems feasible as I skim it-- but it is something to keep in mind.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p><br>
</p>
<p>For the GSOC application, what feature is the most
urgent/interesting to purr data community? The project of the
audio plugins; this one for autocomplete; or the suggested ideas
for gsoc'21?</p></div></blockquote><div><br></div><div>I'm partial to the autocomplete feature as it would be a big UX improvement. But I'm curious what others think.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p><br>
</p>
<p>PS: I've made 2 merge requests (#) into the master branch, but I
saw everyone else is making on the emscripten branch?<br></p></div></blockquote><div><br></div><div>The web app project idea is quite popular, so there's been a lot of activity on that branch. The idea is to merge that into master, but I think there are a few outstanding issues to address before doing so.</div><div><br></div><div>One detail-- the help browser does not currently work in the web app. The doc browser builds its index in the GUI, using node.js. But in the web app only the backend has access to whatever the emscripten file-system abstraction is called.</div><div><br></div><div>Probably the solution there is to *ship* the web app with the doc browser index, and just make a shim to load it up. I think a lot of the pieces are already in place to do that so it shouldn't affect your project idea.</div><div><br></div><div>-Jonathan <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>Best,</div>
<div>Jonathan<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<p>Best,</p>
<p>Gabriela<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div>Best,</div>
<div>Jonathan<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite"> <br>
<blockquote type="cite">Best, <br>
Jonathan <br>
<br>
<blockquote type="cite">Best regards, <br>
<br>
Gabriela <br>
<br>
_______________________________________________ <br>
L2Ork-dev mailing list <br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a>
<br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a>
<br>
</blockquote>
_______________________________________________ <br>
L2Ork-dev mailing list <br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a>
<br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a>
<br>
</blockquote>
</blockquote>
</div>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
L2Ork-dev mailing list
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></pre>
</blockquote>
</div>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
L2Ork-dev mailing list
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></pre>
</blockquote>
</div>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div></div>