In order to replace the data manager someday, more functionality has to be moved to the render window manager.
This basically includes the actions from the context menu entry of nodes in the data manager.
Description
Status | Assigned | Task | ||
---|---|---|---|---|
Resolved | kalali | T25601 Modernize render window manager | ||
Resolved | kalali | T24936 Extend render window manager to include functionality of the data manager |
Event Timeline
Which actions are needed in the render window manager
Rendering properties
- global reinit (bounding box of the whole layer stack for the selected render window)
- reinit (bounding box of a specific / selected data node of the layer stack for the selected render window)
- show only selected nodes
- toggle visibility
Visualization properties
- opacity
- color
- texture interpolation
- color map
Other
remove: can be implemented with the use of keyssave: is already implemented using the menu bar- details
Currently the context menu is created in the data manager; the actions are created all inside CreateQtPartControl-function. Actions are added according to the node descriptors. Each new node descriptor needs a change in the data manager view.
If we want to use a context menu in the render window manager we should discuss a different approach for a cleaner implementation that is reusable and easy to read / maintain.
One existing approach is to implement an mitk::IContextMenuAction-interface with a new concrete action and refer to this concrete action in a plugin.xml using the <extension point="org.mitk.gui.qt.datamanager.contextMenuActions">-tag. This allows to provide new data manager actions without the need to actually modify the data manager classes.
We could think about renaming this extension point so that it is clear that it can be used everywhere, where a data node context menu is needed (e.g. in the render window manager).
We could also provide a microservice-interface for data node context menu actions, so that each module / plugin can easily extend the set of available actions.
@kislinsk What was the original purpose of using the extension point mechanism for context menu entries? Does it make sense to use the microservice-approach so one does not have to modify or extend plugin.xml-files?
What are your thoughts about the context menu entries being defined inside the data manager class? I think about putting them somewhere else so that they can be easily maintained and reused (e.g. in the render window manager).
Discussed in the MITK meeting: actions will be kept, @kalali will split this task further
We start with using the decoupled data node context menu (T25056) with its basic actions inside the render window manager.
We decided to stick with the common actions for now. Discussions on how to (dynamically) customize the context menu can be found in the mentioned task and its subtasks.
Cherry-picked the new data node context menu.
Added new context menu to the render window manager view.
A flaw in the design of the custom context menu was spotted and will be addressed in T25643.