Proposal: Pluggable common context menu items for BlockSvg
See original GitHub issueIs your feature request related to a problem? Please describe.
To add or remove a common context menu item from the block context menu requires either overriding of the Blockly.BlockSvg.prototype.generateContextMenu method, or adding a custom contextmenu generator to every block.
Describe the solution you’d like
A registry for these common items, which would include all of the standard items too, so that’s easier to override/remove these too.
Something like…
Blockly.ContextMenu.addCommonItem(fn, id?)
where fn is a function that generates a menu option (or null if it shouldn’t appear) given the block. The id allows you to remove items later. Also a weight could be added the item data to determine the ordering.
So all standard items will be added in this way to, allowing them to be removed easily.
Blockly.BlockSvg.prototype.generateContextMenu will just be a simple fn that iterates the registry and calls the item fns.
Describe alternatives you’ve considered
The only way we’ve been able to do this so far is to replace the generateContextMenu, call the original fn and then manipulate the list of options - filtering on the option text.
Additional context
I’m happy to submit a PR for this if everyone is happy with the concept.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:8 (4 by maintainers)
Top GitHub Comments
Agreed. A context object makes more sense. This would mean for a block context menu, the callback can access the workspace through contextObj.workspace.
To your second question, customContextMenu is for showing context menus on individual blocks, and would continue to coexist with this design. One thing that could be added to customContextMenu is the ability to include a weight in each context menu item returned, so we can sort everything by weight (rather than just appending it to the end as we do today).
Why even bother with a class for the ContextMenuRegistryItem? … it’s not clear what the constructor args are meant to be, why not just allow registration using a literal object?..