Meeting Minute 2022-04-20
===

###### tags: `working-group` `plugin`

:::info
- **Date:** 2022-04-20
- **Agenda**
- [last week](https://hackmd.io/FJDjQLmlQKWKQI0nOUkLpA)
- [npe2#149](https://github.com/napari/npe2/pull/149) PluginManifest.properties
- [menu ideas w juan](https://hackmd.io/pBiPHwF1SPWHR68h9XwUwQ)
- - [Juan] [npe2#153](https://github.com/napari/npe2/issues/153) event callbacks
- [Andy]: input arguments to plugin functions:
- e.g. a "float_format" argument to a reader, "compression_level", etc
- possible motivation: napari#2288
- as a setting vs as a kwarg
- any objections to adding a non-required kwarg to a built-in?
- [Draga] [napari#4358] weird zarr stuff and npe2 reader handling of directories (iter_readers)
- **Participants:**
:::

<!-- Discussion goes here-->

## Next steps
<!-- Action items go here -->

- [Talley]: contact Curtis Rueden (and Gabriel Selzer) to move forward with adding JVM classpath to plugin schema.
- [Talley]?, [Juan]?, [SomeoneElse]?: drive forward basic menus (maybe without context keys?)
- small set of valid menus uniquely identified by name, and manifest declares this
- some menu items may be commands (not widgets), so may need to use context keys to define if they are enabled? or may be able to just inspect the signature?
- [Andy]: small PR for float_format
- use this as a driver for persisted plugin settings/preferences
- write up snap-to-grid issue

## Notes
<!-- Other important details discussed during the meeting can be entered here. -->
- properties/configuration
- driving issue here is JVM initialization
- if multiple plugins initialize through something like jpype or scyjava
- possible options
- merge this PR: general key/value store that could be used by plugins that need JVM
- pro: configuration is not made for this
- con: loose typing/schema makes this unclear
- con: may not be able to serialize
- con: this doesn't seem to solve the problem - napari would have to look for some specific key
- generic support for initialization of various libraries with stronger typing?
- define a napari-java/jvm plugin that other good plugins depend on
- just inform plugins to depend on scyjava?
- specific manifest entry for JVM classpath
- likely go with specific manifest entry for JVM classpath

- menu ideas
- may need to extend the context keys
- e.g. LayerListContextKeys
- menu is a more challenging usage that might require parametric constraints

- it is possible to reuse npe2 today next to napari (measurement engine, to allow register own measurement functions)?
- no

- writer settings/parameters
- two options
- 1. access global settings/preferences for the plugin
- 2. show a dock widget when there are optional kwargs

- [ ] After the meeting add the minutes to the 'working-group/plugins' folder of [napari/meeting-notes](https://github.com/napari/meeting-notes).

## Links

* [Calendar](https://calendar.google.com/calendar/u/0?cid=Y18zNXI5M2VjNnZ0cDhzbWhtN2R2NXVvdDB2NEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t)
* [HackMD space](https://hackmd.io/team/napari-wg-plugin)
* [Recorded meeting notes](https://github.com/napari/meeting-notes/tree/master/2022/working-groups/plugins)