Nicholas Sofroniew

> or would you propose something else? right now our first example is ```python viewer = napari.view_image(data.cells3d(), channel_axis=1, ndisplay=3) ``` when i try and look as is through lens of...

> I would strongly vote for adding the wrapper method for something so core. What if we add a convenience method to our utils that takes the viewer as an...

Again, back in #619 we used to have `viewer.add_multichannel` and after much thought removed it. At the time we didn't have `split_channels` and added the kwarg. I agree now we've...

If I'm the only one that doesn't want the extra method, then I'm willing to be overruled and we can go with `viewer.add_multichannel_image`. Maybe @jni and @tlambert03 can make final...

> perhaps it shouldn't start with add_* then? we do have open ... which also doesn't directly point to a single primitive layer type, so other "adders" aren't without precedent....

> One "multiadder" adder that we can develop This is certainly intriguing to me - though it feels like it might get very complex, especially if we expanded for more...

I'd like to propose another alternative which would be to add public `split` and `merge` functions to the layers list (or viewer). One could then do things like ```python layer...

Hi all, coming a little late to this - first want to see if I understand correctly: The problem right now is that when we add new data to layer...

> The core problem, for me, with evented list is that someone could connect to such list event and someone else could assign new list to this attribute that will...

Thanks for making this issue! Right now I think blending is handled on the vispy side, but we should look into this!!