Yeah I know. Consistency is the hobgoblin of small minds. ;~)
@ego-lay_atman-bay: I was wrong about this. I withdraw that comment. But I stand by generic WHILE. :~)
Oh. I guess you're right. Sorry! Still, that was what started him down this road.
Back when Alan, Dan and Ted were developing the semantics of a constraint solver for the "wandering letters" problem in Squeak they also distinguished between events, which they named "When", and rules which they named "When always". That's what motivated me wrt to the naming "When" and to use the infinity symbol as a distinction marker. If you look closely I didn't just use the infinity character but actually designed my own variant for Snap! that I made to resemble a "chain-link" or "hook". The reason I want to use such a symbol instead of the explicit word "always" (which is how I would still pronounce it when talking about these hat blocks) is to show something unambiguous from its translation on the block itself, similar to the "location pin" method icon that denotes a sprite-local custom block.
"While" is a universally known loop, and I'm always showing how to build it yourself in Snap! I think that our hat blocks, which are triggers for forking processes in a concurrent system, are fundamentally different from control structures in a single-threaded programming language. Therefore I'd rather avoid naming them something that beginners (and even experienced programmers) might falsely recognize as something they were made to use in Python or Java.
I did notice that it was a homebrew ∞. I like the part about one leg going over the other leg! I just think it could be a little smaller.
Oh, so you're sort of thinking of the ∞ as part of the block title. If that's how you want users to think about it, then I think it should be on the title line (as the location pin is, for local methods) rather than off in space. Even if that meant making it a lot smaller. (By the way, "when always" doesn't sound like English. If anything it sounds as if it's always true!)
I sort of see why you're afraid "while" will make people think of a loop in those other languages (or our language if you load the iteration library!), but it is sort of a loop. It keeps checking repeatedly. But yes, I get that a hat block isn't like anything in Python. :~) Could we compromise on
? Because I don't think the difference between a rule hat and an event hat is anything like apparent to beginners. You're suggesting that they always want events, but I don't think they know what they want, and anything we can do to help them figure it out is all to the good. I like WHILE better than WHENEVER, but I don't think the particular word is as important as it being a different word from WHEN.
Okay, from important stuff to aesthetics: That super-wide make-a-block dialog is hideous, and the box to enter the title kinda gets lost, even more so because the hat block is so huge. I would make the hat block 50% size compared to the others; those block pictures are just icons, not runnable or draggable out or anything. But if you hate that idea, I'd settle for two rows of two block shapes. We could even strike a blow for functional programming by putting Reporter and Predicate in the first row, and Command and Hat in the second, but I don't insist on that. (But if not, Command and Hat in the first row would be better than splitting Reporter and Predicate from each other.) Maybe two rows even if you do agree to shrinking the hat block. (It wouldn't have to be 50%. Maybe 75% would be enough to make it not jump out so much.)
Another thing about the aesthetics is that having the category default to Other isn't so great because it makes the fact that one of the block shapes is lit up less obvious. Back in BYOB it defaulted to Motion, iirc, and that made the invitation to select one of the shapes much more apparent. If it has to be gray, then I think we should draw rounded rectangles around the block shapes so they're obviously buttons.
Oh, one more. I'm not sure, but I think the ∞ would look better if it were somewhat more to the left -- not aligned with the W of WHEN, just smooshed over by its own width, or even half its width. As it is, in the center of the hat bulge, I keep seeing it as eyes. This is supposing I don't talk you into putting it in the title text, just like $location or $flash.
Like this:
I think it's less goofy-looking this way.
in hindsight I'm convinced that the previous "forever... if..." semantics of our generic "when" hat block were just plain wrong, and not at all what users expected, because every other hat block in Snap! would only trigger on a state change, and not depending on state itself. Therefore, in my mind, the new "rule" semantics is really little more than an experiment that leads us - perhaps - to dive deeper into developing future constraint programming / observer pattern features into Snap. I'd be quite happy to discover that our community wouldn't ever use it at all.
Therefore I've decided to again rename the according button in the make-a-block dialog to "Event Hat", because that's the default behavior, and I'm sure it does what people are expecting it to do.
Aligning the chain-link / always icon with the label text is problematic, because there are now also sprite-local custom hat blocks, so both icons would clobber up the same line of label text. Naw, I'm happy with using the currently unclaimed real-estate of the "hat bump" to prominently display a symbol that'll jump to the eye.
The default category for custom blocks depends on the location from where you make one. Only if you invoke the make-a-block feature form the scripting area's context menu will the category be "other". If you do it from the palette, it will be whichever category you do it from.
But I do always do it from the scripting area! That's where my cursor lives, because it's where the Block Editor opens.
What do you think about moving the icon left?
when [ V] key pressed :: control hat
yeah, I like it too. :)
I agree with this, I feel like the icon is very close to the input compared to the text at the beginning:
but then again it would maybe feel weird being so off-centered.
no, you're wrong about the when key pressed hat block. That's a singular event, not a hidden forever loop. The reason why you keep getting triggers is because your physical keyboard and your OS keyboard driver keep actually sending you key events repeatedly! You can change and even disable that altogether in your system setting.
oh.
Yeah, you've convinced me about this. Too bad we have to support old projects! :~) At the time, I couldn't understand why (some) users were clamoring for custom hat blocks at all, other than the same feature closure instinct that I talked about earlier: If there are custom blocks, and there are hat blocks, then of course there should be custom hat blocks! This is helping me understand why you're sometimes impatient with users' suggestions, because you don't have that feature closure instinct. And when we decided to add the generic WHEN block, I was thinking about it in terms of how users used to solve the problem that it solves before we had it, namely FOREVER IF. Because of course, as you said, I didn't grow up in a world of event-driven programming, so my instincts are about conditions rather than about events.
I don't think it's so terrible to have more than one icon on the title line. It's already possible to have $location and $flash there, although there's a subtle difference because $location is shown as being outside of, just next to, the title text, whereas $flash is part of the title text itself. This is reminiscent of another multi-icon thing I've been asking for, namely, the type hints in the formal parameter blobs of custom blocks. The "..." variadic hint should be combinable with list, number, lambda, etc. I'd even consider "λ?" for Predicates! (The point of the digression is that your only-one-icon instinct has been consistent throughout our history, and I don't understand it.)
Are you going to comment on my various aesthetic suggestions? Two by two arrangement of the shape icons in make-a-block, move the ∞ a little to the left, "whenever" as an alternative to the "while" you don't like, "becomes true" in the WHEN event block, "rule ∞" as the menu option name. And the one I'm not sure I'm advocating, namely making the rule hat blocks brown (but not as a separate palette category). Those are pretty much in priority order; two by two is important not to have hat blocks mess up the perspicuousness of the ordinary block case, and even though moving ∞ is obviously of no semantic/pedagogic importance at all, it does a lot to make me see it as a sober signifier rather than something that drowns out the specific title text.
I guess the remaining real substantive issue is that I think that if we have the rule feature at all (and I wouldn't mind if you decided to leave it out), it should be discoverable, and therefore both WHEN and WHENEVER should be primitives prominently visible in the palette. I think that would help a lot in teaching users (such as me) what events are!
The thing about that is, you can have custom hat blocks in any category, so you would have to have a darker color for each category. I think it'll be easier to add a new "rules" category (which would just be in the control category palette), rather than to make a specific color for rule blocks. Plus, it might even allow jens to add the "blocks" category that he mentioned a while ago (for the slot events and editing blocks), without having to make the category selector asymmetrical.
really? interesting!
Oh yeah good point. It's only noon; I'm not awake yet. :~/
PS The whole idea of non-Control hat blocks is freaky.
I think the $infinity is enough
I guess so, but they should still be relabelable with each other.
There's actually hat blocks in scratch extensions, which aren't in the events category, but they're mainly just for events from robots (which is actually a good use for custom hat blocks).
yeah. there should probably be some hats added in those libraries, like when connected :: rgb(100,50,255) hat for example.
yeah, eventually, sorry. Today I had to give a 4 hour seminar to 18 professors about GenAI in Snap! I was fun but also ... strenuous. For the next days I gotta take care of some other stuff, mostly FOSDEM proposals, and at one time I'd like to take 2 days off because I've been working with teachers in Hamburg all over last weekend, and am really kinda ... stressed out right now. Today before the seminar I've tried to at least fix the current dev version so it runs stable enough for us to explore over the next time.
On my list, yep. Let's see how it looks!
naw, I really like it centered in the "dome".
for custom blocks I don't care what label users choose. For the existing variant of the generic "when" hat block I'd like to keep the current label, because all the existing projects already have it, and all the translations are already there, and I'd hate to break them all. See, that's why I've invented that "always" icon, so displaying it on that very block both makes it (somewhat) apparent, that it behaves differently from the other hat blocks, and that it doesn't break existing projects and translations.
same here, I really want the "when" hat block to be "done right", and I think we might be there now. But let's give it some thorough kickin'.
yeah, that could be something to try. I'll have to play around with actual constraint-programming projects to find out more about how I really feel about those "rule" hat bloci, whether they are at all useful or not. Maybe somebody actually try implementing the "wandering letters" paragraph filling algorithm using constraints instead of a loop?
Haha, good one! 
yes, I'm not yet sure about that. Currently the main argument in favor or "rule" hats is that we have to retain backwards compatibility for existing such uses of the generic "when" hat. I'm not decided on this.
I just want to get this out there. I don't like the name "rule", because I can't wrap my mind around what a "rule" is. I think a better term would be an "infinite" hat, since there's already an infinity sign on the hat, and I can reason with my brain what an infinite hat is. Of course it might also not be a good name, because it does imply that the script underneath runs infinitely, which it doesn't necessarily run infinitely.
I know one use that I've used it for. Key presses that don't have the os specified delay. It's really good with projects where you're moving a sprite around with the keyboard, you may want to do something like
Using the rule hat blocks allows you to run this while the key is being pressed with no key repeat delay. If they're event blocks, this wouldn't be the case, and you'd run into key repeat delays (well, not really, because custom event blocks don't know what they key repeat delay is), which is not very good in, for example, games.
Just to be clear, I've used this before, all because it's a really quick way of adding smooth control to sprite movement.
Good example, thanks.
Now that you mention it, I'm not so excited about the name "rule" either, for a different reason, namely that that suggests a whole different style of non-imperative programming. In my mind (and occasionally out loud here) I've been thinking of them as "condition" hat blocks. Is the condition true, rather than did the condition just become true. Saying it a different way, what goes under the hat block is instructions about what to do when the condition is true, whereas in a logic programming rule what goes under the hat block is a definition of what it means for the condition to hold. (And that is the case, for what goes under the hat block in the Block Editor. But it's not the case for what goes under the hat block in actual use.)
I'm not entirely sure about "rule" either, but
THIS. Yes, it totally is about a segue into declarative programming!
@ego-lay_atman-bay's example is the only counter-example that's widely in use, and the reason has nothing to do with hat blocks. There are tons of Snap-cheat sheets out there that explain how "smooth" keyboard control works better with a "forever ... if " construct than waiting to be triggered by whatever the hardware keyboard repeat rate is. But it's important to note that that's the special case. The real treasure lies in ignoring everything we've previously said (and keep saying in this thread) about "when" hat blocks being "syntactic sugar for infinitely looping conditions", and by regarding those hat blocks as constraints instead.