Request a new command, feature, or improvement
- Posts: 326
- Joined: Jul 2nd, '17, 13:47
Since I first came to GP all those moons ago e.g 3 months ago in July 2017 :) - I've been struggling with the animate block
- Does its job perfectly :)
- Does exactly same as forever block in Scratch but called something different
- No other loop command block equivalent
Obviously, calling it forever
would cause confusion with the new while true
Suggestion - rename it to animate forever
or forever animate
to make it more obvious to Scratchers that this is the block that replaces old forever
One suggestion - create shadow blocks for all other loop structures. So we'd end up with extra blocks:
repeat 10 animate
for i in 10 animate
If this was done - then I'd suggest removing animate itsef and replace it with
while true animate
So we'd end up with 2 extra blocks in total but consistency (and very easy to understand and explain to both newcomers to block programming and Scratchers)
Alternatively add drawers to all the loop blocks to add animate true
There is a slight consistency issue that when drawer is closed we'd effectively be saying animate false but it'd be a small price to pay I think
- Posts: 13
- Joined: Mar 29th, '17, 15:26
It has already been changed, but another idea is for it to look like this:
- Posts: 356
- Joined: Sep 11th, '15, 14:42
After having gone back and forth on this issue, I'm inclined with switch the label back to "forever", like Scratch.
Here's my thinking.
First, I'd rather not add a "wait" options on the other loop blocks (but thanks for the suggestion, Gosha). Those who wish to use other loop blocks such as "while", "for" or "repeat" for animation can add a wait block. There are several reasons I prefer this appraoch. First, GP is sometimes uses as a transition to Java or Python, and the loops in those languages don't have any notion of built-in waits. Second, GP is built in itself and its code uses the same loop blocks that appear in the palette, often for processing large amounts of data behind the scenes (e.g. the bytes of a project file). In those applications, there's no need for animation and we want the code to run as fast as possible. Adding a optional "wait" parameter would slow things down because the paraemter would need to be checked even if the wait option wasn't used.
SimpleSi has objected that the "forever" loop is different from all the other loop blocks, a good point. One might address that problem by omitting the "forever" loop, which isn't used at all in GP's own implementation. People who wanted to do animation could use a "while true" block and add a wait block. However, that approach, which is consistent and minimal, requires confronts a user coming to GP from Scratch with a lot of new concepts at once: while loops (which Scratch doesn't have) and the need to add a "wait" block to get smooth animation. Finally, they'd need to guess that "while" is the closest equivalent to "forever". That's a lot fo places people could get stuck.
Considering all this, I think it's okay to keep the forever block -- a very convenient block for beginners and experts alike -- even though it is different from all the other loop blocks in having a built-in wait. I'd hoped that changing the name to "animate" or "forever animate" would emphasize that built-in "wait", but those names have a downside: it is not immediately obvious to students coming from Scratch that "animate" is the same thing as the Scratch "forever" block. So I think maybe its best to go back to calling the block "forever", as recommended by the students of the Acera school several years ago (when the block was originally called "animate").
When people want to use other kinds of loops for animation, we can point them to SimpleSi's Wiki article explaining how to do that. Hopefully, by the time a GP user wants to animate a "while" or "for" loop, they'll be ready to learn about "wait".