Public access to Window.qt_viewer.layer_to_visual

🚀 Feature

I would like to have public access to Window.qt_viewer.layer_to_visual

Motivation

napari particles (https://github.com/maweigert/napari-particles), which I want to incorporate into a napari dock widget, uses

viewer.window.qt_viewer.layer_to_visual[self].node as well as self._viewer.window.qt_viewer.controls.widgets[self]. While I found the second one not being necesary for my purpose the first one seems to be.

[tlambert03]

ah, yeah you’re with @superchromix correct? This is going to be an interesting/challenging case. We don’t have a specification for creating a fully custom layer type as a plugin, so this is absolutely pushing the boundaries of what the plugin system is currently supposed to do. Those are two rather core objects to expose there (doing so would be somewhat akin to just going back to allowing private access). If any plugin can modify the vispy visual and layer controls, how does any other plugin (or the user) have any guarantee about the “state” that they might find those controls or visual nodes in?

@maweigert and I discussed this a while back as well and anticipated the difficulty of a custom layer type as a plugin, it would be fantastic if this particles layer could be added to core napari, since it as far as the underlying data model goes, it’s rather similar to points right? (though I recognize that functionally it’s actually a subclass of Surface).

In any case, all that said, this is clearly awesome functionality that we have to make accessible one way or the other. if we don’t want to try to get this into core, we need to have a more general conversation about how a custom layer should be added via plugins. As a very rough stab for a custom layer type spec, one could imagine:

contributions:
   - layers:
      - name: Particles
        model: napari_particles.particles:Particles
        controls: napari_particles._qt:ParticlesControl
        visual: napari_partiles._vispy:ParticlesVisual

where model is a subclass of napari.layers.Layer, controls is a subclass of _qt.layer_controls.qt_layer_controls_base.QtLayerControls and visual is a subclass of _vispy.layers.base.VispyBaseLayer.

what do @sofroniewn & @jni think? (and also @maweigert… your thoughts on how you as a developer would have this “ideally” integrated are greatly appreciated, while also keeping your dev hat on asking “should any plugin be able to do this” 😄)

[tlambert03]

I don’t have a good enough understanding of why Particles are different from Points to decide whether it should be the same layer.

This is also something that I discussed early on with @maweigert. I would also really love to see this be part of points, since at the end of the day our “layers” are more about data models tied to visualizations, and this very naturally fits into a set of coordinates visualized a certain way. The fact that it subclasses surfaces for the visualization seems to be more of an implementation detail to get around some GL limitations; from a model perspective, it feels very much like just another marker for the points layer though.