Is this Ardublock repository dead? + Prebuilt .jars

[TonyCallear]

Dead - It seems so :-( There doesn't seem to be any response to pull requests?

There are lots of forks of this project, of course, but a it's hard to find one compatible with the latest Arduino IDE (much thanks to facchinm for getting Ardublock working again) and none with .jars you can just use.

Below quoted now irrelevant. Please see releases. https://github.com/taweili/ardublock/releases

If anyone is looking to just use Ardublock there are some prebuilt .jar in the JARs folder here... https://github.com/TonyCallear/ardublock/tree/TC-slim-compatible-1.6.12

• I recommend the "slim" .jar as it contains a lot of improvements (IMO) but lacks the large number of specific hardware draws.

• The "Full" .jar has a lot of improvements (IMO) and but retains a large number of specific hardware draws which have not been debugged in a while.

• The "master" .jar has all the specific hardware draws, should open old *.abp file, but retains some old bugs from taweili's 'master'.

Direct links... https://github.com/TonyCallear/ardublock/raw/TC-slim-compatible-1.6.12/JARs/ardublock-all-slim-compatible-1.6.12.jar

https://github.com/TonyCallear/ardublock/raw/TC-slim-compatible-1.6.12/JARs/ardublock-all-full-compatible-1.6.12.jar

https://github.com/TonyCallear/ardublock/raw/TC-slim-compatible-1.6.12/JARs/ardublock-all-master-compatible-1.6.12.jar

and (of course) place them in a folder like this {Arduino install folder}\tools\ArduBlockTool\Tool

[taweili]

Hi Tony,

Sorry that I have totally been swamped in the past few months. Thanks a lot for your contribution. I will add you to the contributor list to my repository.

David

On Wed, Apr 12, 2017 at 6:47 PM, TonyCallear notifications@github.com wrote:

Dead - It seems so :-( There doesn't seem to be any response to pull requests?

There are lots of forks of this project, of course, but a it's hard to find one compatible with the latest Arduino IDE and none with .jars you can just use.

If anyone is looking to just use Ardublock there are some prebuilt .jar in the JARs folder here... https://github.com/TonyCallear/ardublock/tree/TC-slim-compatible-1.6.12

I recommend the "slim" .jar as it contains a lot of improvements (IMO) but lacks the large number of specific hardware draws.

The "master" .jar has all the specific hardware draws but retains some old bugs from tweili's 'master'.

Direct links... https://github.com/TonyCallear/ardublock/raw/TC- slim-compatible-1.6.12/JARs/ardublock-all-slim-compatible-1.6.12.jar

https://github.com/TonyCallear/ardublock/raw/TC- slim-compatible-1.6.12/JARs/ardublock-all-master-compatible-1.6.12.jar

and (of course) place them in a folder like this {Arduino install folder}\tools\ArduBlockTool\Tool

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/taweili/ardublock/issues/164, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAaQtmKmUSTeXxYoYed_j6pLG8Z2ebmks5rvKurgaJpZM4M7Qb5 .

[TonyCallear]

Thank you, David. It's very good to hear from you! So glad you're fine and haven't forgotten about the project and I do hope it's been a good kind of 'busy' time for you.

Using my prized 'contributor' github status :-) I've just accepted Martino's contribution allowing ArduBlock to work with Arduino IDE > 1.6.11. I've created a 'release' at this state too - there's a .jar in the release for people to try out even if they don't want to compile it themselves.

It's taking me a while to remember what I was thinking about over a year ago but in a short while I'll be integrating my improvments from a year ago and a few over the last week (pull request #146 I think it was) - please say if that's not OK with you.

[taweili]

That would be awesome. Also, if you like, I will write a post on ardublock.com about you the new contributor. :)

David

On Fri, Apr 14, 2017 at 10:15 PM, TonyCallear notifications@github.com wrote:

Thank you, David. It's very good to hear from you! So glad you're fine and haven't forgotten about the project and I do hope it's been a good kind of 'busy' time for you.

Using my prized 'contributor' github status :-) I've just accepted Martino's contribution allowing ArduBlock to work with Arduino IDE > 1.6.11. I've created a 'release' at this state too - there's a .jar in the release for people to try out even if they don't want to compile it themselves.

