[Sugar-devel] Gradual reorganizing of Music Blocks codebase

[Anindya Kundu]

Got it. So, are we going to build on top of Christopher's work or do we
start afresh?

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.

Also, he has created constructs for creating custom dictionaries, I'm not
sure whether we want that too.

On Wed, 9 Sep 2020 at 02:04, Walter Bender <walter.bender at gmail.com> wrote:

>
>
> On Tue, Sep 8, 2020 at 3:57 PM Anindya Kundu <anindyaak007 at gmail.com>
> wrote:
>
>> 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.
>>
>> Meanwhile, I can help with the dictionary stuff too. Please do let me
>> know what I can do.
>>
>
> 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.
>
>>
>> Also, thanks Vaibhav for the resources, and Devin, I'll keep you posted
>> when I begin.
>>
>> On Wed, 9 Sep 2020 at 01:14, Walter Bender <walter.bender at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 8, 2020 at 10:39 AM Anindya Kundu <anindyaak007 at gmail.com>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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?
>>>>
>>>>
>>>> *Anindya Kundu*
>>>>
>>>>
>>> Sounds great.
>>>
>>> Before you jump into coding maybe you can create a master issue to track
>>> proposed changes and progress.
>>>
>>> (One obvious TODO would be to rid the code of its dependency on
>>> createjs, which seems to be abandonware.)
>>>
>>> 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.
>>>
>>> --
>>> Walter Bender
>>> Sugar Labs
>>> http://www.sugarlabs.org
>>> <http://www.sugarlabs.org>
>>>
>>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> <http://www.sugarlabs.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20200909/bf8b2a17/attachment.htm>