jmoenig / snap Goto Github PK

When viewing help for a block, the help screen has a slightly different background color than the color of the window containing it, which leads to an unattractive second border around the help screen.

When blocks are rescaled using the "Zoom blocks…" menu item, the labels on global watchers already shown on the stage are removed.

Using the "Make a variable" button to make a variable that already exists toggles the visibility of its watcher on the stage. Making an existing variable should be a no-op.

Comments disappear when the blocks to which they are attached are dragged into or out of the script area in a block editor.

The "Project Notes…" menu item opens a second project notes dialog when clicked a second time, even if the first dialog has not been closed. This allows the user to open multiple dialogs displaying contradictory information.

Passing a non-number value as the argument to <move () steps>, e.g., the result of <join (hello ) (world)>, causes the sprite to move offscreen; the exact position varies depending on the size of your viewport.

This is caused by SpriteMorph.prototype.forward failing to check for NaN in casting its argument from a string to a number. The simplest fix is to use steps * this.parent.scale || 0 rather than parseFloat(steps * this.parent.scale).

Other affected blocks:

• <turn left () degrees> and <turn right () degrees> (which cause the default sprite to turn into a diagonal line)
• <set size to ()> and <change size by ()> (which both make the sprite a single pixel wide regardless of its previous size)
• <set pen size to ()> and <change pen size by ()> (which draws dotted lines…?)
• <go to x: () y: ()> (which moves the sprite offscreen)
• <change x by ()> and <change y by ()> (which set it to zero)
• <set tempo to ()> (which sets it to NaN)
• <change tempo by ()> (which sets it to the minimum value)

The general approach in these blocks of using parseFloat(value || '0') to cast to a number is flawed because it only guards against an empty string value and doesn't respond well to non-numeric strings—it still produces NaN. +value || 0 is a good solution for a zero default value (what Scratch and BYOB use), and isNaN(value) ? default : +value is good for non-zero default values.

It's easier not to have to drag a variable reporter out into the scripting area.

There are a few non-localized strings (or at least not included in the German localization):

• Scale blocks…
• Rasterize SVGs
• url…
• export project media only…
• export project without media…
• export project as cloud data…

When a custom block with a help comment is dragged out of the palette, hovering over the block instance shows the help tooltip where the block prototype is in the palette.

Clicking "Share" in the "Save Project" dialog with no project selected in the project list should save the project and mark it as shared.

If you ignore the awsome quality of that gif you will notice the block flickering about half way down
I am using Windows 8 pro 64-bit chrome: Version 28.0.1469.0 dev-m

Attached comments can overlap other comments attached to the same script:

The initial size of an enumerated input slot:

…is 1px smaller in width and height than the size when the empty string is selected from its menu:

Side-by-side:

Clicking "help" from the context menu for the "Make a variable," "Delete a variable," and "Make a block" buttons should display the help screens for adding variables, removing variables, and adding blocks, respectively.

When dragging a script, its shadow appears above any attached comments, rather than underneath them:

In addition, other blocks appear above the comment, and remain so when the script is dropped:

This looks a bit unpleasant against the darker block background color.

