So, I'm trying to make an "annotation" widget -- I want to start at a mouse point and draw a box to the current mouse position, and keep redrawing the box as I go along.
However, I want there to only be one box at a time. If we had "sprite-local" clears, this seems like it should be easy, but without that, I can't figure this out. Any ideas?
Here's the project so far:
So, if you click you'll get the ability to draw a box, but I don't want the intermediate drawings to be kept. Any ideas? I would like to not use a JS Function if possible, but otherwise I will.
@jens: Here is a real-life case in which hybrid scope would have helped a lot. I wanted to take the seven duplicated motion blocks and move them into a new BOX block, but in order to do that I would have had to give it four inputs (startx/y, lastx/y) and it was just too much trouble. With hybrid scope I could have done it easily without having to think about it or (were I a new user) debug the unbound variable error messages.
@staff: When I loaded Michael's project from his link, modified it, and then saved it to my own account, the URL bar didn't change. I can see why it'd be wrong to change it to one with my username before I shared the project, but using his uname is wrong too, and could lead to me accidentally reloading his version and saving it over mine. The right solution, as I've been saying for a while now but nobody ever believes me, is that project URLs should be
...edu?project=568973478945628745
regardless of shared status.
@bh good example for the potential benefits of hybrid scope, thank you, Brian!
In my own experience with teachers and kids scope is - perhaps by far - the most challenging concept in all of programming, not just for novices, but also for professionals. Unsurprisingly it's also really powerful. I'm perfectly happy to introduce beginners to the idea of scope at all, without confusing them with several kinds of scope, especially not with dynamic or hybrid scope. I'm very much afraid that such confusing and - in the case of dynamic scope - detrimental concepts would only reinforce students' perception that programming is inexplicably hard.
TL;DR: Scope is hard. Let's not confuse people with hybrid scopes.
But this is not "un-drawing". This is drawing a white box and then a colored box. I don't know the background (in the real project). Or, more precisely, I'm trying to draw a transparent box over any background.
I guess what I am really trying to build is a generic rectangle tool in a photo/document editor.
For example, when explaining a tree recursive problem I would like to be able to annotate a subtree with a box, indicating the recursive calls.
you could try generating a new blank costume out of given dimensions and stamping that over the previous space. That should totally work. Check out the idea here: Snap! Build Your Own Blocks or here: Snap! Build Your Own Blocks. There's a generic "new costume" reporter in this project that you could reuse: Snap! Build Your Own Blocks
{sigh} This from the person who squeezed two entirely unrelated tasks, in which the inputs are in different scales, into one STRETCH block.
What's potentially confusing is lexical scope, and even more so in a language without a capability for internal definitions. Dynamic scope is what's natural to people. There are many advantages to lexical scope, don't misunderstand me about that, but ease of understanding is not one of them.
And please remember that the hybrid scope design is that the only context in which dynamic scope is used is when
There is no variable with the name provided by the user in the lexical environment, so the user is about to get an error message;
There is a variable by that name in the dynamic environment, so that's plainly what the user is expecting to get.
So your argument is really that it's better to punish the user for wanting the wrong thing than to give the user what they plainly want and expect.
Yes, a user who names all their variables "x" and who wants the one in the dynamic environment will instead get the one in the lexical environment.
But my personal feeling is that a user who has, and wants, an unambiguous dynamic binding for a name (i.e., there isn't also a competing lexical binding) should not be punished for the sake of also punishing the everything-named-x user. When it's perfectly clear what the user wants, that's what we should give them. And, once again, that's the only time dynamic scope would come into play.
Anyway, we agreed about this. You have been corrupted by spending too much time with those German CS professors you're always complaining about.
Ah, I see. You want the PEN ERASE block, which puts down the eraser instead of the inked nib. That's on the list, along with PEN REVERSE, which puts down the xor pen. On the list.
Ah, yes, I think that makes sense -- though I'll admit, that I feel like this is a round about way of building something. Sprite-local clear would be super great here.
Building a box using a 1D array of pixels is confusing because I need to understand how that gets translated into a 2D image -- and it's learnable but not very intuitive. (Even for upper level graphics students)
And thanks @jguille2 -- I had built a similar script, but I'm trying not to use CLEAR so that I can make multiple annotations, and don't need to hack around saving the contents of other scripts to costume and then restoring them.
I missed this, but a known issue. The right solution is to use your username and project name. Those URLs would just fine with private projects. (You need to be logged in of course.)
The presence of a URL is an awful UI indicator for "shared-ness" and we should just default to always having URLs. This enables bookmarking private projects if you choose.
