Match 2.0 sprite drag and drop behavior

[rschamp]

While in player mode:

• Only draggable sprites should be draggable
• Sprites should be retained in the stage
• Clones of draggable sprites should be draggable

While in editor mode

• The dragged sprite should have a drop shadow

• Sprite on stage should be hidden while being dragged

• Blocks other than motion blocks should continue running Paul: This isn't quite right. Because the sprite is snapshotted, looks blocks also have no effect in 2.0, but the blocks do continue to run. I'm going to mark this as "correct in 3.0" because it does appear to be the same as 2.0

• The dragged sprite should be a snapshot of the sprite at the time it was picked up

• If the sprite is dropped outside of the stage, the sprite should return to the position it was picked up from

• If the sprite is dropped inside the stage, its position should be updated to the new position

• The sprite's X and Y values should be clamped to values within the stage during the drag. Paul: Not exactly. The XY values are not updated during the drag at all, so there is no clamping to be done. This is different from 2.0 where the XY actually is updated during the editor drag, although there are some bugs because of that (see comment below).

2.0 Weirdness
While in player mode

• In player mode if a dragged clone deletes itself while being dragged, nothing can be dragged again. In this case, we should probably stop the drag and remove the clone being dragged. (Paul: Yeah that is a bad bug... but 3.0 already deals with this in the way you suggested, so marking as done)

While in editor mode

• Clones can be dragged in editor mode. If dropped outside the stage, they are moved to the fenced position of the mouse, unlike the original sprite (Paul: oh come on seriously... let's not replicate this behavior...)
• Effects are applied to the dragged sprite only sometimes (Paul: in 3.0 effects are always applied to the dragged sprite, the sprite looks the way it did when you started to drag it. Marking done.)

[ericrosenbaum]

In 2.0, if the pen is down and you drag the sprite, it does not draw pen lines (in both editor and player modes). Currently in the 3.0 GUI, if the pen is down and you drag it does draw pen lines. It's worth considering changes to the 2.0 behavior, but we probably will want to mimic it.

[jwzimmer-zz]

Reported via internal playtest 3/3/17: currently, you can click and drag sprites but not clones.

[jwzimmer-zz]

Layering of sprites

In 2.0, you can drag a sprite to reorder it's layer/ z-position relative to the sprites around it. In 2.0, dragging it moves it to the front/ top layer. In 3.0, this doesn't seem to happen. It looks like the layer order is just the order that the sprite was added (for new sprites) or the order they were in in 2.0 (for imported projects).

It is convenient to be able to reorder the sprites by dragging them around rather than always using the back/ forward blocks, but on the other hand, being able to tweak the positioning of the sprites without then being forced to re-order them is kind of nice (in 3.0). So, I'm not sure which behaviour we prefer.

[towerofnix]

Layering of sprites

A simple "send to front" context menu item could work; but the only workaround for that on mobile devices would be to use the "go to front" menu item..

[ed-cooper]

I would actually prefer a context menu item to do this - this could be annoying in the case of an unintentional drag (eg. testing project in editor mode, clicked sprite, accidentally entered drag, z order of sprites is now wrong)

To address the issue of touch displays, send to front and send to back could be included as icons in the menu bar (see Scratch 2.0 menu bar icons)

[paulkaplan]

Following up from my comments in the issue body, there is a change to 3.0 editor dragging behavior where the XY are not updated for the sprite while the sprite is being dragged. This prevents a 2.0 bug where things that use the x/y position of a sprite get out of sync when dragged out of the stage:

Instead it just doesn't update until the drag ends

[paulkaplan]

I'm going to close this and open a new "needs-discussion" item for the layering-via-drag