I see the reason for rendering them in user-editable fields, but is this intentional for enumerated inputs? (They're not shown in the menu of choices.)

If the user scrolls with the scroll wheel on the content frame of the project notes dialog when there is no scrollbar, the text is moved to the bottom of the content frame.

Before:

After:

should we simply slightly increase their distance?

Watchers and value bubbles should detect recursion in lists and display some indication of it, rather than trying to create infinitely-nested lists.

Test case.

I propose that right-clicking on a variable reporter or setter block (CHANGE or SET) would present the user with a "show definition" command. If it refers to a variable that has not been declared in its lexical scope, the command would be hidden. When the command is selected, the following would occur:

• If the variable to which the block refers is a script-local variable, the SCRIPT VARIABLES block in which it is declared would be scrolled into view.
• If the variable to which the block refers is a formal parameter to a block, the block prototype would be scrolled into view.
• If the variable is a global or sprite-local variable, the variables palette would be shown and the variable reporter corresponding to the variable would be scrolled into view.

The word "Sprite" in the tooltip for the button should not be capitalized, as "sprite" is not a proper noun.

An ellipsis in a menu item indicates that further user interaction is required to complete that command (often this is in the form of a modal or nonmodal dialog). Clicking "Import tools…" imports the full tool set and does not prompt the user for any more information, so it should not end with an ellipsis.

In the open dialog, double-clicking on a project name should perform the same action as selecting the project name and clicking the "Open" button.

When a block is altered within the palette, e.g., when an input is added to a ring, the palette does not update its horizontal scrollbar.

Before dragging:

After dragging:

Menu items in Snap! are capitalized using sentence case, but the "Project Notes…" item is capitalized using title case. In order to be consistent with the other menu items, it should be "Project notes…"

As it currently functions, choosing "rename…" from a variable reporter's context menu only changes the label of that variable reporter—it doesn't actually change the declaration of the variable or any of its other occurrences.

Before renaming:

After renaming:

Renaming a variable means changing its name, so when a user renames a variable its declaration (with script variables … or as a sprite or global variable) should also be changed to reflect the new name, as should all reporters within the variable's scope which refer to it.

Desired result:

In addition to being a much more intuitive result for the "rename" command, this process is also consistent with Scratch 2.0's variable renaming feature.

Users should still be able to change the variable to which the reporter points (i.e., change only its own label), but this feature should be available from the "relabel…" command rather than the "rename…" command.

When the #lang:xx anchor is added to the URL, the empty project that is created by default should have its name and the name of its (single) sprite localized.

The dialog that opens when a script variable is clicked has the title "Input Name," when it should be "Variable Name" or "Script Variable Name."

#open: should support the Username=username&ProjectName=project name format, so users can link to their projects in editing mode rather than presentation mode.

If a comment (wrapped to a reasonably narrow line width) or block contains a large amount of text, the scripting area which contains it no longer renders its background texture. The text itself is also not rendered, nor is the background of the comment/block.

At least in Mac OS X, non-ASCII characters cannot be input the usual way (i.e., ´+a to get á). All non-ASCII characteres must thus be pasted from elsewhere.

When one mistakenly tries to drag an .ypr file into the costumes area an unrecoverable error occurs. See the attached image.

1. Open the about dialog (Snap! logo → About…)
2. Click the "Modules…" button
3. Without moving the mouse, click the "Back…" button
4. Click the "Credits…" or "License…" button

The "Back…" button looks like the mouse is hovered over it, even though it is not.

Costumes go missing with this project: https://www.dropbox.com/l/RvhhsYNfwjHf9dohkng4bc

When I've tried snap on win7 in firefox or chrome, there is a general lag - its very slow to load - and some script or other often freezes the browser. Sometimes basic UI interaction works at first, until I try to load the official blocks, or open a project. Is this expected at this stage in development?

While Snap! allows cirularity in lists and is able to serialize / deserialize them displaying them in a list watcher - either on stage or in a bubble - freezes Snap!

Naming a variable with a name that includes an input slot, e.g., %b foo, causes the variable to have those input slots rather than literal percent signs.

The last row of pixels of the block editor background is solid white rather than the striped texture of the rest of the background.

• Making a variable called hasOwnProperty breaks the variables palette.
• Making a sprite called hasOwnProperty breaks the sprite name menu.
• Making a costume called hasOwnProperty breaks the costume name menu.
• Making a sound called hasOwnProperty breaks the sound name menu.
• Making a broadcast called hasOwnProperty breaks the broadcast menu.

It would be really nice if Snap! supported keyboard shortcuts for these common commands:

• ⌘S / Ctrl+S – Save
• ⇧⌘S / Ctrl+Shift+S – Save as…
• ⌘O / Ctrl+O – Open
• ⌘N / Ctrl+N – New
• ⌥⌘T / Ctrl+Alt+T – Import tools (not ⌘T / Ctrl+T because that's a frequently-used browser command)
• (Alternative to above: ⇧⌘N / Ctrl+Shift+N – New project with tools)
• ⌘U / Ctrl+U – Clean up current scripting area
• ⌘M / Ctrl+M – New sprite
• ⌘K / Ctrl+K – Make a variable (anyone have a better suggestion for this that's not ⌘V / Ctrl+V, ⌘L / Ctrl+L or ⌘A / Ctrl+A?)
• ⌘B / Ctrl+B – Make a block

(I'm aware that Snap! already has keyboard shortcuts for starting and stopping scripts)

I think that's my fault—sorry.

When a user clicks and drags on a dialog button, he/she picks up the dialog itself and can't finish clicking the button. The button should prevent the drag event from propagating to its parent dialog so a user can press the mouse, drag slightly, release it, and still complete the click; this is the behavior exhibited by other buttons in the interface, e.g., the palette buttons.

Uncaught TypeError: Cannot call method 'fullBounds' of null

When more text than fits onscreen is entered into an input slot, the text continues offscreen but a scrollbar does not appear to indicate that there is more content.

In the script variables … block, all generated variable names after "z" are "foo." A more useful pattern would be "aa"…"az," "ba"…"bz," etc.

Clicking the a palette category button when it is already selected scrolls the palette contents over about 10 pixels up and to the left.

The "Export blocks ..." and "Export project as plain text ..." menu items have a space before the ellipsis, while other menu items don't.

When I try to import the project http://bit.ly/14MGc7j to Snap! the following error occurs:

Load failled: TypeError: Cannot call method 'setContents' of undefined

If I remove the script and leave only the costumes (see http://bit.ly/YZWjud), the error no longer occurs. However, the costumes are not loaded properly.

When the block scale is set to something other than 1.0 using the "Zoom blocks…" menu item, the radio buttons for selecting block type in the "Make a Block" dialog are also rescaled, which causes layout issues.