Discuss and Approve NAP-3: Spaces

[brisvag]

Description

This is a (currently empty) PR to discuss and eventually approve NAP-3.

The discussion from the original PR (#4684) is already incorporated in the full text (if I missed anything, this is the time to point it out), so you're encouraged to take a look at the current full text, as it may differ significantly from the last time you read it all.

Depending on how the discussion develops, we might merge this as a simple update to the text in a few days, or we might end up agreeing on something and mark it as Accepted.

Here's a summary of what I think are the current points of contention:

• nomenclature (space vs state vs viewer)
• where these objects should live (individual viewer, a new app abstraction)
• what they should be (a serialization of part of a ViewerModel, a new model that is a subset of ViewerModel or a ViewerModel itself)

[andy-sweet]

• nomenclature (space vs state vs viewer)

I'll come back for more discussion, but I vote for anything but state. I dislike it because it's vague and general - any class could be called state (assuming it has some attributes/properties), so in my opinion nothing should, except maybe something referring to a dynamic system that might have states like STARTED, STOPPED, SHUTDOWN. Maybe I'd be willing to bend if it had a prefix or qualifier in front of it, but not sure.

[kevinyamauchi]

I agree with @andy-sweet that state is too generic. What about workspaces? This is how a similar concept is called in ubuntu.

I will also come back with more substantive feedback once I've caught up on the discussion.

[Czaki]

I really like workspaces. It is much more intuitive than spaces for me.

[andy-sweet]

I know it's future work and has already been discussed, but it's hard for me not to think about multi-canvas as I re-read this NAP again, especially with some of the recent demos and PRs. In particular, thinking about the hierarchy between spaces and multiple canvases seems important and might help us make decisions about some of the design questions here in a way that won't make future work harder.

It seems natural to me that a space lives at a higher level than a canvas. When I say canvas, I mean canvas + dims sliders - i.e. the visualization and control of all the layers' across all their dimensions. I could imagine having two spaces, one of which has a multi-canvas view, and the other just having a single canvas. If spaces is meant to reflect something like an OS' workspaces or desktops, that hierarchy also seems appropriate (i.e. a canvas kind of reflects a window in an OS).

Maybe a better way to add to the discussion here is to ask the following question. Assume we have a working implementation of multi-canvas and that I'm viewing 4 canvases in my current space. Now, let's say I create a new space.

Does the new space show 4 canvases arranged in the same way, or does it show the default single canvas?

[brisvag]

Maybe a better way to add to the discussion here is to ask the following question. Assume we have a working implementation of multi-canvas and that I'm viewing 4 canvases in my current space. Now, let's say I create a new space.

Does the new space show 4 canvases arranged in the same way, or does it show the default single canvas?

I think we are hitting again the same nomenclature confusion of viewer vs space, in that you are thinking of spaces as viewers, rather than a scene (maybe this is another name candidate, but has some overlap with vispy). I think I envision multicanvas differently:

1. each canvas in a multicanvas should have their own independent Dims and Camera objects, but they might be connected by events
   • so you can actually see 2D and 3D at the same time, or two different time points
   • but so you can also have ortho-view and grid-mode
2. each canvas should also allow different layer lists, so you can for example look at [image, segmentation1] on one side and [image, segmentation2] on the other.

These things would imply that each canvas would have its own space (which could be the same space, but also not).

What you seem to be referring to (opening a new viewer which has the same "layout" as another) is more akin to what @tlambert03 proposed in #4227, which I think is cool but orthogonal to what this NAP is trying to solve. This is maybe why the term workspace is a bit loaded, and might be counterintuitive for this application.

[andy-sweet]

These things would imply that each canvas would have its own space (which could be the same space, but also not).

Thanks for the explanation @brisvag! I'm comfortable with that definition.

[brisvag]

Im adding some comments from the eurasia napari meeting:

Sharing layers between spaces is currently not trivial unless we do one or more of the following:

• we duplicate them (but then changes are not synced between spaces)
  • we can first separate the data source for the layer, so duplicating a layer is not as expensive or hard to sync
• we first separate slicing state (as per the async project) so that the same layer can be sliced in different ways

Sharing layers between states is an important point of this NAP:

• two different spaces could have the same layer sliced differently
• or have the same same layer in combination with different other layers (i.e: different segmentations of the same image layer)

Another big benefit of this NAP would be for multi-viewer/multi-canvas support, by making it easier to open specific sets of Layers + Camera + Dims quickly, without having to start from scratch every time.

The above reasons might be enough to put this NAP on hold until we have settled on some specific paths for: data sources, slicing, and multicanvas. I will spend some more time thinking if I can come up with an API proposal that neither relies nor precludes the above; however, for now, if we exclude these plans from the NAP, all that's left is this:

A quick and easy way to switch between different ViewerModel states which include:

• independent layerlists
• Dims state
• Camera state

@jni proposed to create a plugin for this, for now, and we can see about the rest at a later time.

Personally, I'm ok with putting this on hold (for my current use case, a plugin like the above is good enough). What do youy all think about this?

[andy-sweet]

• independent layerlists

By independent, you mean that a layer cannot be in more than one layer list right?

• we first separate slicing state (as per the async project) so that the same layer can be sliced in different ways

This is a goal of the async slicing project, but it is not a must-have. I could imagine an implementation where we at least encapsulate the slice state to make it easier to ensure that it is atomically accessed, but where it still exists as state on the layer.

I think if you can implement this as an example or plugin first (I think you already have a solid working example right?), that sounds like a good plan. Having a good reference implementation or a working prototype will be super helpful to clarify details in the future too.

[brisvag]

By independent, you mean that a layer cannot be in more than one layer list right?

Yes!

[tlambert03]

This is a goal of the async slicing project, but it is not a must-have. I could imagine an implementation where we at least encapsulate the slice state to make it easier to ensure that it is atomically accessed, but where it still exists as state on the layer.

fwiw, the thing we've discussed that would make this possible is what we've referred to as "datasources" (where the layer doesn't actually have the data, but rather points to a datasource object that multiple layers could share). While that concept certainly comes up in the async discussions (because it would be useful there), as @andy-sweet, it's technically an independent aim that could be tackled on it's own. and it would make it much easier to have a layer representation in multiple places.

[sofroniewn]

@quantumjot you might want to give this a read based on our conversation right now!

[quantumjot]

[Note: I've only skimmed the discussion here]

I really want to suggest the nomenclature of Portals -- i.e. views on underlying "datasources" as Talley calls them. To me, the layers in napari have become more like containers of data with a visualisation on top, rather than the visualisations built with some data. It seems like there could be a solution whereby the Portals (haha, I'm going to keep using it) are dynamically created as views of the data built using combinations of existing visuals, slicing, cameras etc.

[brisvag]

I think we can close this one and put it on hold. @jni, should I open another PR to mark this a retracted, or else "paused", or something of sorts?