Ziyang Liu

I don't think it can be searched yet. also we may not want to categorize plugins based on their menu contribution. also just to make sure, by "File", "View", "Window",...

some of the trade-off here would be future-proof and deprecations. If we take a complete open approach, then there is an extra burden if we later decide not to allow...

Any @napari/core-devs want to provide opinions here in terms of where plugins should be allowed to insert menus? If everyone is on board with starting broadly and allow plugins to...

> From today's community meeting (my remarks): It would be nice if the plugin could contribute a dynamic submenu generated by a function called on menu creation. This may allow...

Porting over the whitelist we will be starting with from the discussion on NPE2 side: ``` Menu("/napari/layer_context", "Process Layer"), Menu("/napari/layer_context/projections", "Make Projection"), Menu("/napari/layer_context/convert_type", "Convert datatype"), Menu("/napari/tools/acquisition", "Acquisition"), Menu("/napari/tools/classification", "Classification"), Menu("/napari/tools/filters",...

Reading the original issue discussion, I hesitate to add UUID to layers. Though I don't think hash would work in this case (I don't yet find evidence that hash would...

I updated the test in my PR to not assert menu existence when there is no action registered, I don't think it makes sense to check for no-action menus anyway:...

@haesleinhuepf if you can help take a look here would be great, the list comes from the npe2 PR that you contributed to

> I don't necessarily mind declaring these menus manually, I do think it's part of the necessary curation/upkeep we'll need to maintain, especially as the list expands. This seems to...

I got feedback that the menu structure would need a bigger discussion and potentially a NAP to record the decisions as it is influential. I removed the tools menu migrated...