Re: [Sugar-devel] Gradual reorganizing of Music Blocks codebase

[Walter Bender]

On Wed, Sep 9, 2020 at 2:17 AM Anindya Kundu  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 
> wrote:
>
>>
>>
>> On Tue, Sep 8, 2020 at 3:57 PM Anindya Kundu 
>> 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 
>>> wrote:
>>>


 On Tue, Sep 8, 2020 at 10:39 AM Anindya Kundu 
 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
 

>>>
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>> 
>>
>

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [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  wrote:

>
>
> On Tue, Sep 8, 2020 at 3:57 PM Anindya Kundu 
> 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 
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 8, 2020 at 10:39 AM Anindya Kundu 
>>> 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
>>> 
>>>
>>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> 
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel