You'll want the ∞ to appear when the WHEN I AM [CLICKED v] menu input is changed to PRESSED, if I'm understanding that distinction correctly. I would go further and change the block title text to WHILE I AM, because I think this distinction is non-obvious enough that users will need some redundancy in the labelling to figure it out. For the same reason I support the generic WHILE block, and would even make it primitive, so users see them one below the other right from the start. And I would add redundancy to their names, making them WHILE < > TRUE and WHEN < > HAPPENS.
It'd be nice if the "rule" menu item were called "rule ∞."
It wouldn't be so bad also to turn the block brown, borrowing that color from Scratch, for events, keeping rules orange/yellow. (People disagree on what to call that color.) But if you go along with changing the names, that may not be necessary or helpful.
It wouldn't kill me if that ∞ icon were a little smaller and thinner, by the way. It's really aggressive.
definitely. or maybe "run script while" or just "run while" or "while",
maybe just a help screen... but why while <> true? I would say while <>, I feel like while <> true feels like my biggest snap pet peeve, people doing this: if <condition> then <<true>> else <<false>>
I think just while <> :: control hat is already clear enough. Plus, I feel like people would also know to assume that if it's true, it will run, if it's false, it won't. I don't think saying "true" is unnecessary.
I do understand when <> happens :: control hat since that is more clear what it's doing, and I don't think "happens" is as redundant as while <> true :: control hat
Making the icon appear wouldn't change the semantics of PRESSED, but I'm saying that I think the semantics of PRESSED is already while-like.
Right, WHILE and WHEN already imply TRUE and HAPPENS, respectively, if you already understand the difference between a rule and an event. But if you've never heard of rules and events, and you don't understand the need for such a distinction, then WHILE TRUE and WHEN HAPPENS one above the other in the palette are educative. Just WHILE and WHEN will lead to people thinking "what's the difference?" (as I think we've seen earlier in this topic).
We could make it WHILE < > REMAINS TRUE if that'd make you guys happier.
Repeat after me: The great thing about block programming is that the users don't have to type in your procedure names, so you can make them long enough to explain the meaning to the masses.
so when I am [pressed V]
go to [random position V] is the same as when I am [pressed V]
while <<touching [mouse pointer V]?>and<mouse down?>@delInput@addInput>{
go to [random position V]
}
?
I think so. We could test it out. Or Jens could tell us for sure.
Nope, I was wrong. PRESSED fires one when you push the mouse button down over the sprite. DROPPED fires once when you let go of the mouse button, but only if you've dragged the sprite from where you clicked it.
As far as I can see, CLICKED doesn't do anything ever.
Another great thing about block programming, is that it's super easy to experiment, and figure out what a block does.
I feel like if it were WHILE <> and WHEN <> HAPPENS, people would be able to experiment and find out that WHILE runs while it's true, whereas WHEN <> HAPPENS runs once. I'm just saying, WHILE <> REMAINS TRUE is a little too descriptive, since WHILE already implies REMAINS TRUE.
Just saying, I'm down to having WHEN <> HAPPENS, I'm not arguing against that.
Yeah, that's sort of true, but when you're a beginner and there are a thousand things you're not sure about, it's a lot easier to ask for help than to experiment about everything, and even easier than that if you don't have to ask because the names are redundant enough to be explanatory.
Don't you hate it when you ask for an explanation of something and some smartass tells you the minimum-length text string that in principle disambiguates something, but doesn't actually explain it to you?
P.S. This is why I would still love a better name for MAP that would explain what it does without sounding as if it modifies the actual input list.
P.P.S. Hey, what do y'all think about
? I just thought of it. OF EVERY ITEM OF would be even better, but Jens has a thing about primitive names that don't fit in the palette column.
When I made those help screens, I thought that "compute a function of" in the title doesn't in the least suggest that the input is mutated. But "choose items" is ambiguous, so I thought I had to make it extra clear.
I feel like beginners could figure out the map block reporting a copy of the list if we had the scratch list blocks being relabelable (lol new word), becoming reporters reporting that function done to only a copy of the list.
