-
-
Notifications
You must be signed in to change notification settings - Fork 410
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider ability to 'upgrade' ViewerModel
to full Viewer
#6768
Comments
I think that we should promote using ViewerModel in headless mode. |
But we never instantiate a |
Or do you mean headless users should always instantiate |
For current usage we provide active viewer (last focused). How will you determine which viewer use? |
True. So no non qt viewer injection then? |
I think than in headless mode, user should provide own injection. |
I'm on board with disambiguating the use of |
Viewer
in headless modeViewerModel
to full Viewer
馃О Task
Currently, we have a single provider for the napari
Viewer
. This provider is used when plugin widgets request aViewer
, but also internally.Under the hood, the provider just calls and returns the
current_viewer
:This means even though the
Viewer
can exist in headless mode, theViewer
provider only works when qt and the window are present.Do we envisage a world where a plugin (or other API user) might want the headless viewer injected if the qt one is unavailable e.g. chaining commands, computing stuff on layers before showing the viewer, idk. If we think that's a valid use case, we should consider adding a provider for the headless viewer, with a lower weighting than the one we already have.
The text was updated successfully, but these errors were encountered: