Developing napari plugins

Hey Napari devs,

First off - Napari is awesome.

As you know, I’m working on a plugin for napari for cell tracking and visualization. Currently, I’m using the add_dock_widget and abusing a few other methods to register layers etc. I want to transition this to a fully fledged napari-plugin, taking advantage of the new plugin engine - but would love some tips on how to approach this.

So far, most of the examples I’ve seen are for IO. In our case, there is the GUI, some associated worker threads and the track visualization layer too.

Project is here:


1 Like

Hi @quantumjot! Yes we :heart: what you’ve done with arboretum, and associated demonstrations! I think we all want to see this sort of thing available as a “proper” plugin, but exactly how we are going to support this sort of complicated extension is definitely still an open discussion. I’ll point you to a couple existing discussions, and also encourage others (@sofroniewn, @jni, @neuromusic) to weigh in here too:

So far, most of the examples I’ve seen are for IO

That’s because IO plugins are really the only type of plugins that are “officially supported” at this point. Ultimately, we want to extend our hook specifications to enable other types of plugins (e.g. analysis plugins that take a layer and return a layer, and even GUI plugins that wrap lots of functionality).

We need/welcome input on this, so if you haven’t already, read through the plugin docs linked above and then read this comment at github to get a sense for what a “new hook spec” proposal would need.

There has been a proposal to provide a hook specification that would probably meet most of your needs here… but there is also hesitation to “formalize” too much of the internal machinery by exposing big central objects (like viewer) to the plugin API before it is all more stable. So that’s still an open discussion. Your input on that thread is welcome as well.


Awesome - thanks @talley. That was what I understood regarding the current hook specifications. I’ll take a look at the github conversations, and see if I have anything useful to contribute. I agree that the viewer interaction seems like the most challenging one.

p.s. ha - just read “at least they know they’re being naughty” - that sums it up nicely!


Hi @quantumjot yes, we’d love it if you weighed in on those discussion - having more perspective from people that want to use the plugin API will definitely help make it better!!