[Sugar-devel] Gradual reorganizing of Music Blocks codebase

Walter Bender walter.bender at gmail.com
Wed Sep 9 05:17:28 EDT 2020


On Wed, Sep 9, 2020 at 2:17 AM Anindya Kundu <anindyaak007 at gmail.com> wrote:

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

I think we can 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.
>

Yes. That is a problem.

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

That still might be handy for some applications. I imagine referencing a
dictionary that is not a turtle name would create a custom dictionary.

>
> 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>
>>
>

-- 
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/87875626/attachment-0001.htm>


More information about the Sugar-devel mailing list