Open ctrueden opened 9 years ago
There is also the possibility of getting rid of View
altogether. Display
is UI-specific and operates on a particular type T
. All viz settings (e.g., dimensional position of a Dataset
) would need to then wrap into Dataset
itself. While this would be a slightly worse separation of concerns, it would greatly simplify the architecture, to the point where I'm thinking it's worth it.
So if you want to show the same image with same visualizations settings and position, great—add the same Dataset
to two different ImageDisplay
s or whatever.
And if you want to show the same image with different viz settings, we can have a by-reference Dataset
wrapper that exposes different settings, but for the same backing data object.
Further thought needed of course, but my current thinking is "the fewer class hierarchies, the better".
In conjunction with imagej/imagej-common#12, we want to rework how SciJava
Display
s are structured.The status quo:
Object
, which gets wrapped in a (UI-agnostic)Display
. EachDisplay
is a list of suchObject
s, 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.,Dataset
wrapped inDatasetView
, orOverlay
wrapped inOverlayView
). Then anImageDisplay
, which is a type ofDisplay
forDataView
s.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.ViewService
handles wrapping ofObject
s to the most appropriateView
.ImageView
which has a position (while its wrappedDataset
does not).Display
, which becomes a UI-specific thing used by theUIService
.DisplayViewer
gets renamed toDisplay
.Display
no longer exists—we only support a singleView
perDisplay
.DefaultView
that is used forObject
s with no particular need for visualization settings.Dataset
s andOverlay
s) bagged together, we provideCompositeView
, which composes a list ofView
s in a single composite space.CombinedInterval
et. al inimagej-common
, which will facilitate this.CompositeView
would be the closest thing to the currentDisplay
, but would support recursive nesting ofView
s, so that a proper object hierarchy can exist (see also imagej/imagej-common#12).These changes would reduce the amount of names floating around—we would no longer need "viewers" but would only have
View
s andDisplay
s. It would also help simplify the implementation of new UIs, at least from the perspective of understanding the execution flow.