carlosperate
commented
8 years ago Hi,
While simple way to transfer blocks between BlocklyDuino and Ardublockly would be fantastic, there are a couple of additional features on Ardublockly that means it will require some extra attention. I'm currently working on a simple way to expand the block catalogue, and as part of that development I'm trying to figure out the easiest way to abstract the extra features in a way that reduces the impact on the "blockly blocks" code (so that ideally transferring these blocks could be simpler).
I'll address your other points individually for clarity:
- 100% localized for the kids we aim at
The translation is something that has started but still needs to be fully implemented on Ardublockly. Currently only the default blockly blocks change language when selected from the menu, the rest still need to have their strings moved into the messages files. There is a bit more information in https://github.com/carlosperate/ardublockly/issues/17, including a list with the remaining tasks.
Apart from that I also need to internationalise the front end interface, but those string files would be kept independent from the blockly stuff.
- Chrome OS is what we use. So upload via Codebender.cc. Everything that points to running some local program cannot be shown
This is definitely a different need that what originated Ardublockly. On my initial requirements we had a very restrictive offline environment (couldn't even run Chrome), and in that case having this type of offline application was a necessity. I must admit that I have though about this suggestion before, but at the moment it feels like I would be duplicating effort for the same feature, with the disadvantage of not being able to expand to other interesting Arduino boards (just started looking into Arduino for the esp8266 :).
- I fail to see the advantage of showing the Arduino code. Should be optional, the kids will only be distracted by seeing the code, a separate tab like in classic has my preference.
Showing the Arduino code and how the changes to the blocks actually translate to the written code was one of the original driving forces for this implementation. The idea being that the blocks are used only as an introduction to the programming concepts, and then the kids could be transition to start writing (or at the beginning modifying and expanding) real Arduino code. Based on the same idea I would also like to add a feature where a selected block would highlight the relevant Arduino code, to emphasise this correlation even more.
Of course this doesn't mean that approach should work for everybody. The "classic" interface (which currently is probably broken) could be used to hide the code if you wish.
Alternatively I've always wanted to add a "expand workspace" mode. Where a button would be added that expands the blockly workspace to take all the main space area, pushing the code and xml containers below. Very similar to the responsive mobile interface that you would encountered when accessed by a cell phone (you can try http://ardublockly.embeddedlog.com/demo/ on your phone to see what I mean).
- Why not just have a fork of blockly, with this a specific demo? Don't you have to merge blockly from time to time into ardublockly? Ok minor point
Blockly is a git subtree inside the Ardublockly repository, which means I can pull from upstream blockly just like I would if I had a fork. In fact this was quite convenient during the initial phases, when every time I was able to spend some time working on Ardublockly there was interesting changes to pull from upstream, and I was running from the uncompressed source code. In this case having a fork would mean pulling into my fork, doing any changes to blockly core, and then manually move all that to Ardublockly.
I see you did some specific choices in your blocks and what to expose. It seems to me we need some committee to decide on best blocks for Arduino, or we will end up with all incompatible implementations.
That was exactly what we were thinking at BlocklyDuino (https://github.com/BlocklyDuino/BlocklyDuino/issues/41). Unfortunately as exited as we all got, in my case life happened and when things settled down a few months ago it looked like things didn't get very far. To be honest that is something I would really like to do, but I guess we need to get the ball rolling again.
bmcage
I started my own new fork of blockly based on BlocklyDuino. Now I find this project. My needs are a bit different though. Mainly I work for non English speakers.
It would be good to somehow make sure we use the same blocks, so people can move between implementations.
My translatable arduino blocks: https://github.com/bmcage/blockly/tree/arduino/blocks Most could be incorporated directly in ardublockly.
Used in Dutch here: http://ingegno.be/Manuals/Blockly4Arduino/demos/blocklyduino/
Some other things I needed also present: A Define part to create floats, integer up front
I'm unclear on what best to do with my effort. I could fork ardublockly and restart, but I have specific needs:
I see you did some specific choices in your blocks and what to expose. It seems to me we need some committee to decide on best blocks for Arduino, or we will end up with all incompatible implementations.