<div dir="ltr">Got it. So, are we going to build on top of Christopher's work or do we start afresh?<div><br></div><div>I thought his implementation needed improvements as it doesn't actually store the values in some variable, rather it parses the blocks to find the values.</div><div><br></div><div>Also, he has created constructs for creating custom dictionaries, I'm not sure whether we want that too.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Sep 2020 at 02:04, Walter Bender <<a href="mailto:walter.bender@gmail.com">walter.bender@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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 8, 2020 at 3:57 PM Anindya Kundu <<a href="mailto:anindyaak007@gmail.com" target="_blank">anindyaak007@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"><div dir="ltr">We'd definitely need to go back to the drawing board and chalk out the plan and the structure, e.g. data flow diagram. With it, I'll come up with a list of objectives and create the issue.<div><br></div><div>Meanwhile, I can help with the dictionary stuff too. Please do let me know what I can do.</div></div></blockquote><div><br></div><div>The current implementation is tied to the block structure, which doesn't really work (especially for  JavaScript export). I think there should be a default dictionary for each turtle and that dictionary should auto-populate with the turtle attributes. You should be able to access the dictionary by the turtle name (or by default for your own dictionary). This would let us eliminate most of the Ensemble blocks.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Also, thanks Vaibhav for the resources, and Devin, I'll keep you posted when I begin.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Sep 2020 at 01:14, Walter Bender <<a href="mailto:walter.bender@gmail.com" target="_blank">walter.bender@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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 8, 2020 at 10:39 AM Anindya Kundu <<a href="mailto:anindyaak007@gmail.com" target="_blank">anindyaak007@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"><div dir="ltr"><div>I'm considering reorganizing the modules and cleaning up the complete codebase in a gradual manner - something I briefly worked on, during this summer. It is to my understanding that Music Blocks was built progressively, and there's still scope for a lot of additions, but I've observed some significant issues.</div><div><br></div><div>I feel the user experience isn't quite appealing. For instance, the application feels bulky, the mouse interaction isn't very good, there are UI lapses here and there, etc. As for the code, I feel we are lacking structure. The JS modules have become disorganized, there's lots of deprecated code spread throughout, and the scripts do not stick to a proper convention.</div><div><br></div><div>Many times it becomes a challenge to figure out the source of a bug or add/modify some code. Also, it is quite easy to generate an obscure bug while fixing something else. Moreover, several components are convoluted among themselves. I've only worked on the MVC refactoring of a few components, but I believe it should be done all throughout for it to bear advantages.</div><div><br></div><div>Therefore, I'm planning on rebuilding a structure under the hood, primarily for better code management, but also to enhance the performance of the application. Any thoughts or suggestions?</div><div><br></div><br clear="all"><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font size="2" color="#666666"><i><span style="font-family:"arial narrow",sans-serif">Anindya Kundu</span></i></font></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font size="2"><span style="font-family:"arial narrow",sans-serif"></span></font></blockquote></div></div></div></div></div></div></div></div>
</blockquote></div><div><br></div>Sounds great.<div><br></div><div>Before you jump into coding maybe you can create a master issue to track proposed changes and progress.</div><div><br></div><div>(One obvious TODO would be to rid the code of its dependency on createjs, which seems to be abandonware.)</div><div><br></div><div>FYI, I am working on the dictionary block PR, which needs some serious attention. I do think we could use it to greatly simplify the Ensemble code.<br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><font><font>Walter Bender</font></font><br><font><font>Sugar Labs</font></font></div><div><font><a href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br><a href="http://www.sugarlabs.org" target="_blank"><font></font></a><br></div></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><font><font>Walter Bender</font></font><br><font><font>Sugar Labs</font></font></div><div><font><a href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br><a href="http://www.sugarlabs.org" target="_blank"><font></font></a><br></div></div></div></div>
</blockquote></div>