Cross-testing the Multi-select Plugin with other Blockly Plugins

[HollowMan6]

Check for duplicates

• I have searched for similar issues before opening a new one.

Problem

Test the integration with other Blockly plugins, apply fixes whenever applicable (something to start with is https://groups.google.com/g/blockly/c/MuL2Ln8SwDU)

Request

To start with:

Workspace-related

• Keyboard-navigation
• Shadow-block-converter
• Workspace-content-higlight
• Disable-top-blocks
• Plugin-strict-connection-checker

Blocks-related

• Block-dynamic-connection
• Block-shareable-procedures
• Block-test

We might want to check with other plugins as well later if time allows

Alternatives considered

No response

Additional context

No response

[HollowMan6]

The new changes in Blockly 11 may cause the compatibility issue with the backpack plugin again, so we should re-evaluate again after #39 is done
RaspberryPiFoundation/blockly-samples#2311

[changminbark]

Hi everyone,

My name is Chang Min Bark and I will be the GSoC contributor in charge of upgrading the multiselect plugin. I am also in charge of cross-testing the mutliselect plugin with other Blockly plugins. I am looking forward to contributing to this community!

Thanks,
Chang Min

[changminbark]

Quick update: The newly updated multiselect plugin works with the scroll-options plugin as well as multiple workspaces.

[changminbark]

Checklist:

Original

• Scroll-options plugin
• Backpack (Need to update UI in Backpack plugin side)

Workspace-related

• Keyboard-navigation
• Shadow-block-converter
• Workspace-content-highlight
• Disable-top-blocks
• Plugin-strict-connection-checker

Blocks-related

• Block-dynamic-connection
• Block-shareable-procedures
• Block-test

[changminbark]

Keyboard Navigation Plugin:

https://developers.google.com/blockly/guides/configure/web/keyboard-nav

Tested with the backpack plugin and multiselect plugin

• Enabling keyboard navigation
• Using default cursor across all levels
• Connecting blocks on workspace
• Moving a block on the workspace
• Detaching blocks
• Inserting a block from the toolbox
• Delete shortcut (look at note and comments below)
• Copy/paste shortcut (look at note and comments below)

Note: When editing a field (e.g. true/false block), I cannot use "w" or "s" to navigate through the field options. However, I can use the arrow keys to navigate through the field options. I don't know if this is intended behavior for the keyboard navigation plugin. I tested this with and without the multiselect plugin.

Note: I am not sure if there is a bug with the keyboard navigation's copy/paste function. The following gif was tested without the multiselect plugin. I cannot seem to reproduce it, so I am also not sure about this bug.

However, with the multiselect plugin, it seems to be holding two different copyData storages (so two different copy-pastes are running simultaneously with the shortcut).

What should be the intended behavior here? Should we incorporate the copy functionality of the keyboard navigation plugin into the multiselect plugin? I don't think this would be a good idea as not everyone will use both plugins at the same time. Do you have any other suggestions?

Note: When installing the multiselect plugin first, there is no error regarding the delete shortcut. However, when installing the keyboard navigation plugin first, we encounter this error:

I am not sure why we don't see this issue when we install the multiselect plugin first.

Multiselect Plugin:
Everything works as intended (use cases). There are no clashes as there are no overlapping use cases.

Note: The multiselect mode is activated when holding shift for moving around the keyboard navigation cursor, but this does not cause any unwanted behavior as the multiselect mode affects cursor/mouse behavior.

Backpack Plugin:
Everything works as intended (use cases). There are no clashes as there are no overlapping use cases.

[HollowMan6]

Note: When editing a field (e.g. true/false block), I cannot use "w" or "s" to navigate through the field options. However, I can use the arrow keys to navigate through the field options. I don't know if this is intended behavior for the keyboard navigation plugin. I tested this with and without the multiselect plugin.

The Keyboard Navigation Plugin is highly experimental, so I would expect this to happen. You can report it to the Blockly team.

Note: I am not sure if there is a bug with the keyboard navigation's copy/paste function. The following gif was tested without the multiselect plugin. I cannot seem to reproduce it, so I am also not sure about this bug.

However, with the multiselect plugin, it seems to be holding two different copyData storages (so two different copy-pastes are running simultaneously with the shortcut).

What should be the intended behavior here? Should we incorporate the copy functionality of the keyboard navigation plugin into the multiselect plugin? I don't think this would be a good idea as not everyone will use both plugins at the same time. Do you have any other suggestions?

That's one thing to think about. I guess the Blockly team doesn't have a good solution for this either (e.g. cross tab copy-paste and the keyboard navigation also have two set of copyData storages). Of course, we shouldn't incorporate the copy functionality of the keyboard navigation plugin into the multiselect plugin this time, but it would be good to work out some design so that people can connect the multi-select copyData storages with possibly other plugins /for other uses (extensibility).

Note: When installing the multiselect plugin first, there is no error regarding the delete shortcut. However, when installing the keyboard navigation plugin first, we encounter this error:

I am not sure why we don't see this issue when we install the multiselect plugin first.

This is exactly #41 Let me know if you have any insights on this one.

[changminbark]

The Keyboard Navigation Plugin is highly experimental, so I would expect this to happen. You can report it to the Blockly team.

This may be related to this issue: RaspberryPiFoundation/blockly-samples#2380

That's one thing to think about. I guess the Blockly team doesn't have a good solution for this either (e.g. cross tab copy-paste and the keyboard navigation also have two set of copyData storages). Of course, we shouldn't incorporate the copy functionality of the keyboard navigation plugin into the multiselect plugin this time, but it would be good to work out some design so that people can connect the multi-select copyData storages with possibly other plugins /for other uses (extensibility).

I think that a possible solution to this would be to implement what the multiselect plugin is doing in Blockly core. Instead of having the base copy/cut/paste function directly using the copyData of that one block/element, it should define a set (can be called copyData) that contains a set of each element's copy data (whether it be just one element or multiple). This can be used across different plugins that have their own copy/cut/paste shortcut functions defined.

This is exactly #41 Let me know if you have any insights on this one.

I found out the reason why this occurs. Currently, the keyboard navigation plugin allows for collisions when they register the key mappings for the shortcut registry while the multiselect plugin does not. This should be a simple fix by also allowing the shortcuts in the multiselect plugin to allow for collisions. However, I am not sure if this would be a good idea as other plugins may have copy/cut/paste shortcuts that behave differently. Having multiple copy/cut/paste functions would lead to unexpected behaviors. It would also be impossible to make an all-in-one copy/cut/paste functions for all the plugins. So I am not sure how to approach this issue.

If there is nothing else that I can investigate in, I will mark this cross-checking as done and move onto the next plugin.

[HollowMan6]

I think that a possible solution to this would be to implement what the multiselect plugin is doing in Blockly core.

You can discuss that with the Blockly team to see if this is feasible.

I found out the reason why this occurs. Currently, the keyboard navigation plugin allows for collisions when they register the key mappings for the shortcut registry while the multiselect plugin does not.

Yeah, I mean that and that's why I mentioned this here: https://groups.google.com/g/blockly/c/MuL2Ln8SwDU/m/9WihibDsAgAJ

This should be a simple fix by also allowing the shortcuts in the multiselect plugin to allow for collisions. However, I am not sure if this would be a good idea as other plugins may have copy/cut/paste shortcuts that behave differently. Having multiple copy/cut/paste functions would lead to unexpected behaviors. It would also be impossible to make an all-in-one copy/cut/paste functions for all the plugins. So I am not sure how to approach this issue.

You can try and see if it works when you allow for collisions. One of the solutions I proposed (guess, not verified) is to temporarily unregister the multi-select plugin key mappings when keyboard navigation is activated, and register that back when deactivated. You can also verify if this works/is possible or not. if you have any better ideas/comments, feel free to continue commenting under that thread.

[changminbark]

You can discuss that with the Blockly team to see if this is feasible.

I will send an email to them soon.

Yeah, I mean that and that's why I mentioned this here: https://groups.google.com/g/blockly/c/MuL2Ln8SwDU/m/9WihibDsAgAJ

I don't have access to comment on the thread.

You can try and see if it works when you allow for collisions. One of the solutions I proposed (guess, not verified) is to temporarily unregister the multi-select plugin key mappings when keyboard navigation is activated, and register that back when deactivated. You can also verify if this works/is possible or not. if you have any better ideas/comments, feel free to continue commenting under that thread.

I was able to do the temporary unregister and it seems to be working. Since it works, should I implement it into the multi-select plugin and push the change into the blockly-v11 branch?

[HollowMan6]

Yeah, I mean that and that's why I mentioned this here: https://groups.google.com/g/blockly/c/MuL2Ln8SwDU/m/9WihibDsAgAJ

I don't have access to comment on the thread.

Really? It's a public Google group.

You can try and see if it works when you allow for collisions. One of the solutions I proposed (guess, not verified) is to temporarily unregister the multi-select plugin key mappings when keyboard navigation is activated, and register that back when deactivated. You can also verify if this works/is possible or not. if you have any better ideas/comments, feel free to continue commenting under that thread.

I was able to do the temporary unregister and it seems to be working. Since it works, should I implement it into the multi-select plugin and push the change into the blockly-v11 branch?

You mean implement the "allow for collisions"? Sure, you can test that and once you think it's fine, it's always preferred to have that allowed.

[changminbark]

Yeah, I mean that and that's why I mentioned this here: https://groups.google.com/g/blockly/c/MuL2Ln8SwDU/m/9WihibDsAgAJ

I don't have access to comment on the thread.

Really? It's a public Google group.

You mean implement the "allow for collisions"? Sure, you can test that and once you think it's fine, it's always preferred to have that allowed.

The only problem I have encountered is that when we unregister the multiselect shortcuts when we are in the keyboard navigation mode, we cannot use the cursor to select/copy/cut/paste. We can only copy/cut/paste the blocks selected in the keyboard navigation mode. I have tried registering the original Blockly core shortcuts, but they do not allow for collisions and will run into an error with the keyboard navigation plugin. If you think this behavior is still okay, I will push it into the blockly-v11 branch of the multiselect plugin.