Shift-drag to select multiple blocks and allow moving multiple block group

[AnmAtAnm]

Several times I've found myself wanting to move multiple block groups at once when organizing my workspace (perhaps to make room for a new block group). My instinctive action is to attempt to drag a rectangle around the blocks, but this just drags the workspace.

I suggest we allow user to hold shift to change the drag behavior into creating a rectangular selection marquee.

This might be the default behavior on non-scrollable workspaces.

[NeilFraser]

Multiple selection becomes a crazy-complex feature when you start thinking about the details. When dragging two islands, how do connections work? When you right-click on a multiple selection, how do those options apply to all blocks?

This feature has been on our future list for four years. It would take about two months to implement this properly and shake out all the bugs. I don't recommend touching this until we have lots of time on our hands and a nearly bug-free codebase.

[amber-cd]

It's been a few years, but is it possible to follow up on this? Are there any current plans to implement this? I know this is a feature we've been hoping for. I don't think most people want this feature for the purposes of anything which would require much in the way of connections handling, but rather for the purposes of "move all of these blocks at once/delete all of these blocks at once/disable all of these blocks at once". I would thus propose the following behaviors for the initial implementation:

1. If all of the selected blocks are in one block stack (e.g. there is only one top block in the selection), treat the connections behavior the same way as when dragging the top block.
2. If all of the selected blocks are not in one block stack (e.g. there are multiple top blocks in the selection), then disable all connections logic until the selection includes only one top block. You can move the blocks around; they just won't snap, and no insertion markers will appear.
3. The "Duplicate" menu will duplicate all selected blocks. The selection will be changed to all newly created duplicate blocks.
4. The "Add Comment" option will not appear or will be disabled if multiple blocks are selected.
5. "Collapse Block" will instead read as "Collapse [x] Blocks" and will collapse all selected blocks. Children of selected blocks which are themselves not selected will not be in the count and will not be collapsed.
6. "Disable Block" will instead read as "Disable [x] Blocks" and will disable all selected blocks. Children of selected blocks which are themselves not selected will not be in the count and will not be set as disabled.
7. As with deleting a block with children, "Delete [x] Blocks" will appear in the menu and will represent the count of all selected blocks and their children. Deletion will delete all blocks and their children. (This logic may require some finagling to prevent attempting to delete blocks twice if a child block is one of the selected blocks.)
8. The "Help" option would not appear or would be disabled when multiple blocks are selected.
9. Copy would copy all selected blocks, and paste would paste all blocks on the clipboard.
10. As with the current behavior, all blocks could be deselected by clicking on the workspace background. Additional blocks would be able to be selected by holding shift while clicking the new block. Clicking a new block without pressing shift would change the selection to that block. Holding shift and dragging an area to select would deselect any previously selected blocks and select all blocks touched by the new selection rectangle. Holding shift and ctrl and dragging an area to select would add all blocks touched by the new selection rectangle to the currently selected blocks.

I think this all represents intuitive and desired behavior, and would be very useful. I know I was deleting a large number of blocks earlier as a part of debugging and was frustrated by having to select and delete each one in turn, particularly as these were all snapped in to a "build list" block and I was removing only some of the options, meaning there was no "shortcut" to delete them all by placing them inside a parent block and then deleting it.

Are all of these features acceptable? While I'm not swimming in free time, I or someone else may be amenable to implementing this behavior, so long as the behavior can be agreed upon.

[asanzo]

Edit: I re-read amber-cd's suggestion and I agree more than before. I crossed out some suggestion.

Hi! I like this! 😁 I agree with amber-cd in the general expected behaviour description. However, I want to discuss two differences:

• In 2., I'd change the default dragging behaviour once the block group is selected. The normal behaviour "drag one, take everything below with me" is a quick way of managing block chunks today. However, when selecting multiple blocks I'm saying "I particularly want to fiddle with these guys", so when dragging the selected block group I'd unplug the group from wherever it is and connect previous and next blocks to close the generated space.
• Regarding 10., I'd start with a simple selection of multiple consecutive blocks. I think this is useful for most of the situations. In that case, I think it is simpler to implement "click top block - hold shift - click bottom block" for selection of multiple blocks. However I'm not partial to any selection method because just having it would be great. I like the rest of the described behaviour.
• And of course there is the android/tablet/touch problem: how to select multiple blocks in that context.

Thanks to the team for leaving this one still open 😁 and thanks for the continuous great work. 👏 👏 👏

[MNSDivya]

Issue still needs to be addressed as reported behavior is still observed.

[rachel-fenichel]

I just transferred this issue from Blockly to blockly-samples. This is a good candidate for a plugin, because it is behaviour that we think is interesting but not a good fit for core Blockly.

This would be a workspace plugin, so its name would be @blockly/workspace-multi-select.

It's now in the discussion phase and open for conversation. The first two points to discuss are:

• desired behaviour
• APIs needed in core Blockly

@amber-cd @asanzo @AnmAtAnm

[asanzo]

How very exciting it is to see this one moving around. Thanks, Rachel! 🦾

I've updated a bit my previous comment. I still think amber-cd has some great ideas here. I imagined the behaviour with and without value inputs and statement inputs and I think what amber-cd says works as expected.

[amber-cd]

Regarding @asanzo's points:

• The change to 2. is equally logical and I'm fine with it
• I think that holding shift to select the first and last block in a stack in order to select all blocks between them is logical, but I'd want a way to indicate that I do want to select only these blocks and not the blocks between them (such as holding ctrl + shift).

I agree that the touchscreen problem would need to be addressed... I'd say that could be addressed either by drawing a rectangle and automatically selecting all blocks within it or by adding some type of "selection mode" toggle button which would change selection behavior on touchscreens between single and multiple.

[BeksOmega]

Recent requests from App Inventor and Sandspiel Studio

[HollowMan6]

Recent requests from App Inventor and Sandspiel Studio

Hi everyone, glad to have a chance to implement this issue during my Google Summer of Code 2022 at MIT App Inventor. Now an initial demo for this has already been worked out by myself. You can find the PR at mit-cml/workspace-multiselect#1 .

The user behavior of the plugin mainly follows @amber-cd 's idea , with modifications that are more practical to implement. You can check in detail at the PR description.

It would be great if you could provide any suggestions of the user behavior/bugs you encounter or any other general feedback to help improve the plugin. Thanks in advance!

[HollowMan6]

Now the plugin has already been published to NPM. You can also find the demo and blog post here: https://groups.google.com/g/blockly/c/1qb-M8HZYzY

[gonfunko]

Closing this out now that the plugin created by @HollowMan6 is available.