Block "units" format.

[carlosperate]

I'm creating this issue to be able to discuss this topic in an easy-to-follow format.
We can then use the wiki to document the current draft of whatever its decided.

@SebCanet has already added a couple of general ideas to the wiki (good point about having to think about the translations):

My opinion for each new category block :

in /block directory :
a directory for each category which contains 'category.js' file and image

in /generators/arduino/ directory : (do we need sub directory ?)
a 'category.js' file which contains block generators

For translation, do we put all blocks translation in a /msg/arduinoblocks/en.js ? or do we create >/generators/arduino/category/ with block generators and its translation ?

This is the general format that blocks take in Blockly, which should definitely be followed by the blocks included as part of BlocklDuino itself.

I was thinking about this, and I wanted to share some general thoughts about how I think we should approach the requirements for the format itself .

• In my opinion simplicity for the user should be the number 1 priority. This would mean to reduce the number of steps to add a block to be a few as possible and as simple as possible.
• Block "packets" should be modular in a way in which each unit can contain a single block, or a group of related blocks.
• The steps to add a block "packet" should be the same, no matter if it contains a single or multiple blocks, or any other kind of features that we might come up with.
• The format chosen should be able to be generated completely by the block factory (this will definitely need further discussion)

Do you guys have any other thoughts on main requirements?

So, I although what I'm about to propose does not quite follow the Blockly format, I think it could be a good alternative.

We could have each "block packet" be a folder containing at least 2 files, probably more:

• Block/s definition: what normally goes into the blockly/blocks directory.
• Block/s generator: the arduino code generator, what normally goes into the blockly/generator/arduino directory.
• Translation: This could be a directory with a file per language
• Packet definition: a JSON file that defines what blocks are included, where the definition/generator/translation are defined, and the properties required to general the XML that goes into the toolbox.

Now, for this to work we'll need some kind of javascript parser that looks for a general JSON configuration file inside a specific folder (say a folder called extrablocks, could be at the root project directory, could be inside the blockly folder). And then have each "block packet" folder inside the extrablocks directory.

BlocklyDuino
├───blockly
└───extrablocks
    │   extrablocks.json
    ├───block_a
    │   │   block.js
    │   │   config.js
    │   │   generator.js
    │   └───msg
    │       │   messages.js
    │       └───lang
    │               en.js
    │               es.js
    │               fr.js
    └───block_b 
    └───block_c
    └───...

Then the folders could be just copied and pasted directly from this repository and only the extrablocks.json file would need to be modified. In fact, the a Python script or the arduino_web_server.py current script could be created/modified to automatically generate the extrablocks.json file.

@stevoleeto @SebCanet @gasolin Any thoughts?

[stevoleeto]

Haven't had a chance to go through this (and much else) in detail yet, but can't wait to get the time to sit down and put some time into this. With that said, this looks great so far and I'll make sure to provide more feedback when I get the chance.

Edit:
This looks great Carlos. I personally like the idea of the "packets" you have, keeping the different blocks modular and such.

[SebCanet]

Hi, thanks for all this thoughts.
I need translation (of course :-D) because a lot of French STEM teacher use BlocklyDuino or Blockly@rduino, and kids too by themselves.

I agree with you about simplicity, but I think the most important is compatibility for future version, without need of an enormous work.
In requirements, I think about offline, which is a normal way to be sure it can works in any case.

For translation it means we do have to create a specific 'mechanism' different from blockly official one. My version is made upon 'code example' of blockly, we decided to keep for compatibility problem...
Some colleague, which are NOT in any way ease with programmation, computer or anything like that succeded in downloading zip from github, follow my wiki instruction to add their own block by copying existing one.

Spanish Bitbloq version modifiy blocks like that : https://github.com/bq/roboblocks

For now, I have to prepare my holidays because I leave tomorrow for 2 weeks :-D, sorry I'll let it a little and work on it in august.

Thanks a lot, if I can, I'll continue to have a look on your different ideas..

[carlosperate]

Just in case to let you guys know that from today I will be on holiday for a week. I still have access to email (so I'll be able to see responses). Looks like @SebCanet and I will be back at around the same time, so we can then continue looking into this.