Refactor MenuNode to get rid of MenuExecutor, MenuCommandAdapterRegistry and MenuCommandExecutor #14217
Comments
1 task
tsmaeder
added a commit
to tsmaeder/theia
that referenced
this issue
Oct 30, 2024
Fixes eclipse-theia#14217 Makes menu nodes active object that can decide on visibility, enablement, etc. themselves. Contributed on behalf of STMicroelectronics Signed-off-by: Thomas Mäder <[email protected]>
tsmaeder
added a commit
to tsmaeder/theia
that referenced
this issue
Dec 27, 2024
Fixes eclipse-theia#14217 Makes menu nodes active object that can decide on visibility, enablement, etc. themselves. Contributed on behalf of STMicroelectronics Signed-off-by: Thomas Mäder <[email protected]>
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Description:
Currently menu nodes (whether they be sub-menus, groups, separators or actions) are pure data. users of the
MenuNodeinterfaces must implement all concerns like whether a menu item is visible in a context or how to adapt menu command parameters (for example, converting Widget instances to a view id to send to a plugin) themselves. In order to prevent breaking layers, we have introduced a registry infrastructure (MenuCommandAdapterRegistry) that allows in particular the VS Code contribution handlers to influence the execution and visibility of items in toolbars and menus.By making menu nodes active and polymorphous (for example, replacing the
commandfield with arunmethod), we could simplify the menu item handling and move the complexity to where it is needed and hide it from the rest of the system.The text was updated successfully, but these errors were encountered: