In conjunction with imagej/imagej-common#12, we want to rework how SciJava Displays are structured.
The status quo:
- You have an
Object, which gets wrapped in a (UI-agnostic) Display. Each Display is a list of such Objects, rather than only a single Object. To visualize that Display, you then need a UI-specific DisplayViewer, which actually shows the Display's contents to the user somehow.
- In ImageJ, the type hierarchies are more complex: you have a
Data, which is wrapped in a DataView (e.g., Dataset wrapped in DatasetView, or Overlay wrapped in OverlayView). Then an ImageDisplay, which is a type of Display for DataViews.
We can streamline this. Let's have instead:
View, which wraps an Object, and contains visualization settings. Subtypes of view (e.g., ImageView) implemented as needed to encapsulate the appropriate viz settings.
- A
ViewService handles wrapping of Objects to the most appropriate View.
- In the case of images, there would be an
ImageView which has a position (while its wrapped Dataset does not).
Display, which becomes a UI-specific thing used by the UIService.
- In other words:
DisplayViewer gets renamed to Display.
- The old
Display no longer exists—we only support a single View per Display.
- We have a
DefaultView that is used for Objects with no particular need for visualization settings.
- To cover the need for multiple N-dimensional image objects (i.e.,
Datasets and Overlays) bagged together, we provide CompositeView, which composes a list of Views in a single composite space.
These changes would reduce the amount of names floating around—we would no longer need "viewers" but would only have Views and Displays. It would also help simplify the implementation of new UIs, at least from the perspective of understanding the execution flow.
In conjunction with imagej/imagej-common#12, we want to rework how SciJava
Displays are structured.The status quo:
Object, which gets wrapped in a (UI-agnostic)Display. EachDisplayis a list of suchObjects, rather than only a singleObject. To visualize thatDisplay, you then need a UI-specificDisplayViewer, which actually shows theDisplay's contents to the user somehow.Data, which is wrapped in aDataView(e.g.,Datasetwrapped inDatasetView, orOverlaywrapped inOverlayView). Then anImageDisplay, which is a type ofDisplayforDataViews.We can streamline this. Let's have instead:
View, which wraps anObject, and contains visualization settings. Subtypes of view (e.g.,ImageView) implemented as needed to encapsulate the appropriate viz settings.ViewServicehandles wrapping ofObjects to the most appropriateView.ImageViewwhich has a position (while its wrappedDatasetdoes not).Display, which becomes a UI-specific thing used by theUIService.DisplayViewergets renamed toDisplay.Displayno longer exists—we only support a singleViewperDisplay.DefaultViewthat is used forObjects with no particular need for visualization settings.Datasets andOverlays) bagged together, we provideCompositeView, which composes a list ofViews in a single composite space.CombinedIntervalet. al inimagej-common, which will facilitate this.CompositeViewwould be the closest thing to the currentDisplay, but would support recursive nesting ofViews, so that a proper object hierarchy can exist (see also Improve Display-DisplayView-Data hierarchy imagej/imagej-common#12).These changes would reduce the amount of names floating around—we would no longer need "viewers" but would only have
Views andDisplays. It would also help simplify the implementation of new UIs, at least from the perspective of understanding the execution flow.