Sharing blocks and collaborating

[bmcage]

I see you left a note on ardublockly: carlosperate/ardublockly#78

Better would be to work together towards common blocks for arduino to use with our blockly versions.
I like the approach of ardublockly very much, so I contributed to that project. It is now fully translatable. Next I keep all my new blocks compatible with ardublockly, and do PR to integrate them in ardublockly.

For example, the component blocks of my version (see arduino block in http://ingegno.be/Manuals/Blockly4Arduino/blockly4Arduino/index_en.html?url=examples/Blink.xml ) are available in
carlosperate/ardublockly#76

We should work together more, instead of having too many projects with their own blocks.

That said, I do wonder how you pulled of the codebender integration. I will check that out, at the moment I need to copy/paste code for that 👍

[SebCanet]

That's not me who left this note :-D
I saw that you did a really great job ! I'm very impressed.
In fact with Carlos we tried to make BlocklyDuino on the road again a few months ago, that's why Gasolin recreated it's github, and that's why there's this blocklibrary : https://github.com/BlocklyDuino/blockslibrary

I really want to share, stop wasting time to create the same thing. I think we have a lot of work to modify our version and make them totally compatible. I cannot change anymore what I created (functionnality I mean) because it's very appreciated in France and Quebec, choosed by STEM trainer at national scale and already used in lot of schools !!!

The best is to make something easy to enhance with particular function, this way anyone can do what he wants. How can we merge what we have in common ?

[bmcage]

I work from a fork of ardublockly, so the question is, can you merge to the core blocks of ardublockly or not? It seems to me you have a lot of extra blocks, and you follow a different paradigm, so it would not be easy to change....

However there are some core parts that are important functionality and if all versions could agree on that, that would be great:

1. full translatable. A PR of me made ardublockly fully translatable. I see Blockly-at-rduino is a mix.
2. arduino types present in ardublockly, avoiding kids to make mistakes in a strongly typed language
3. my PR in ardublockly that adds common variable names for components. As an extension of this, I strongly believe my component approach is useful for kids (see http://ingegno.be/wp-content/uploads/2016/03/03_sketch.png ), but those are just extra blocks building on the common variable names, a GUI can expose them or not.
4. should arduino blocks have type? I intend a PR for ardublockly to give all blocks type.

It might not be possible to change the functionality that you have, but that does not mean the blocks of ardublockly cannot be present in your version. After all, the GUI does not need to expose all blocks present. Ideally, we work with forks of a common base, adding our own GUI on top of it and some extra blocks we try to merge upstream via PR. The main question is then, which version to be the base. For me that would be ardublockly version of blockly.

Ok, as my project was young, I could easily redo my blocks to follow the ardublockly way of doing things (I started from blocklyduino), for you that would be much harder. Something you should discuss with with carlos I suppose!

Now I go steal some of your blocks :-)

PS: I contacted codebender, using their plugin to upload outside codebender is not supported, and will probably break from time to time. They said for now you should copy/paste in their official plugin, and that they are working on a 'blockly type of integration', but that it was not ready. So some way generated code could be used directly with their plugin. Perhaps they also work on a blockly version, who knows!

[SebCanet]

Hi,
as I'm finishing Blockly@rduino, I have a little time to correct bugs and issues.
I posted something in Carlos issues about working again on block definition. But about what you say, can you explain a little bit:

1. why do you say it's a mix, Blockly@rduino is not not fully translatable ???
2. totally agree about types.
3. I like a lot your idea on assigning PIN on Arduino card, because my work is for kids too I'm very interested. that's why we added the multi toolbox functionnality: one toolbox for exeprt, one for newbies, one for....
4. I don't understand what you mean.

Totally agree about respecting core, and work only on GUI. In my last release I created special folders more explicit and to explain really who made what.

Thanks a lot for your work !!!

[bmcage]

Did not look again at the code, quick answer here:

1. For full translatability, all strings must be from Blockly.Msg. , and some of the blocks you have don't have that. Most do though, so not the biggest issue. Some of the core errors should also be translated, I added some of that to ardublockly.
2. I'll work out the PIN assigning some more following month, we go to Makerfaire Rome with a project, and blockly is a part of it.
3. in blockly blocks with no type can always follow another block. As arduino blocks have no type, you cannot create specific logical blocks that don't allow to be followed by an arduino block. Eg, I add component blocks in which you say what components you link to each other, so like littlebits. Now, a child can put a for loop or a print serial block to follow such a component block, which is wrong and has no meaning. The solution is to give all blocks a type ('arduino code block') and then you can also put other logic on the canvas that does not mix with that.