<div dir="auto">The fix that may have triggered the regression you describe was supposed to fix a regression :-)<div dir="auto"><br></div><div dir="auto">Namely the code removed that deletes data structures during a redraw also tends to delete all the other objects on a subpatch when an undo action is triggered, leaving only patch cords visible. This was true regardless of the nw.js version. I suspect that the fix that Jonathan originally introduced there may have been because of drawing of the data structures alongside the regular objects on the same canvas, which is what the about page has with the animated cat.</div><div dir="auto"><br></div><div dir="auto">My originally proposed merge request offered deleting only scalars in a situation that the code seemed to address. I also indicated that it needed to be tested further given I was unsure under which circumstances this code would be necessary. The final merge was Jonathan's where he erased that part entirely suggesting it was not necessary anymore.</div><div dir="auto"><br></div><div dir="auto">What may be helpful, as the code complexity continues to grow, is to carefully annotate each of these calls in the code so that we can better understand why they are placed there in the first place and what needs to be done to check for regressions.<br></div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">Best,<br><br>Ico<br><br>-- <br>Ivica Ico Bukvic, D.M.A.<br>Director, Creativity + Innovation<br>Institute for Creativity, Arts, and Technology<br><br>Virginia Tech<br>Creative Technologies in Music<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu">ico@vt.edu</a><br><br><a href="http://www.icat.vt.edu">www.icat.vt.edu</a><br><a href="http://www.performingarts.vt.edu">www.performingarts.vt.edu</a><br><a href="http://l2ork.icat.vt.edu">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net">ico.bukvic.net</a></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 30, 2020, 14:16 Albert Graef <<a href="mailto:aggraef@gmail.com">aggraef@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Sorry, I missed these remarks earlier.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 30, 2020 at 2:14 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank" rel="noreferrer">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I can confirm running HEAD against a local 0.46.3 nw.js on aarch64<br>
does indeed work to load and display patches.<br></blockquote><div><br></div><div>Have you tried  the Help - About Pd-L2ork menu entry?</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">
What do I need to add to the contributor's guide to make it clear what<br>
a desirable merge request branch should look like?<br></blockquote><div><br></div><div>I guess you're talking about workflow here? That is, rebasing and squashing commits so that you present your feature branch a.k.a. merge request as simple and comprehensible as possible, with a clean and logical commit history. There's a lot that goes into that  process and much of it is common sense -- but you'd probably have to replicate half the Git Book to explain these things really thoroughly.<br></div><div><br></div>However, the main failure in this case IMHO was that there weren't enough eyeballs looking at this "patchset from hell", before the changes were merged into master. A call for help on the mailing list goes a long way there, explaining what the new set of changes is about, what parts of the program might be affected, and what needs to be tested. I did notice the flurry of commits, but I wasn't sure what they were about and didn't have the time to look into them. I would certainly have tried to give a helping hand in testing, though, when asked about it in the manner described. ;-) (Or maybe I missed that call, then I have to apologize.)</div><div class="gmail_quote"><br></div><div class="gmail_quote">Albert</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

> On Tue, Jun 30, 2020 at 11:42 AM Sam Thursfield <<a href="mailto:ssssam@gmail.com" target="_blank" rel="noreferrer">ssssam@gmail.com</a>> wrote:<br>
>><br>
>> Hi Albert,<br>
>><br>
>> On Tue, Jun 30, 2020 at 9:12 AM Albert Graef <<a href="mailto:aggraef@gmail.com" target="_blank" rel="noreferrer">aggraef@gmail.com</a>> wrote:<br>
>> > The program still builds fine, launches and I can still open new patch windows (^n), but "About Pd-L2ork" doesn't work any more and I can't open existing patches either (apparently the patches do get opened in the engine, but no window is mapped).<br>
>><br>
>> Is it possible that you are using a version of nw.js >= 0.42.3 ?<br>
>> This issue sounds a bit like<br>
>> <a href="https://git.purrdata.net/jwilkes/purr-data/-/issues/572" rel="noreferrer noreferrer" target="_blank">https://git.purrdata.net/jwilkes/purr-data/-/issues/572</a><br>
>> Sam<br>
>> _______________________________________________<br>
>> L2Ork-dev mailing list<br>
>> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank" rel="noreferrer">L2Ork-dev@disis.music.vt.edu</a><br>
>> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
><br>
><br>
><br>
> --<br>
> Dr. Albert Gr"af<br>
> Computer Music Research Group, JGU Mainz, Germany<br>
> Email: <a href="mailto:aggraef@gmail.com" target="_blank" rel="noreferrer">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" rel="noreferrer noreferrer" target="_blank">https://agraef.github.io/</a><br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank" rel="noreferrer">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank" rel="noreferrer">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank" rel="noreferrer">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank" rel="noreferrer">https://agraef.github.io/</a></div></div></div></div></div></div></div>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank" rel="noreferrer">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div>