It's taking me a while to remember what I was thinking about over a year ago but in a short while I'll be integrating my improvments from a year ago and a few over the last week (pull request #146 https://github.com/taweili/ardublock/pull/146 I think it was) - please say if that's not OK with you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/taweili/ardublock/issues/164#issuecomment-294160831, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAaQkJ9gN6KoJf57xKXNaFHUqi9p2gGks5rv3-FgaJpZM4M7Qb5 .

[karlTH]

Hello Tony, i still produce some block for ardublock.

here is a link to the developpement : http://www.duinoedu.com/dl/logiciels/arduino/arduino_augmente/version_duinoedu/

it's a package arduino + 3 versions of ardulock + librairies + add on in arduino tools (leap motion, guino, matrice).

[TonyCallear]

Hi David, Yes, sure... whenever you have some time to update the blog it would be really good to keep it looking lively.

[TonyCallear]

Hi Thomas, I have downloaded your ArduBlock related stuff and will look at it ASAP.

Mainly though, I'm feeling bad in case I've have broken some of your code in ArduBlock. Do please check it out (see releases for a quick look) and see if the functionality you need is still there.

[frankhorvat]

Hi Tony Thanks for the revival - we have been using Thomas's version for a while now with great success as it has many blocks of "newer" items & we are quite comfortable with the format esp. the Maxi version - so we are currently reviewing your updates. Many look good & we'll test further to see if some of the bugs we have identified have also been rectified. One thing I would like identify as an issue is any proposed plan to change colours, position &/or menu any blocks are currently located in. We effectively now have a defacto standard that will cause confusion especially if it changes at every revision. Also for what we do - we need all of the various manufacturers menus/blocks

[TonyCallear]

Hi { frankhorvat ?}, Testing is good! And time consuming! Thank you very much for offering.

Re: "change colours, position &/or menu any blocks " -> probably worth an 'Issue' thread of it's own! I guess you've been looking at the latest 'release'? Thank you. https://github.com/taweili/ardublock/releases/tag/beta-20170414

I do understand that, if you’re selling/supporting hardware on the basis it can be used with ArduBlock you’ll not want to annoy current customers by changing the interface in ways that don’t benefit them. New customers?

When using ArduBlock educationally (my main use) – no one would want to re-do instruction sheets and videos to correspond with a new interface until this has considerable added value. No one wants to ask an individual student to use a different interface if they’re already competent with the first one. There may be more pressure though to make things as intuitive, logical and appealing as possible for new groups of students as they’re introduced to ArduBlock. Some changes just need doing if there’s a clear problem with users finding/distinguishing blocks.

So, having said all that I do still think the de-facto interface is bad – really quite bad – clearly something that’s agglomerated over time, as you'd expect in beta, rather than being well thought out. That doesn’t mean I think I’ve found the perfect solution to the UI – but I would argue for the possibility of change.

Solutions might include

• making Ardublock skinable – though I’m not volunteering to do this beyond pointing out one can compile using different ardublock.xml’s - and I’d upload the .jar’s of two or three different skins.
• Producing a v1.0 release with de-facto layout and setting some goals for v2.0. Having something ready for a v1.0 release and some coding guides would be a good idea whatever else is happening.
• Something else ??

Thomas obviously generates a lot of useful blocks and I do hope he'll be tempted back if things look a bit more lively here.

[frankhorvat]

Thanks Tony

I'm in a similar situation to you in that I have numerous educational programs that we run & changing things too drastically would require a lot of effort redoing course work. We also use a number of different manufacturer's hardware hence the need to keep them included. I see this as one of ArduBlock's greatest features as it gives a student the ability to use a block with an image of the item they are working with rather than focusing on actual "coding" ie set digital pin xxx etc

I'm not sure what you mean when you indicate users have difficulty finding/distinguishing blocks although not having the manufacturers blocks in alphabetical order is a bit of a pain. Can you provide some examples of what you consider bad?

It also occurred to me that we have been talking about 2 different parallel versions. The current "official" version of ArduBlock has many inconsistencies mainly due to the lack of any recent development & I can see why you would call it bad. This has actually led us to use the version that that been in consistent but parallel development by the duinoedu team & the one which we refer to as the defacto version. It would be very good if their development could be incorporated back into current "official" version as it corrects some inconsistencies as well as incorporate many new features.

I'm still reviewing your recent suggestions & while I can see where you believe we should be going the biggest shock was the incorporation of the Scoop capability (which we reserve for our intermediate & advanced students) across the TASK/CONTROL menus. Also not sure why you changed the colours for the CONTROL, PINs, CONSTANTS and COMMUNCATIONs menus - was it a form of version control so as to distinguish it from the current "production" version?

I agree that going forward there needs to be put in place some sort of governance (which would include version control) at both a development & UI perspective. I believe this would benefit both developers as well as consumers of the environment.

From an electronics hardware perspective this visual programming environment is still way ahead of all of its competition - we just need to ensure that the various parallel manufacturer developments can be included. One thought in this space is to incorporate a facility that would allow you to add/import the specific manufacturer menus you need. This would serve to cater for those who require a less cluttered menu list including those who just want their specific hardware menus for their programs to groups like ourselves that use many different hardware manufacturers.

Overall - it looks like we are in for some exciting developments as this environment continues to evolve. BTW - I've used the term MENU to try & describe the various options that are presented on the left side of the work space but use the term PALETTE when training others

Regards Frank

[TonyCallear]

Thanks Tony

I'm in a similar situation to you in that I have numerous educational programs that we run & changing things too drastically would require a lot of effort redoing course work. We also use a number of different manufacturer's hardware hence the need to keep them included. I see this as one of ArduBlock's greatest features as it gives a student the ability to use a block with an image of the item they are working with rather than focusing on actual "coding" ie set digital pin xxx etc

I can see where that’s a good and popular way of using Ardublock. I’m never going to have all of that kit though and from a Design and Technology (school subject in the UK) I’m more interested in using the native features of the Arduino boards – with the odd bit of cheap generic hardware attached (Servo – LCD display – Bluetooth – Motor controller – Relay board) and building these into simple prototype products. Pins are more important to me :-)

