Components

[bmcage]

This branch builds upon #73 to offer component blocks:

1. you have an 'arduino' block, which also sets the board.selected automatically (you can change uno to mega, to ...)
2. the arduino block has a mutator to add pins that are used in your construction. At the moment digpin, anapin, pwmpin, and double digpin (for things like stepper or distance sensor).
3. there are components to attach to this. At the moment servo, stepper, ledleg, ledstrip. This sets variable names for these components.
4. then extra blocks are present so as to use these variable names. In my version I remove the old stepper and servo setup blocks from my toolbox, leaving a single way to work with components.

I'm working on a pushbutton as a component, then a generic digital and analog sensor.
In my branch digitalread/write is possible on variables. In default ardublockly not. So to have components really useful, some way to use the generic variable names in analog/digital read/write is needed too, perhaps a version of #70, or some other way.

Example use: http://ingegno.be/Manuals/Blockly4Arduino/blockly4Arduino/index.html?url=examples/BlinkNoDelay_nl.xml

[bmcage]

Added extra components so as to cover all bases:

1. generic digital read/write and analog read/write components. In my branch this allows me to remove the digital/analog write/read methods on variable names. You have two options now, you use eg digitalwrite on a pin#, or you do digitalwrite to a component that exposes a digitalwrite type block, eg the generic digital output component.
2. Added a button component which does general button press handling. This is a typical use case for all type of buttons. To add double click would be nice addition

Ideally for me you agree to this component idea. In my view, it is not required for a GUI that builds upon the blockly core to expose all blocks present. It is possible to not include component blocks. The idea of components will be nice for some use cases. However, to mix component and not components is not a good idea in my opinion. So in my version, I don't expose the stepper init block which is not a component, leaving only the component way of adding a stepper.

NOTE: You will see I call my normal code blocks ARD_BLOCK, as in this.setNextStatement(true, 'ARD_BLOCK'); and others. I find it really annoying that all blocks are null blocks, as null blocks can be added everywhere. Ideally the blocks of the core are perhaps null, but all extra blocks have a type, eg the ARD_BLOCK I use here. Then one can filter on actual blocks, and have parts that cannot mix, which with all null blocks is impossible to achieve.

[carlosperate]

Wow, this is a rather large PR, that might take me a while to find some time to have a look properly.
It also looks like it include some of the changes from #73 ?

I won't be free until the weekend of the 20th, and I doubt I'll have much time after work during the week. My plan is to prioritize #73 first, as it's been a while since it's open. I want to play with the idea of creating this "instance of things" based on variables to be able to separate objects.
Then we can start looking into breaking down this one a little bit into smaller chunks for merge.

[bmcage]

Yes, it needs #73 so however that evolves I must reintegrate here.
There is no rush. We have a workshop Saturday with children where we will use it a first time, so some more bugfixes might be coming.

Then I want to have a component for a distance sensor, which also needs two pins like stepper (though it can be programmed too via pulseIn and normal functions I assume).
But I'll not add that also to this PR. This PR covers all components as present in ardublockly in other ways + the ledstrip and led stuff + button. The last two could be separate PR but with the translation stuff there is quite some overhead for me in juggling different PRs.

If you want to play around with the new blocks without adding them to ardublockly GUI (as that is not in this PR), they are all present on my version online.