41
63
providing “lively” response to input changes; if Input sliders is checked, reopening the settings menu will show
an additional option called Execute on slider change. If this option is also checked, then changing a slider in the
scripting area automatically runs the script in which that input appears. The project live-tree in the Examples
collection shows how this can be used; it features a fractal tree custom block with several inputs, and you can see
how each input affects the picture by moving a slider. This option is per-project, not per-user.
Clicking sound causes a really annoying sound effect whenever one block snaps next to another in a script.
Certain very young children, and our colleague Dan Garcia, like this, but if you are such a child you should
bear in mind that driving your parents or teachers crazy will result in you not being allowed to use Snap!.
Turbo mode makes most projects run much faster, at the cost of not keeping the stage display up to date. (Snap!!
ordinarily spends most of its time drawing sprites and updating variable watchers, rather than actually carrying
out the instructions in your scripts.) So turbo mode isn’t a good idea for a project with glide blocks or one in
which the user interacts with animated characters, but it’s great for drawing a complicated fractal, or computing
the first million digits of , so that you don’t need to see anything until the final result. While in turbo mode,
the button that normally shows a green flag instead shows a green lightning bolt. (But when clicked hat
blocks still activate when the button is clicked.)
Flat design changes the “skin” of the Snap!!window to a really hideous design with white and pale-grey
background, rectangular rather than rounded buttons, and monochrome blocks (rather than the shaded,
somewhat 3D-looking normal blocks). The monochrome blocks are the reason for the “flat” in the name of this
option. The only thing to be said for this option is that it may blend in better with the rest of a web page when a
Snap! project is run in a frame in a larger page.
Thread safe scripts changes the way Snap! responds when an event (clicking the green flag, say) starts a script,
and then, while the script is still running, the same event happens again. Ordinarily, the running process stops
where it is, ignoring the remaining commands in the script, and the entire script starts again from the top. This
behavior is inherited from Scratch, and some converted Scratch projects depend on it; that’s why it’s the default.
It’s also sometimes the right thing, especially in projects that play music in response to mouse clicks or
keystrokes. If a note is still playing but you ask for another one, you want the new one to start right then, not
later after the old process finishes. But if your script makes several changes to a database and is interrupted in
the middle, the result may be that the database is inconsistent. When you select Thread safe scripts, the same
event happening again in the middle of running a script is simply ignored. (This is arguably still not the right
thing; the event should be remembered and the script run again as soon as it finishes. We’ll probably get
around to adding that choice eventually.)
Prefer smooth animations slows down Snap! ’s frame rate (time between updates to the display) to a fixed 1/30
second, like Scratch. (Ordinarily Snap!! updates the display as often as possible.) One reason you might want
this, explaining the option’s name, is to ensure that sprites move a constant distance from one redisplay to the
next, so that motion seems smooth rather than jerky. Another reason is to ensure that your program runs at the
same speed on different computers. A third reason, somewhat counterintuitive, is that a project with many
scripts running at once (for example, one that clones sprites repeatedly) may run faster if more time is available
for scripts because less time is spent on the display of the screen.
Flat line ends affects the drawing of thick lines (large pen width). Usually the ends are rounded, which looks
best when turning corners. With this option selected, the ends are flat. It’s useful for drawing a brick wall.
44
64
Codification support enables an experimental feature that can translate a Snap!!project to a text-based (rather
than block-based) programming language. The feature doesn’t know about any particular other language;
instead, you can provide a translation for each primitive block using these special blocks:
Using these primitive blocks, you can build a block library to translate into any programming language. Watch
for such libraries to be added to our library collection (or contribute one). To see some examples, open the
project “Codification” in the Examples project list. Edit the blocks map to Smalltalk, map to JavaScript, etc.,
to see examples of how to provide translations for blocks.
Stage Resizing Buttons
Still in the tool bar, but above the left edge of the stage, are two buttons that change the size of the stage. The
first is the shrink/grow button. Normally it looks like this:
Clicking the button displays the stage at half-
normal size horizontally and vertically (so it takes up ¼ of its usual area). When the stage is half size the button
looks like this:
and clicking it returns the stage to normal size. The main reason you’d want a half size stage
is during the development process, when you’re assembling scripts with wide input expressions and the normal
scripting area isn’t wide enough to show the complete script. You’d typically then switch back to normal size to
try out the project. The next presentation mode button normally looks like this:
Clicking the button
makes the stage double size in both dimensions and eliminates most of the other user interface elements (the
palette, the scripting area, the sprite corral, and most of the tool bar). When you open a shared project using a
link someone has sent you, the project starts in presentation mode. While in presentation mode, the button
looks like this:
Clicking it returns to normal (project development) mode.
Project Control Buttons
Above the right edge of the stage are three buttons that control the running of the project.
Technically, the green flag
is no more a project control than anything else that can trigger a hat block:
typing on the keyboard or clicking on a sprite. But it’s a convention that clicking the flag should start the action
of the project from the beginning. It’s only a convention; some projects have no flag-controlled scripts at all, but
respond to keyboard controls instead. Shift-clicking the button enters Turbo mode, and the button then looks
like a lightning bolt:
Shift-clicking again turns Turbo mode off.
Scripts can simulate clicking the green flag by broadcasting the special message __shout__go__ (two
underscores in each of the three positions shown).
The pause button
suspends running all scripts. If clicked while scripts are running, the button changes
shape to become a play button:
Clicking it while in this form resumes the suspended scripts. There is also
a pause block in the Control palette that can be inserted in a script to suspend all scripts; this provides the
essence of a breakpoint debugging capability.
The stop button
stops all scripts, like the stop all block. It does not prevent a script from starting again in
response to a click or keystroke; the user interface is always active.
15
65
B. The Palette Area
At the top of the palette area are the eight buttons that select which palette (which block category) is shown:
Motion, Looks, Sound, Pen, Control, Sensing, Operators, and Variables (which also includes the List and Other
blocks). There are no menus behind these buttons.
Context Menus for Palette Blocks
If you control-click/right-click a primitive block in the palette, you see this menu:
The help… option displays a box with documentation about the block. Here’s an example:
The hide option removes that block from the palette. (This option is available only when clicking the block in
the palette itself, not in a script.) The purpose of the option is to allow teachers to present students with a
simplified Snap!!!with some features effectively removed. The hiddenness of primitives is saved with each project,
so students can load a shared project and see just the desired blocks.
If you control-click/right-click a custom (user-defined) block in the palette, you see this menu:
The help… option for a custom block displays the comment, if any, attached to the custom block’s hat block in
the Block Editor. Here is an example of a block with a comment and its help display:
30
66
The same comment is also shown while hovering over the custom block in the palette.
The delete block definition… option asks for confirmation, then deletes the custom block and removes it from
any scripts in which it appears. (The result of this removal may not leave a sensible script; it’s best to find and
correct such scripts before deleting a block.) Note that there is no option to hide a custom block.
The edit… option opens a Block Editor with the definition of the custom block.
Context Menu for the Palette Background
Right-click/control-click on the grey background of the palette area shows this menu:
The hide primitives option hides all of the primitives in that palette. The show primitives option, which is in the
menu only if some primitives of this palette are hidden, unhides all of them.
C. The Scripting Area
The scripting area is the middle vertical region of the Snap!!window, containing scripts and also some controls for
the appearance and behavior of a sprite. There is always a current sprite, whose scripts are shown in the scripting
area. A dark grey rounded rectangle in the sprite corral shows which sprite (or the stage) is current. Note that
it’s only the visible display of the scripting area that is “current” for a sprite; all scripts of all sprites may be
running at the same time. Clicking on a sprite thumbnail in the sprite corral makes it current. The stage itself
can be selected as current, in which case the appearance is slightly different.
Sprite Appearance and Behavior Controls
At the top of the scripting area are a picture of the sprite and some controls for it:
Note that the sprite picture reflects its rotation, if any. There are three things that can be controlled here:
The three circular buttons in a column at the left control the sprite’s rotation behavior. Sprite costumes are
designed to be right-side-up when the sprite is facing toward the right (direction = 90). If the topmost button is
lit, the default as shown in the picture above, then the sprite’s costume rotates as the sprite changes direction. If
the middle button is selected, then the costume is reversed left-right when the sprite’s direction is roughly
leftward (direction between 180 and 359, or equivalently, between -180 and -1). If the bottom button is
selected, the costume’s orientation does not change regardless of the sprite’s direction.
The sprite’s name can be changed in the text box that, in this picture, says “Sprite.”
Finally, if the draggable checkbox is checked, then the user can move the sprite on the stage by clicking and
dragging it. The common use of this feature is in game projects, in which some sprites are meant to be under
the player’s control but others are not.
25
67
Scripting Area Tabs
Just below the sprite controls are three tabs that determine what is shown in the scripting area:
Scripts and Blocks Within Scripts
Most of what’s described in this section also applies to blocks and scripts in a Block Editor.
Clicking on a script (which includes a single unattached block) runs it. If the script starts with a hat block,
clicking on the script runs it even if the event in the hat block doesn’t happen. (This is a useful debugging
technique when you have a dozen sprites and they each have five scripts with green-flag hat blocks, and you
want to know what a single one of those scripts does.) The script will have a green “halo” around it while it’s
running. Clicking a script with such a halo stops the script. (If the script includes a warp block, which might be
inside a custom block used in the script, then Snap!!!may not respond immediately to clicks. Hold the mouse
button down until it works.)
If a script is shown with a red halo, that means that an error was caught in that script, such as using a list where
a number was needed, or vice versa. Clicking the script will turn off the halo.
Control-click/right-clicking a primitive block within a script shows a menu like this one:
The help… option shows the help screen for the block, just as in the palette. The other options appear only
when a block is right-clicked/control-clicked in the scripting area.
Not every primitive block has a relabel… option. When present, it allows the block to be replaced by another,
similar block, keeping the input expressions in place. For example, here’s what happens when you choose
relabel… for an arithmetic operator:
Note that the inputs to the existing – block are displayed in the menu of alternatives also. Click a block in the
menu to choose it, or click outside the menu to keep the original block.
The duplicate option makes a copy of the entire script starting from the selected block. The copy is attached to
the mouse, and you can drag it to another script (or even to another Block Editor window), even though you are
no longer holding down the mouse button. Click the mouse to drop the script copy.
23
68
The block picture underneath the word duplicate is another duplication option, but it duplicates only the
selected block, not everything under it in the script. Note that if the selected block is a C-shaped control block,
the script inside its C-shaped slot is included. If the block is at the end of its script, this option does not appear.
The delete option deletes the selected block from the script.
The script pic… option opens a new browser tab containing a picture of the entire script, not just from the
selected block to the end. You can use the browser’s Save feature to put the picture in a file. This is a super
useful feature if you happen to be writing a Snap!!!manual!
If the script does not start with a hat block, or you clicked on a reporter, then there’s one more option: ringify
or, if there is already a grey ring around the block or script, unringify. Ringify surrounds the block (reporter) or
the entire script (command) with a grey ring, meaning that the block(s) inside the ring are themselves data, as an
input to a higher order procedure, rather than something to be evaluated within the script. See Section VI,
Procedures as Data.
Clicking a custom block in a script gives a similar but different menu:
There is no relabel… option for custom blocks. The two options at the bottom, for custom blocks only, are the
same as in the palette.
Scripting Area Background Context Menu
Control-click/shift-click on the grey striped background of the scripting area gives this menu:
The clean up option rearranges the position of scripts so that they are in a single column, with the same left
margin, and with uniform spacing between scripts. This is a good idea if you can’t read your own project!
The add comment option puts a comment box like the picture below in the scripting area. It’s attached to the
mouse, as with duplicating scripts, so you position the mouse where you want the comment and click to release
it. You can then edit the text in the comment as desired.
16
69
You can drag the bottom right corner of the comment box to resize it. Clicking the arrowhead at the top left
changes the box to a single-line compact form, as below, so that you can have a number of collapsed comments
in the scripting area and just expand one of them when you want to read it in full.
If you drag a comment over a block in a script, the comment will be attached to the block with a yellow line:
Comments have their own context menu, with obvious meanings:
Back to the options in the menu for the background of the scripting area:
The undrop option is a sort of “undo” feature for the common case of dropping a block somewhere other than
where you meant it to go. It reattaches the dropped block or script to the mouse, like duplicating a block, and
restores the former contents of the slot into which you dropped it. You can then reposition the mouse to put the
block where you meant it to go.
The scripts pic… option opens a new browser tab with a picture of all scripts in the scripting area, just as they
appear, but without the grey striped background. Note that “all scripts in the scripting area” means just the top-
level scripts of the current sprite, not other sprites’ scripts or custom block definitions.
Finally, the make a block… option does the same thing as the “Make a block” button in the Variables palette.
It’s a shortcut so that you don’t have to keep switching to Variables if you make a lot of blocks.
20
70
Controls in the Costumes Tab
If you click on the word “Costumes” under the sprite controls, you’ll see something like this:
The Turtle costume is always present in every sprite; it is costume number 0. Other costumes can be painted
within Snap!!!or imported from files or other browser tabs if your browser supports that. Clicking on a costume
selects it; that is, the sprite will look like the selected costume. Clicking on the paint brush icon
opens the
Paint Editor, in which you can create a new costume.
Control-clicking/right-clicking on the turtle picture gives this menu:
In this menu, you choose the turtle’s rotation point, which is also the point from which the turtle draws lines. The
two pictures below show what the stage looks like after drawing a square in each mode; tip (otherwise known as
“Jens mode”) is on the left, middle (“Brian mode”) on the right:
As you see, “tip” means the front tip of the arrowhead; “middle” is not the middle of the shaded region, but
actually the middle of the four vertices, the concave one. (If the shape were a simple isosceles triangle instead of
a fancier arrowhead, it would mean the midpoint of the back edge.) The advantage of tip mode is that the
sprite is less likely to obscure the drawing. The advantage of middle mode is that the rotation point of a sprite is
rarely at a tip, and students are perhaps less likely to be confused about just what will happen if you ask the
turtle to turn 90 degrees from the position shown. (It’s also the traditional rotation point of the Logo turtle,
which originated this style of drawing.)
Costumes other than the turtle have a different context menu:
Documents you may be interested
Documents you may be interested