I haven’t seriously used Ardublock with students for nearly a year. Some of the updates that brought new manufacturer’s blocks also seemed to break some core functionality in using basic pins and servo’s; also introduced blocks for manufacturer hardware into what I’d term ‘general’ block draws (pallet’s in your terminology?) which was very confusing and made it hard(er) for me to trim down the interface into something less distracting/confusing. Feeling more positive now! But it did make me just ‘do something else’

I'm not sure what you mean when you indicate users have difficulty finding/distinguishing blocks

Various degrees of vision impairment, difficulty processing text and too much information on-screen at once, colour blindness – using cheapish projectors for demonstrations in classrooms with little lighting control – printing things out in monochrome - that sort of thing. I tried to put blocks in places where students looked for them and therefore asked me fewer questions but that effort was brought short, I have to admit.

although not having the manufacturers blocks in alphabetical order is a bit of a pain.

That’s a great example of things just agglomerating over time. Should we reorder those then?

Can you provide some examples of what you consider bad?

It’s just way too cluttered - Too many options for those students genuinely trying to solve a problem and too many distractions for those who are disengaged and getting ‘click-happy’. It just kind of looks ugly? The blocks developed latest have the most eye catching colours, an unseemly attempt to grab attention! The whole 'SCoop thing is a bit weird to me - more later.

I'm still reviewing your recent suggestions & while I can see where you believe we should be going the biggest shock was the incorporation of the Scoop capability (which we reserve for our intermediate & advanced students) across the TASK/CONTROL menus.

I think there’s a solid argument for not including multitasking/event driven programming at all. I think there’s a good argument for including it too. I don’t think there’s a correct answer, what seems ‘right’ is going to depend on your student’s ability and previous experience – what they need to do now – and where you’ll be guiding them next. In the UK many students will have used Scratch and (much more recently) the BBC Micro:Bit - where multitasking/event driven programming is easy.

The half-way-house of putting 'SCoop tasks" in a separate draw raised too many student questions at the wrong time and just didn’t work for me – and calling the draw ‘Scoop’! not something I wanted to explain to students. I think it's like that because of how it was developed in Ardublock and what we know about the hardware limitiations of actually using it. I think it’s more hidden from beginners in a Tasks draw (menu) because they don’t even (have to) use that draw to write simple programs

I agree that going forward there needs to be put in place some sort of governance (which would include version control) at both a development & UI perspective. I believe this would benefit both developers as well as consumers of the environment.

True. I'd really like to get that discussion going, but maybe better to start a new thread – out of time myself for today :-(

One thought in this space is to incorporate a facility that would allow you to add/import the specific manufacturer menus you need. This would serve to cater for those who require a less cluttered menu list including those who just want their specific hardware menus for their programs to groups like ourselves that use many different hardware manufacturers.

That’s a good thought! I do hope things head that way – for now I’d just like to get out a v1.0 with a rock solid performance in the core board/generic hardware functions, all the current manufacturer blocks included but contained in their own block draws (menus?) and organized so that Ardublock.xml can be easily edited to produce different skins. And! a way to stop students closing Ardublock without saving their work! See pull request #166 for a very limited solution, where closing the Arduino IDE still silently kills Ardublock :-(

--

Regards and apologies for just running out of time to make this more intelligable!

[frankhorvat]

Thanks Tony I was thinking that rather than cluttering up this thread - can we take this off-line for further discussion?

[TonyCallear]

Thanks Tony I was thinking that rather than cluttering up this thread - can we take this off-line for further discussion?

Sorry for very late reply - hope I'm not too late but, of course, that would be fine. Try github callear net.

[letnialynne]

Hi Tony & Frank,

I'm excited to find this discussion as it addresses many of the UI issues that concern me when deciding to use Ardublock verses other bloc style languages. I've been tasked with designing an engineering curriculum at an independent k-8 STEAM school in the Boston area. I'm looking at a maker space model that creates yearly installations throughout the school verses doing desktop projects. We hope to enhance the school environment though electronic art, environmental monitoring and iot devices.

Ardublock is so close but the UI issues have me concerned. Distraction is a big problem for young kids and a cluttered workspace makes for a cluttered brain. Has there been any headway into the issues dicussed here especially 1) Autosave because kids are so use to everything auto saving that they just don't understand why this software does not. And it really increases frustration for both the instructor and students.

2) Having the ability to slim down the menus activated so that students can focus only on the hardware available at each institution.

Those 2 issues would make ardublock the clear winner in the bloc world. The arduino integration is there, code commenting, being able to pull your blocks off to the side out of the main loop effectively commenting them out and the shear number of basic blocks included set ardublock apart.

Looking forward to an update on these issues. Many Thanks, Andrea

[Arhat109]

Thanks to the developers who continued and revived this great project! He is simply irreplaceable in the training of children 8-12 years Arduino and programming in General.

TonyCallear, You were interested in color schemes, tried both, I think the original from Taweili is preferable.

[q2dg]

Well, definitely, one year later, it seems dead. A pity :-(