Hi, Yes, it will be. Wishes,

Comments having spent, admittedly, less than 5 minutes with 3.0, so I might be overlooking something in my haste... 1) Auto error underlining is an interesting feature I have debated over the usefulness with early CS learners. On the one hand they will see errors quickly and can fix them. On the other hand, they see errors quickly and do not learn the value of knowing exactly how to type code the first time correctly, which hurts educationally on tests/quizzes. I wish there was a way to turn it off / on so both valid merits could be used at different times. 2) Tabbing - great! ... except, wait... There is only forced tabbing? Windows might clutter the taskbar up and make it hard to switch to the right class when dozens of classes are open, but at least they allowed positioning them where you would like. I do not currently see a way to rip tabs out into new windows, or split into different frames like Eclipse. We now are allowed to look at exactly one class at a time, maximum? I would never be able to teach with this set up, where I often hide one set of code on my non-projected screen while modifying it, but still displaying a second set of code on a projected screen. I have also found it immensely useful to have students snap one class to the left and another to the right to allow comparison of code, or to allow working on two interacting classes simultaneously. 3) Changes to generics on certain methods have really changed things. Backwards compatibility has been broken with the change of generics with special extends, for example on the getActors method which used to allow any class, but now only allows classes which extend Actor. That messes with a fantastic opportunity to teach Interfaces. Since an Interface can't extend Actor, I can no longer call getObjects( any interface ). Interfaces really should be the backbone of code design in Java and this takes a huge hit to that.

OK. Saw GF 3 frames stuff and for a moment I thought my best scenario had been realised. My students have been struggling so much typing their code into GF 2.4. But then I tried the new stride editor and realised one major shortcoming - you are hiding all the braces and semis. I need something that shows them where the braces go and what they do. The Java preview is nearly there, but unless the proper code is right in front of their noses 100% of the time, my lot will just not absorb it. If we just wanted a block editor for a new 'language', we could just have used scratch. I need something that allows the students to see the shape of Java actual code as they make it. Can we please have an intermediary mode? One that shows all the punctuation as you build? For all it's faults (cumbersome editor much, non-expandable much), Alice has such a mode. If Greenfoot did that, it could potentially become the single best way to teach Java.

Many many thanks, that looks really good, I really like the style of Stride. Unfortunately I'm having trouble using a user library within Stride. The code works in GF3 using the Java configuration but in Stride it refuses to recognise the variable type. I suspect I haven't managed to bind the Javadoc files in correctly as code completion in 'Java' is also not working for this library. Could you point me at the right settings so I can correct this? If I can implement the libraries I'd love to start using Stride from mid November onwards in my classroom.

sgparry: Thanks for the comment. We will consider whether to add an option to always display the brackets and semi-colons. We don't want this by default as we want Stride to be a powerful option on its own (as well as being a lead-in to Java), and the brackets add a lot of unnecessary vertical space and confusion if you're not headed to Java afterwards. dtwyman: That sounds like a bug. Could you email us on support@greenfoot.org, telling us how you added the user library to Greenfoot, and also send us your debug log (see our support page: http://www.greenfoot.org/support ). We will then look into it.

I find it very hard to find syntax errors in Greenfoot 3, especially in longer files. The tiny underlines are almost invisible among all the many other coloured elements of the editor. Once students have spotted the error, students can make the actual error message appear on the mouseover - but my feeling is that finding it is too hard in the first place. Especially, when the error is situated outside the visible window, this makes it tough to even realise there is a syntax error at all. I would suggest adding one or all of the following: 1. Highlighting the erroneous line more aggresively (red background etc) 2. Show an error symbol on the margin (like Eclipse) 3. Add a "Jump to next error" button and keyboard shortcut and hightlight that button somehow when a compile error has happened. 4. I actually liked having an error message immediately appear at the bottom of the screen. The current (3.0.4) is a bit inconsistent IMHO: I'm told down there when I have succesfully saved my file, when it's compiled succesfully, but not when compilation failed. Why not? Apart from that: Thanks a lot for your great and hard work!

@Super_Hippo: That doesn't always seem to work. Actually, I didn't even know it was supposed to work this way, because I was never taken to the error when I hit Ctrl-K. I always had to scroll down and look for little red lines manually, err, visually. That's what I called "hard to find". I've just constructed another example where, yes, suddenly when I hit Ctrl-K or the Compile-button I am taken to the error. But it stopped working again after fixing the first error. Then suddenly after some edits it worked again. Strange. I'll investigate. I also just found out that when I first hit Ctrl-k once, I'm just taken to the error position. When I hit Ctrl-k a second time, the error message appears. If this is a feature, I think I like it! Gives students a chance to think about what might be wrong in that line before seeing the error message.

For me, it seems to be that the first click on compile tries to compile the code and if there is an error, another click on compile will take you to the error. Unless it already compiled itself automatically, then the first click on compile will take you to the error. The error message shows up when clicking on the error itself (so on some red underlined text). At least that's what I am seeing.

@Embee: Highlighting errors in stride is already clear, but in the Java editor could be better. I've added two of your suggestions to our tasks' list. Thank you for this and for your nice words about Greenfoot.