Design - Reconcile behaviour when dragging out of the workspace

[rachel-fenichel]

Blockly currently:

• Deletes the block if it's dragged out of the side with the toolbox, no matter how far past the toolbox the drag ends.
• Otherwise drops the block at the point in the workspace nearest the pointer's final position, no matter where the pointer exited the workspace.

Scratch currently:

• Deletes the block if it's dragged into the "flyout" section of the toolbox.
• Adds the blocks to the other sprite and returns them to their original position, if the drag ends on top of a sprite.
• Otherwise returns them to their original position, including if they were dropped on the category section of the toolbox.

[rachel-fenichel]

Scratch also deletes the block if it was dragged directly from the toolbox to somewhere outside of the workspace.

[thisandagain]

/cc @carljbowman Something to consider when doing the spec for the toolbox.

[rachel-fenichel]

/cc @NeilFraser

[NeilFraser]

I vote for deleting the block when dropped on the categories. Can't imagine that different drop behaviours on categories vs flyout was an intentional design decision.

A larger issue is Scratch's ability to drag blocks to other sprites. SVG can't do that if the SVG rectangle is the workspace (as is normally the case with Blockly). There are two options I see. One is to copy in-flight blocks out of Blockly and onto some new floating layer. The other is to expand the SVG so that it encompases all of Scratch. The latter seems to be a more solid solution with less chance for misalignments. That's also closer to what Scratch currently uses, where all of Scratch is one Flash element, not a fragile collection of stuff.

[rachel-fenichel]

In Blockly right now you can actually drag the workspace around and have blocks end up on top of the flyout but not deleted, thanks to the svg. This is pretty rare because usually when the flyout is permanently open, you can't drag the workspace, but that constraint won't apply for scratch.

[thisandagain]

Part of spec in #21