Is this Ardublock repository dead? + Prebuilt .jars #164
Comments
|
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 ***@***.***> 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
<#164>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAaQtmKmUSTeXxYoYed_j6pLG8Z2ebmks5rvKurgaJpZM4M7Qb5>
.
|
|
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. |
|
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 ***@***.***> 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
<#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
<#164 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAaQkJ9gN6KoJf57xKXNaFHUqi9p2gGks5rv3-FgaJpZM4M7Qb5>
.
|
|
Hello Tony, 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). |
|
Hi David, |
|
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. |
|
Hi Tony |
|
Hi { frankhorvat ?}, Re: "change colours, position &/or menu any blocks " -> probably worth an 'Issue' thread of it's own! 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
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. |
|
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. Regards |
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’
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.
That’s a great example of things just agglomerating over time. Should we reorder those then?
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’.
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
True. I'd really like to get that discussion going, but maybe better to start a new thread – out of time myself for today :-(
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! |
|
Thanks Tony |
Sorry for very late reply - hope I'm not too late but, of course, that would be fine. Try github callear net. |
|
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.
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. |
|
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. |
|
Well, definitely, one year later, it seems dead. A pity :-( |
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
and (of course) place them in a folder like this
{Arduino install folder}\tools\ArduBlockTool\Tool
The text was updated successfully, but these errors were encountered: