Adding myMessages upvar

[jguille2]

Hi Jens!
Don't worry about this... Really it is not a Pull Request, it is only to show an idea (I think a PR helps us to see changes and to test it), and if this is worth it, I can remake it with the changes you would propose.

The idea is to have a message upvar. Something like this (we can change name, or visibility, or make another primitive with this...)

We know broadcasting (doBroadcast) search allHatBlocksFor that message (or for 'any message') on all the receivers (all sprites or targeted sprites), and then, it starts a new process.
The simple idea is to pass its message to this process, as a script variable (accessible by an upvar block variable).
This allows us to use the real message (the message received) and not the "last message" (that can be another one)

A simple demo is:

What do you thing about this? Is it interesting, or is it a wrong approach? If it is interesting I can make other changes and all the "routine work" for backward compatibility (translations...)
And if not, no problem, but I want to know your criteria about this, to future proposals...

Joan

[jguille2]

Hi Jens @jmoenig

Maybe a PR is not the place (:smile:)... but we can continue here playing with some ideas...
I've added the same "upvar feature" to keyPressed hatBlock and allow both (myMessage and myKeyPressed) to change their names.

If this is interesting... I will continue and then, two questions:

• Is it fine to have these upvars always visible? I want to put them inside a MultiArgMorph with only one position (really, not "Multi") and initially hidden (yes, now with that arrow). Then, both blocks will be unchanged (yes, the arrow...) and this "advanced" feature will be only for people who need it.
• What do you think about a new block like "press key %key" simulating a keypress event? Trigger those events programatically allow users not to be forced to repeat scripts (when they want to trigger a script by keyboard, but also by other ways).

Current state is:

Continue,
Joan

[brianharvey]

I want to put them inside a MultiArgMorph with only one position (really, not "Multi") and initially hidden (yes, now with that arrow).

Yes! Yes! And for custom blocks, too!!! Maybe now that it's not just me bugging Jens about this he'll finally allow it.

The right way to do this so it isn't a kludge for this one case is for every MultiArgMorph to have three associated counts, Minimum/Default/Maximum, where "Default" is the number of slots visible in the palette. (For example, Join and Append would have default=2.) Maximum could be zero or blank to mean infinite.

About what you've done, I think the keyboard and envelope icons as variable names are problematic. Can users make up 🤷 variables? Otherwise great.

[jmoenig]

Oh gawd. This sparks applause in all the wrong ways for all the wrong reasons. I'm getting out of this discussion.

[jguille2]

Hi!
Excuse me. I don’t want to cause problems or unconstructive discussions.
It is not a merge request, we do not need hasty decisions... Only sharing and documenting some "hard fun", with the intention of allowing to take ideas, to think about designs, to document code solutions ...

Now I have a cleaner code. And these "myUpvars" are now inside a MultiArgMorph. I've added a "press virtual key" block to see this idea in action.

Thanks!
A sample here:

Joan

[brianharvey]

That's very nice.

I have mixed feelings about reporting the name of nonprinting characters ("space" etc.). The alternative would be to report the actual character, 0x40 or whatever. The advantage is that it'd be a single character, simplifying comparisons, and that you could JOIN it into a message and it'd do the right thing. I don't have a strong feeling either way; does anyone else?

[jguille2]

Thank's Brian,

• About character names...
  Yes, I agree with you about nonprinting characters (and really, about all characters info). In this first draft I use those names, because they are already used by our (advanced) users, and because those names are already accessible from our current blocks. You see many posts (and not only current ones) with these questions and solutions.
  Yes, we have already
  
  But yes, it's not very nice for me. You know it’s worse from a non-English perspective.

So, I will think more deeply about this topic and try to write something about this. I will review old issues: you know, problems between keyCode-keyNames (we have different keys with the same names), problems about multiple detection, about IDE fired-events...

• And about upvar names.
  I think those pics are not bad for default upvar names (you know our default "upvar" is also an "up arrow" character), but other names ara also fine.
  Look! I've found this old post 😄 (it's not new!!)
  In my first draft I used "picture characters" because they were non-editable. But we can choose now.
  "message" and "key" are fine, but I would discard "message" to avoid confusions with our "message" reporter (meaning "last message").
  And also we can choose if we want the label "with input"...

Ok. That's all for now.

Joan

[brianharvey]

The uparrow isn't the default upvar; it's the type hint for upvars. Different. But I can see that for a non-native-English-speaker an ideogram is better than a word. I don't hate it.

And, now you remind me, "with input" isn't quite right, it is? The upvar isn't an input to a block. If the upvar were named "key" or "message," then a label of just "with" would be reasonable. But I don't think we need a label at all.

Jens gets mad when I'm more excited about your 0/0/1 "multiple" input slot than about the any-key/any-message feature, but I've wanted that for sooooooo long! I want it for users, not just for primitives. My UI proposal is that when you click the multiple input slot radio button, the default-value text box turns into three numeric slots labelled Min, Def, and Max, with the requirement that Min≤Def≤Max except that Max=0 is taken to mean Max=∞, i.e., no maximum. Maybe if you make a PR he'd pull it? Maybe?

[jmoenig]

naw, forget about it.

[jguille2]

Yes Brian,
I was confusing technical details (labelString of that TemplateSlotMorphs is really an "up arrow" character) with the variable name (that is the blockSpec of the upvar reporters).
And then yes, if this is the first intro to those variables names, it must be checked deeply before.

Joan