Shadow block custom context menu

[francisc...@ubbu.io]

Hi everyone!
I'm working on adding a custom context menu to a specific shadow block, but the issue I'm facing is that the menu that appears is always the parent block's menu. My use case involves dynamically adding and removing these shadow blocks from this parent block via some buttons. I want to provide an extra option to remove a specific block from the middle using the context menu. These blocks need to remain as shadow blocks, so they can't be removed from the input. Does anyone have a workaround? I've ran out of ideas and I wanted to avoid patching the gesture class.

Thanks in advance

[Christopher Allen]

Hi Francisco,

I'm working on adding a custom context menu to a specific shadow block, but the issue I'm facing is that the menu that appears is always the parent block's menu.

Hmm, yes: it is the case that the gesture code treats most gestures as belonging to the first non-shadow parent, except for (left) click gestures.  It's possible that could be changed but it would probably be a breaking change, not just in principle but in practice for many developers using Blockly in their apps.

 

My use case involves dynamically adding and removing these shadow blocks from this parent block via some buttons. I want to provide an extra option to remove a specific block from the middle using the context menu. These blocks need to remain as shadow blocks, so they can't be removed from the input. Does anyone have a workaround? I've ran out of ideas and I wanted to avoid patching the gesture class.

Can you explain why you want these blocks to be shadow blocks?  We normally only expect developers to use shadow blocks in situations where there will be a single block attached to a single input, and typically the attached block is a simple reporter (block with just one field, one output, and nothing else).  In that case it makes sense to provide a shadow block so the user doesn't have to add a small block just to provide a fixed numeric or string value to that input.

In any other situation, especially ones where the user is adding, removing or reordering multiple blocks, we'd normally expect "real" (non-shadow) blocks to be used.  That will certainly be much more intuitive in most cases than adding shadow blocks with buttons.

(One possible exception might be that blocks like lists_create_with or text_join could provide shadow blocks for their inputs—but in that case I would expect that rearranging shadows would be the result of rearranging the inputs on the parent block, which would be done using the parent block's mutator, not controls on the child blocks.  (This needn't require having a mutator icon + flyout—see the block-plus-minus plugin for an alternative UI.)

A good guideline might be to consider whether the controls you've added to the child block make any sense if that block is not connected to a certain type of parent block: if they don't, there's a good chance that the control belongs on the parent block instead.

Best wishes,

Christopher

[francisc...@ubbu.io]

Hi Christopher,

I'm working on recreating a function block (image attached) using the new version of Blockly, where users can dynamically add or remove multiple shadow argument blocks. However, most blocks cannot connect in this setup, with a few exceptions. I also implemented a custom dragging strategy that allows new argument blocks to be created by dragging shadow argument blocks.

Now, I want to enhance the shadow blocks by adding a context menu that allows users to edit or remove the selected block. I experimented with making the argument blocks non-movable instead of using shadow blocks, but this approach didn’t work with the dragging strategy.

I think this is the case: "We normally only expect developers to use shadow blocks in situations where there will be a single block attached to a single input, and typically the attached block is a simple reporter (block with just one field, one output, and nothing else)."

I'll take a look lists_create_with but I think this is a different use-case. If anyone can think of a workaround it'd be much appreciated.

Thank you in advance

[Christopher Allen]

Hi Francisco,

I'm working on recreating a function block (image attached) using the new version of Blockly, where users can dynamically add or remove multiple shadow argument blocks. However, most blocks cannot connect in this setup, with a few exceptions. I also implemented a custom dragging strategy that allows new argument blocks to be created by dragging shadow argument blocks.

Now, I want to enhance the shadow blocks by adding a context menu that allows users to edit or remove the selected block. I experimented with making the argument blocks non-movable instead of using shadow blocks, but this approach didn’t work with the dragging strategy.

Aah, I see.  And the fix that would make the context menu work with shadow blocks would also break your instantiate-on-drag code, because at the moment trying to drag a shadow block actually drags the non-shadow parent, whereas with the "fix" it would be the shadow itself that was dragged.

This explains the difference between your instantiate-on-drag code and the copy-on-drag code Aaron posted in the other thread: I believe his code uses non-shadow blocks, so the code lives on the child block and copies itself, rather than living on the parent and creating a block of a different (child) type.

I would certainly encourage you to file a bug report / feature request (not sure which it technically qualifies as) for us to get context menus working on shadow blocks, but I think it unlikely we will be able to do that in the short term so in the mean time you might want to consider adopting the approach Aaron has.

Best wishes,

Christopher

[francisc...@ubbu.io]

I've been testing with shadow blocks, and while everything looks great visually, there's still the issue with the context menu. When I tried using non-shadow blocks as suggested, actions like copy/paste or undo/redo would result in an extra block being created. My theory is that this happens because a block is being created during the display update. Then, the block's state includes another block that replaces the created one, which disconnects the initially created block, leading to the extra block. I'm unsure how to work around this issue. Any suggestions?

[Christopher Allen]

Hi Francisco,

I've been testing with shadow blocks, and while everything looks great visually, there's still the issue with the context menu. When I tried using non-shadow blocks as suggested, actions like copy/paste or undo/redo would result in an extra block being created. My theory is that this happens because a block is being created during the display update. Then, the block's state includes another block that replaces the created one, which disconnects the initially created block, leading to the extra block. I'm unsure how to work around this issue. Any suggestions?

Apologies, but I can't quite visualise what you are describing here. Can you provide a screencap video (or series of still screenshots), including a clear explanation of what you do at each step?  Or perhaps better still a live demo page I can try, and and list of steps to reproduce the issues you note?

Best wishes,

Christopher