Dale_Mahalko wrote:

What I am trying to do is to move all scripting into a single main script, rather than spreading out code fragments across many sprites. This has long been a limitation in Scratch that you can't have a single central script in the stage and command sprites to do stuff from that central script.

Sure, no problem.
TELL [Sprite 1]
blah
blah
blah
TELL [Sprite 2]
foo
baz
garply
etc.
Use “Import tools” to get the TELL block.

I don't know if I'm trying to push this limited language to try to act too much like a normal language,

Hey! Scratch is a deliberately limited language to appeal to 8-year-olds. We could discuss some of their design choices, but it's hard to argue with their success. But Snap! is a complete implementation of Scheme, the world's most versatile programming language, even including Scheme's first class continuations. You don't have to like Snap!, but don't call it names if you don't know what you're talking about.

As for “normal,” what's not normal about object-oriented widget management? That's what sprites are.

which may not have a concept of sprites but just stamps out bitmaps onto the background with every frame update, only checks for overlapping rectangles in code, and has no concept of “touching”.

Sorry, but all I'm hearing is “I learned one way to do this, and any other way is therefore wrong.” Nevertheless, you can do it your way if you want, because you're wrong about this:

Just doing this is a problem because AFAIK there is only the one background, and I can't create a floating drawing area over the background that can then be drawn on, and discarded when I am done with it.

Sure you can. The drawing you do happens on the “pen trails” layer, which is above the background but below the sprites. To clear the pen trails, use the CLEAR block, the first thing in the Pen category. And the STAMP block will stamp the sprite's costume onto the pen trails layer. If you want to be able to save and restore drawings, import the pen trails library.

The Say chat bubble for player interaction is very limiting. I've been contemplating trying to write some sort of GUI framework that uses tens to hundreds of tiny tiled sprites in a cluster to create clickable auto-resizable buttons with sprite-generated text labels inside them, and I'm trying to figure out a “proper” way to do it.

Yes, SAY is limited, I agree. As soon as 4.1 is done, I'm going to get to work on a programmable-and-editable text box as a special case sprite costume. As for buttons, if you import the pen trails library into Snap!, it includes a BUTTON block that does just what you want.

Did someone use the word transpile? What's wrong with compile? /rant-omitted-too-tired.

cycomachead wrote:

Did someone use the word transpile? What's wrong with compile? /rant-omitted-too-tired.

Nothing's wrong with compile. What's wrong with transpile?

Since Snap has a Javascript block, are there any precautions taken in limiting the effects of it?

Was there ever a discussionif a project should come with a warning when it is using this block? If no, why not?

frodewin wrote:

Since Snap has a Javascript block, are there any precautions taken in limiting the effects of it?

Was there ever a discussionif a project should come with a warning when it is using this block? If no, why not?

Yes, there's been a fair bit of discussion on the topic here. I'm not certain if any actual code or plan changes have come out of it yet (correct me if I'm wrong?).

This has long been a limitation in Scratch that you can't have a single central script in the stage and command sprites to do stuff from that central script.

The broadcast mechanism allows you to send commands to sprites from a central script so that's not a limitation in Scratch

It might not do what you want but it does do that bit

What a silly project of mine. They don't usually get this silly.

_nix wrote:

They don't usually get this silly.

I liked the part about using a Snap! script as the callback to a JS function. But I got tired before figuring out why you need two sprites. Sorry… It's very cool, though, that you can animate an external web window from Snap!.

bharvey wrote:

_nix wrote:

They don't usually get this silly.

I liked the part about using a Snap! script as the callback to a JS function. But I got tired before figuring out why you need two sprites. Sorry… It's very cool, though, that you can animate an external web window from Snap!.

It actually doesn't need two sprites; the unnamed one was just an old test script. (Note that its script isn't attached to a “when green flag clicked”.)

djdolphin wrote:

cycomachead wrote:

Did someone use the word transpile? What's wrong with compile? /rant-omitted-too-tired.

Nothing's wrong with compile. What's wrong with transpile?

Mostly I think it's unnecessary. There's some small argument of whether compiling has to mean going to a lower level of abstraction, but when used in the case of modern JS code, you're removing abstractions.

As to the concerns around JS functions - we've not written any code. The primary mitigating factor (as to why this isn't urgent), is that there's no public directory of Snap! projects, so far most projects are only shared in small / relatively controlled settings.

However, very recently (as in the last 24 hours) I've also realized there exists a way in Snap! to automatically execute a JS (or any other) function when opening a project. So, it's probably becoming more important to do something about this.

Hi,
I was wondering if anyone can guide me to the method or parameter to change the blocks view (where the code is) to be read only. i.e. To stop the ability from someone changing the code they see for a sprite or stage, I would call X in a script?

Thanks in Advance

Is there going to be a community website / forum / project sharing platform launched for Snap! yet this year, or has that been pushed off until next year?

I started using Snap! in an introductory programming class which started last week, with the expectation that a community website, where students could share their projects and collaborate like with Scratch, would be arriving any day now.

Probably will have students share and collaborate and learn from each other on Scratch for a while, until that gets done.

dev_in_spain wrote:

I was wondering if anyone can guide me to the method or parameter to change the blocks view (where the code is) to be read only. i.e. To stop the ability from someone changing the code they see for a sprite or stage, I would call X in a script?

Short answer: No, we don't have a way to make scripts visible but not writeable.

We do have a way to make scripts invisible: append “&hideControls” to the URL of the shared project. But this isn't super-high-security; kids will discover it by the end of the first class. So they have to buy into the game for this to work as a teaching technique.

Dale_Mahalko wrote:

Is there going to be a community website / forum / project sharing platform launched for Snap! yet this year, or has that been pushed off until next year?

I too am frustrated by the delays. We're a little scared of introducing a big back-end change with classes running, so our current target is xmas vacation.

bharvey wrote:

I too am frustrated by the delays. We're a little scared of introducing a big back-end change with classes running, so our current target is xmas vacation.

If there is a need for a beta period to make sure it is all working, it should be possible to launch it right now without disturbing what exists already.

Leave the current cloud storage alone and fork an entirely separate version of Snap! that is integrated into the new portal/community/cloud.

If people want to move from the “old cloud” to the new beta community cloud, they can migrate their projects manually via export/import.

Is it possible to write a block that create a new block and adds it to the pallet? Also, is it possible to write a block the creates a new category in the pallet?

I think that I found a bug in Snap: http://snap.berkeley.edu/snapsource/snap.html#present:Username=bookowl&ProjectName=Bug%20report

(For context, that is just a simplified test case, my real code that I first found this bug with isn't near as bad name-wise )

BookOwl wrote:

I think that I found a bug in Snap: http://snap.berkeley.edu/snapsource/snap.html#present:Username=bookowl&ProjectName=Bug%20report

(For context, that is just a simplified test case, my real code that I first found this bug with isn't near as bad name-wise )

I reported that a while ago, it's because there's an implicit input for the t block https://github.com/jmoenig/Snap–Build-Your-Own-Blocks/issues/1245

BookOwl wrote:

Is it possible to write a block that create a new block and adds it to the pallet? Also, is it possible to write a block the creates a new category in the pallet?

Yes, and yes…We have access to everything through JS Function, so that'll work.

There's some work to define a reasonable extensions API that would enable more of this. No time frame, but it's on the list of projects.