# napari community meetings (Pacific)

Friday 11am Melbourne / Thu 9pm NYC / Thu 6pm Pacific (Thu 1am UTC)

- Zoom link: https://numfocus-org.zoom.us/j/89631373371?pwd=iSmpAe0fJzAoaFlcKalarZgPeRCXWw.1
- Link to this HackMD: https://hackmd.io/VSaKh4hMQ12Bn7uWD_ij6A
- [Agenda :point_down:](#Agenda)

### Code of conduct
We strive to make the napari community a welcoming place! As such, the napari code of conduct applies to all community events. Please take a moment to review our [our code of conduct and incident reporting process](https://napari.org/stable/community/code_of_conduct.html).

### What this meeting is for

Community meetings are a resource for the napari community to get help directly from napari core developers in using napari or developing plugins. They are also a way to showcase plugins, cool demos, or new scientific use cases!

If this meeting was not at a convenient time for you, check out our [calendar](https://napari.org/stable/community/meeting_schedule.html#meeting-schedule)! We have meetings centered on the Atlantic, Indian, and Pacific oceans!

# Agenda

## 2025-09-04/05

Attendees: Sesan, Tim, Draga

## Topics

- draga wrapped up Eureka prizes
- we need to make some kind of announcement -- who will do this?
- share the video especially!
- should also video some stuff at the hackathon to share out
- ndev-settings
- Tim originally made napari-ndev https://github.com/ndev-kit/napari-ndev
- plugin to help manage a bunch of different microscopy file types
- now relies on bio-io
- hope was to get batch analysis in napari without using code
- use GUI to make workflow and then run it
- utilities
- opening/saving files, correcting metadata
- converting files to a more usable format
- APOC
- machine learning part
- workflow
- create a workflow and run in batch
- measure
- a thorough regionprops-based measuring tool, allows you to batch measure stuff
- spits out a nice dataframe, which you can edit the format of within the GUI
- eventually want to use nyxus which should be faster and more thorough than skimage regionprops
- settings tab
- allows you to setup reading preferences, scene handling, export settings etc.
- settings tab pulled out into its own plugin: https://github.com/ndev-kit/ndev-settings
- settings file contains information that can be passed to create_widget from magicgui
- widgets get created directly from the yaml within each group
- Draga: thinks there could be a settings contribution, but from the napari-side manifest directly
- We would need to add a settings contribution, that points to a settings file or a schema for a settings file (a validator)
- Draga is thinking about the reader settings - and that reader can offer settings - potentially we can populate the reader settings with that dialog
- This means we can link logic where we know what plugin reads the file, we can ask / expect that writer to be
- This also intersects with the idea of profiles / schemas, etc. Where we customize napari on load for a use case. Like geospatial, or a particular plugin
- We can combine all this into a profile
- Splitting out settings group (like in ndev-settings) makes it really nice to find what each plugin contributes, and split it out
- this is a step towards richer plugin manifest
- cell-tracking example
- Sesan working with pytorch folks to work out the learning step of cellGNN
- goal is to have it working with data of different densities/time resolution etc.
- looked at trackastra and it worked pretty well, but needs fine-tuning
- Draga gives her thesis
- Where do we spend human time?
- On fine-tuning a model?
- Or on iterative method (whether modifying labels or writing scripts, etc)
- We have a choice to make
- Will fine-tuning work?
- How do we know the time spent vs quality?
- Draga focuses on a non-learning method that gives *reasonable* results, then have methods that *help/guide* the users inspect, correct, evaluation workflow that helps the user understand error and estimate time spent.
- The big challenge is estimating accuracy from sparse data
- Sesan: there is no God model. Architecture needs to be understood to really use effectively

## 2025-08-21/22

Attendees: Tim, Sesan, Draga

### Topics

- Cell tracking example
- Sesan has updated to load with napari-ctc-io
- Looked at code for generating tracks, saw one potential bug with creating track records
- Sesan will update the script and work to get consistent single tracks
- Draga will look at the script for handling divisions and try to grok it before next meeting
- Hub-lite searching https://github.com/napari/hub-lite/pull/102
- Relevant conversation placed in the PR and opened issues, namely discussed:
- Ordering of results: decided it should be by latest release-date to highlight newer plugins
- Changes to the search (added to PR)
- including manifest categories in index
- We should consider filtering out template contributions https://github.com/napari/hub-lite/issues/105

## 2025-08-06/07

Attendees: Draga, Carol, Peter, Sesan

### Topics

- Cell tracking example PR: https://github.com/napari/napari/pull/8051
- reordering the data on the fly?
- potentially we could update the tracks layer API to support passing in a dataframe and an order list of columns that correspond to track_id, t, (z), y, x
- GEFF file format for track exchange: https://liveimagetrackingtools.org/geff/latest/
- reader/writer for napari tracks: https://github.com/live-image-tracking-tools/napari-geff
- traccuracy: https://github.com/live-image-tracking-tools/traccuracy
- Updates to the example:
- updated function to avoid pre-commit errors:

def load_tracks_data(data_dir, filename=""):
    """
    Load tracks data from a specific CSV file.
    Returns tracks data in napari format: [track_id, t, y, x]
    """
    track_file = data_dir / filename

    if not track_file.exists():
        print(f"Tracks file not found: {track_file}")
        return None

    try:
        df = pd.read_csv(track_file)
    except (ValueError, FileNotFoundError) as e:
        print(f"Error loading tracks file: {e}")
        return None

    print(f"Loaded tracks from: {track_file}")
    print(f"Columns: {df.columns.tolist()}")
    print(f"Shape: {df.shape}")

    if len(df.columns) < 4:
        print(f"CSV file has fewer than 4 columns: {len(df.columns)}")
        return None

    # Reorder to [track_id, t, y, x] format
    tracks_data = df.iloc[:, [0, 1, 4, 3]].values
    print(f"Successfully loaded {len(tracks_data)} track points")
    print("Data reordered to [track_id, frame, y, x] format")
    return tracks_data

- We also noticed the tracks look a little wonky, although we loaded them correctly. The next steps for checking what's going wrong are:
- download cell tracking challenge ground truth data. example for how to do that: https://github.com/live-image-tracking-tools/traccuracy/blob/main/scripts/download_test_data.py
- read the data using napari-ctc-io: https://github.com/bentaculum/napari-ctc-io
- `viewer.open(path_to_data, plugin='napari-ctc-io')`
- run current scripts on the ground truth data and see what tracks are generated, this should help us figure out if there are bugs in generating the tracks or in the code for assigning the track-id

## 2025-07-24/25

Attendees: Tim, Carol, Draga

### Topics

- npe2
- fixed CI and merged into Jaime's "pin GHA" PR, merged that too
- npe2api
- we're still using the XML-RPC api from back when bigquery was broken
- would be good to switch back to bigquery because it's more stable
- probably still good to keep XML-RPC script around in case bigquery gets borked again
- hub-lite
- as we're doing big rearchitecting/re-CSSing stuff we may want to set up a staging site so we're not deploying barely working things
- plugins with optional dependency
- would be nice if a plugin could specify in pyproject.toml which optional dependency group they would like installed from the plugin manager

## 2025-07-10/11

Cancelled

## 2025-06-26/27

- Juan, Peter, Sesan, Tim

### Topics

- grid order (Tim & Juan vs Peter 😜)
- The actual ordering is determined by the sign of stride, so you can change it in Preferences to `-1` to make it reverse
- need things to be more clear in the Preferences and the popup
- Better appraoch: have the direction to be a forward/backward or some other bool and "stride" be just a positive int
- Peter: stride implies skipping not stacking, so a more obvious name would be nice
- need to make a tracking issue for Grid/viewbox followups
- new tracking example (Sesan) PR #8051 https://github.com/napari/napari/pull/8051
- will add Tracks data
- share the code for generating it? maybe not a CI run example
- pooch caching: OS controlled location, maybe we should put under napari and not custom folder?
- need to add imagecodecs to `gallery` dependencies
- the `=` line must match the legth of title
- the zip file containers macOS files, use `zip` from the CLI
- napari-threedee is currently broken and needs released
- Juan suggests reaching out to pull napari-threedee into our maintenance
- then we can maintain and release
-

### Action items

- Juan: ask Kevin + Alister to move napari-threedee to napari org
- Tim: Make Grid follow up
- Tim fixed bug in layer rendering for stride
-

## 2025-06-12/13

- Juan, Tim, Peter, Draga, Carol, Sesan

### Topics

- Sesan: DOI object downloads
- issue with calling `napari.Viewer` in a script?
- possibly when upgrading the environment got messed up. If you install napari from conda, then install it in editable mode in the same environment, this breaks calling `napari.Viewer`, so probably a new environment would fix this
- Sesan is working on an example for tracking that is not using synthetic data. The PR will grab the data from a zenodo-stored URI
- once the environment issue is fixed, the PR should be ready to go!
- Integrating xarray with napari
- If you look at the example now we grab the metadata manually
- Would be good to eventually be doing all this grabbing automatically, but there would be a lot of magic involved
- Probably more of an internal discussion at the moment
- What are the possible limitations and what are the possible strategies
- e.g. could we develop a napari-xarray plugin and that's what the integration looks like?
- xarray used heavily with geospatial data, but we don't have spatial transforms in napari so that's the biggest limitation there
- would using the xarray tree be useful for implementing multiscale in napari?
- xarray also a big opportunity with bioimaging, even though adoption in the bio community is less widespread
- array + metadata is a big thing
- Tim: I think it could be pretty central to the way napari operates
- JNI: it's a very heavy dependency, so wouldn't want it to be a core dependency
- JNI: the whole metadata model is different in xarray to the way xarray handles metadata e.g. scale, transform, rotate
- PS: xarray may not be that big of a dependency if it enables a lot of use-cases for us e.g. named axes, metadata, lazy arrays
- should probably talk to the xarray folks whether they have plans to drop pandas in favour of polars/narwhals
- xarray also have their own lazy array datatype which they've developed to replace dask
- lots of issues with dask so if we could leverage xarray's array here and potentially have some performance/usability wins
- potential questions for Ian:
- what he's been working on
- what he thinks about a joint sprint
- what he thinks about using a flexible index and leveraging that in napari
- with xarray the status bar also needs a bit of attention because we're only ever displaying pixel coordinates so you lose the correlation between the pixels and the actual units/scale of the data
- would be nice eventually to have a public format stream for the status bar so that you can format the data being displayed in a way that's useful for your data
- Examples: how complex/simple should examples be
- Do we want more fully-integrated examples, or tutorials that leverage multiple examples together to create a more complete workflow/instructional guide
- DDP: for me the most useful trifecta of teaching materials is short snippet example that shows me how to do just one thing, the API docs for that one thing linking to the examples, and then wider-form, narrative-based tutorials that tie together multiple examples into a full use-case or workflow
- Carol: the gallery should be ordered to put the most motivating/rich examples at the top and keep the more involved or more snippety examples at the bottom, rather than just sorting alphabetically
- Also an important question is how can we enable folks using real data for examples, rather than just the sample-data/randomly generated data that we use because it's easy to provide
- JNI: I think for data the correct solution is use remote data that is cloud-friendly. The data should not be bigger than the viewer i.e. you'll never load more pixels than pixels on the screen, as long as you have multi-scale data
- Tim: what "rules" do we have about pulling remote data? As long as it's a public license e.g. CCBY and CCBYNC are fine
- Draga: we need a 'remote data protocol' on our end, to give a canonical way to include grabbing remote data into an example
- playing around with DOI objects is a bit tricky but can be figured out
- would also be good to have a "checklist" of how to make your remote-data "napari example ready" e.g. small, publicly accessible, public-use license, manual download instructions where reasonable
- PS: would also be super useful for the example to also include how you can manually download the data
- Gifs in the gallery?
- we could update the gallery capturing code to read a little "animation language" that we then take and produce the animation while building the gallery
- `napari._qt.qt_event_loop.get_qapp().processEvents() # Ensure the window is done rendering before taking a screenshot`

### Actions

- Juan: Create a general topic asking for ideas and potential use-cases in leveraging xarray in napari
- mention that napari, xarray and xarray-bio folks will all be at scipy and it would be great to get a pulse-check on how xarray is being used today, and what ideas folks have
- Sesan: will add a remote data protocol for contributing to examples
- Tim: will update #7991 to summarize our examples discussion

## 2025-05-29/30

- Draga, Carol, Peter, Juan

### Topics

- No keyboard way to navigate the layerlist i.e. up/down on the keyboard or something
- would be good to open this as a good-first-issue and keep it around for scipy
- On Windows you can install napari, jupyter etc. and everything launches but you get no ipython kernel, so that has to be installed separately
- could that be a missing dependency with latest release of jupyterlab?
- now we can open wholeslide images with napari-tiff and imagecodecs, but the pyramid higher levels don't load
- so you only get the downsampled layers because the max texture exceeds OpenGL limit
- we should consider multiscaling instead of downsampling: https://github.com/napari/napari/issues/7149
- Peter's suggestion might tie the layer closer to the rendering front-end
- Ideal solution would be for the vispy layer to set the multiscale value on the image layer, rather than the image layer doing the guessing
- every vispy layer has a reference to the 'napari' layer though so we should be able to tell the layer to do the multiscaling - from the vispy layer
- the other option: can we just split the image into multiple textures and tile them together?
- the downside to this is that vispy doesn't scale well with large numbers of textures, so it's almost like having lots of layers in the viewer
- there is also a tiled image visual which we may want to explore
- Peter should post the little script for discussion, as it's something we may want to entertain
- would be good if we actually told the user what downsample factor is e.g. in the warning
- rasterizing inconsistencies
- we decided converting edges to labels shouldn't take into account edge-width because the edge-width is strictly a visualization feature not part of the data
- however we've previously also claimed that points diameter is part of the data, not a visualization feature
- but this isn't really true because if you save out a points csv, you don't save the diameter alongside it
- we need to make sure we're consistent with what we count as data and what we count as strictly viz
- potential "solution" lies in how we handle features i.e. if you set edge-width to a feature column, or points size to a feature-column, that should "count" as data
- tricky bit with that is our writers don't usually write features
- we should have our points writer save features alongside the points data
- we should also use geojson for saving our shapes layers
- there is a geojson plugin but not actively maintained, we should consider bringing that into the napari org
- Carol reporting from PyCon
- Marimo notebooks could be something to explore
- Peter has tried working with them and couldn't really get napari going but this was a while ago
- Hub-lite
- npe2api stuff should be finished this coming week, making sure our data quality is right
- Peter reports using the hub-lite is actually really nice, with easy access to the pypi and github links and quite responsive
- we probably want to consider ways to serve up a filterable table of plugins, might be nicer than just having endless dropdowns in the filters
- switch-over is June 30th. Will currently aim for June 15th-ish to add a banner to napari.org and current napari-hub to point people to the new URL

## 2025-05-15/16

- Draga, Juan, Tim, Sesan

### Topics

- 0.6.0 - is conda-forge the right way to install it?
- yes, all releases are on conda-forge, and you could argue it's the best way to install napari
- resurrecting the release channel which hopefully should be an easier spot to refer to for information
- could we get pre-releases on conda?
- we do have a channel there, but we don't know how to use it
- 0.6.1 release debrief
- vispy ready on conda-forge
- https://github.com/napari/napari/pull/7925/files
- pre-release and get Peter to test it
- Juan will play with it
- Tim has played with it - the overlaps seem to be a little offset, but it **could** just be an internet-speed issue
- potential tracks layers improvements
- would be nice to colour tracks by state e.g. motility
- could be done using a tracks `color_by` property
- add a dataframe to the layer that contains for each cell and time what the property is
- then you can switch the color by feature in the GUI
- super brief example in the docs: https://napari.org/stable/howtos/layers/tracks.html#setting-the-track-color-with-features
- Sesan might work on a richer example
- #7923 is also a new issue: toggle 2D/3D doesn't work if layer isn't centered
- only from the keybindings
- looks like there's an issue with the `toggle_ndisplay` firing twice which means it turns on and then back and you end up in the original state
- works from command palette but that's a separate function
- seems like it's an issue with shortcut dispatch
- confirmed that it also happens with toggle theme: you can't toggle theme if your layer is not centered
- it's definitely a focus issue: someone is stealing focus from the viewer (?) or **two** things are receiving focus from the viewer, and **both** are executing it
- but when you move the layer focus is on canvas so that works
- TLDR: when the canvas has focus, viewer shortcuts are triggering twice
- goes back to at least 0.5.0, so it's not an urgent fix
- we should look into this: if the fix ends up being relatively quick, we should definitely do it. If it's a tricky fix and needs a lot of surgery, we should just wait for the app-model work to be complete and make sure that fixes it
- Discussing updates to `napari-plugin-template` that make it easier to automate PRs/cron jobs to update test matrices and improve test coverage and testing of pre-releases
- if we improve copier template, how can we make it easier for plugins to incorporate these features
- definitely don't want to overreach by opening a bunch of noisy PRs for plugins, or take over maintenance
- could definitely do lots of announcements and stuff when new major changes to `napari-plugin-template` occur

### Action items

## 2025-05-01/02

- Draga, Juan, Tim, Sesan

### Topics

- Bug reported in plugins zulip: labels layer from uint32 breaks napari when `visible=False`
- could be related to some type changes made to the `slicer`s
- Tim's plugin can't add `Labels` layers anymore i.e. it runs for a bit but doesn't add labels
- also afterwards you can't add labels or any other layer with the click button
- Tim is going to investigate and get an MRE
- Cadence of releases
- hoping to go back to fast cadence
- for minor releases we should be able to avoid scope creep and be more ruthless with delaying PRs to after release
- would be good to have the release manager from the prior release overlap with the current release for handover/pairing
- Sesan working on tracking and looking at tracks layer in quite a bit of depth
- we suggested he add an example with his brightfield cancer cells!
- Cool zarr samples repo!
- https://idr.github.io/ome-ngff-samples/

### Action Items

- Tim: share gifs from his demo on general
- Tim: look into the labels issue and post MRE

## 2025-04-17/18

Attendees: Carol

### Topics

- No items. Meeting canceled.

## 2025-04-03/04

Attendees: Juan, Tim, Draga, Sesan, Grzegorz, Carol

### Topics

- Draga: more plugin manager stuff :face_holding_back_tears: (Carol: Let's get the open PRs on the repo merged. :smile:)
- Restart warning now fires correctly on install/uninstall and respects cancellation
- Going to merge both PRs today and also look at other PRs and merge if needed, otherwise close
- will also open issue for test coverage and limiting warning to core packages changed
- Carol and Juan: 0.6.0a1 release (Which should be merged and which should have milestone changed/removed?)
- #7739 should be merged soon
- merged #7742 :tada:
- merged #7770
- Carol will look at #7714 to try to get tests passing
- issues will be moved async
- Grzegorz: potential to organize a working group for streamlining pip/conda dependencies for deep learning workflows
- could bring people together from a wider community to work on reproducible installs for deep learning workflows
- could look at e.g. wheelnext
- Carol: could be potentially useful, haven't looked sufficiently at wheelnext to determine whether it's the "next" wheel or just another implementation
- shared memory between python environments could help
- core devs probably won't have time to work on it, but could provide a space and coordination for the working group e.g. scheduling the meetings, hosting the meetings
- Juan: since we have such limited bandwidth wouldn't immediately dedicate a lot of effort, but could wait to see if it takes off on its own after the recent discussions
- Carol: maybe a new channel in zulip is a good idea to help people find a space to gather for these kinds of discussion, and potentially meet organically. Packaging is definitely still in flux, could reach out to Rolf at Quansight to ask his thoughts
- could invite folks to the US/Europe time meeting for initial discussion
- Sesan: definitely been on his mind as well, also would love to use a web version of napari, something very light that can be embedded in HTML, helping avoid packaging/installation instructions

- Carol: Trust and merging PRs (please put at end of agenda after other topics)
- once you have ready-to-merge the time to merge should be shorter, because otherwise you're not working on "clean" code as the PRs stack up
- checking the PR description is one of the main things, reviewer/merger should be checking that the description is updated and it becomes the commit message
- would be good to just get rid of ready-to-merge entirely, the milestone etc. check should happen on approval
- PRs also always sit for a few days so it's not likely people who want to look at it truly won't have chance
-

### Action items

- Grzegorz: reach out to Kyle & Ashley in core devs to invite them to next US/Europe meeting to discuss dependencies etc.
- Draga: merge/close PRs in napari-plugin-manager for 0.6.0a1
- Juan: make issue to add checklist to reviewer guide for pre-merge
- Juan: ping Grzegorz about making a daily updates channel (public) and making the PR update daily
- Carol: update the ready-to-merge action to trigger on PR approval instead (after alpha)

## 2025-03-20/21

Attendees: Peter, Juan, Grzegorz, Tim, Carol, Draga

## Topics

- Deprecations: Carol is fighting to get the PRs ready to go but there's some funkyness and some flaky tests. Two of the three should be almost ready, but we might push the next alpha to Monday.
- [#7732](https://github.com/napari/napari/pull/7732) - Tim would like feedback and discussion
- in original issue if you have text annotations and zoom out, the annotations don't scale and become a mess
- PR implements options to scale the text to the layer rather than the canvas size
- rather than connecting to zoom, it currently connects to layer scale_factor so that the scale is passed down for points and shapes layers
- problems:
- when mouse is not on canvas, scale factor is emitting constantly
- already an issue which Grzegorz tried to fix but it totally broke shapes highlighting so it's still around: https://github.com/napari/napari/issues/7071
- possibly leads to inconsistent updates
- also leads to scale factor update when you move off canvas because the scale factor is recalculating and firing with a different value
- text is now float not int to allow smooth scaling
- GB: scale factor was mostly introduced for highlighting of elements so that when you zoom it changes border thickness. When you move off canvas, scale factor changes so the highlight thickness changes...
- Aside: tracks layer also has text but it's not connected via text manager so it's not relevant here, but we do need to eventually add the text manager to tracks layer
- the scale factor should maybe be split into two different attributes: one for this hovering edge thickness thing, and one "real" scale factor that just does what is expected
- we figured out the issue with the pydantic import
- discussed that we want to eventually remove rendering state from layer but adding this attribute won't be a huge change, and actually clarifies the current behaviour better
- Tim will update the PR
- status bar updates: definitely want monospacing on the numbers. Juan will have a look
- Peter will post a little snippet of how to update the formatting
- napari-plugin-manager
- tests failing for the "always show restart message" PR
- could fix them by just reverting the settings file to not use npe2 adaptor
- but people liked the idea of just deleting that message entirely and adding a modal to napari when you close the plugin manager to restart
- Draga will look at that instead
- Peter tried to update plugin manager to always use conda to install conda stuff, so pyside2 tests can run
- Grzegorz will have a look at this

## Action Items

- Peter: Send Juan example code for styling parts of the status bar
- Juan: look at Carol's deprecation PRs
- Draga: new PRs to drop old restart message when installing plugins and add a modal on closing plugin manager
- Grzegorz: look at plugin manager conda installation stuff

## 2025-03-06/07

Attendees: Peter, Tim, Carol, Draga, Juan, Grzegorz

- Release action items
- [Status bar PR](https://github.com/napari/napari/pull/7673)
- shows layer name and other attributes in the status bar
- shows **all** layers under the cursor position
- Peter would like selected layers only (maybe), and ability to turn it off in settings
- if you have properties on a shapes or labels layer, it's basically impossible to see anything
- Draga: it's definitely not an 0.6.0 feature, there's a LOT of things we need to work out
- Grzegorz: 0.6.0 could be the grid mode thing and showing all selected layer
- Carol: could be a togglable feature so that we can get feedback on it
- Let's see the minimal change i.e. grid mode change and only show selected layers status
- although note that with active layer, we see values even if it's invisible
- should elide filenames
- not clear whether we want the full layer name: value dict, or whether we should squish together coords/values/etc. of each layer
- we should also update layerlist to show the layer index
- Fix napari-plugin-template
- Tim just tried to use it and there's some concerns
- tox.ini didn't have a .jinja ending and didn't put the python version in there correctly : https://github.com/napari/napari-plugin-template/pull/29
- Carol's README update needs to go in: https://github.com/napari/napari-plugin-template/pull/21
- [Issue #30:](https://github.com/napari/napari-plugin-template/issues/30) should make defaults to use versioning, dependabot and github deployments
- issue with the git tags is if you download a zip from github, it'll never work installing it because they don't come with a git repo
- Codecov needs token now?
- we should be able to update the napari-plugin-template so we don't need token
- but maybe some complexity with orgs...?
- Should look at scientific python guide and point people to it, or just do that
- plugin manager issue: https://github.com/napari/napari-plugin-manager/issues/135
- i think it's because we constrain to numpy <2
- we should remove that constraint, because it's been out for long enough now so if plugins break it's time for them to update
- if a plugin pins pydantic<2 this might break us, so we should add a minimum pin version for napari-plugin-manager
- ping #reviews when things are green
- plugin manager npe2 adaptor update: https://github.com/napari/napari-plugin-manager/pull/131
- :point_up_2: add your agenda items here!

## Actions:

- Peter: open issue about adding layer index to the layerlist
- Juan: merge everything in napari-plugin-template
- Tim/Peter: test creating a plugin with the updated plugin templates
- Grzegorz: remove numpy 2 constraint for plugin manager
- Grzegorz: add PR to add Pydantic minimum pin to plugin manager
- Draga: give Tim and Carol permissions on napari-plugin-template

## 2025-02-20/21

### Attending:

- Sesan Ajina
- Tim Monko
- Carol
- Juan
- Peter
- Draga

- **Viewer handedness**: Juan recapped the changes to the axes ordering in [#7554](https://github.com/napari/napari/pull/7554). We have an issue open to update the docs ([docs/#570](https://github.com/napari/docs/issues/570)). Peter mentioned we should include the axes in the screenshots in [the example](https://github.com/napari/napari-release-tools/blob/main/additional_notes/0.6.0/highlights.md) that's going in the release notes.
- **Command palette**: Juan demoed. We know there are a couple of existing issues with it and Peter has opened a [tracking issue](https://github.com/napari/napari/issues/7611). We particularly discussed that if you open the console from the command palette, it doesn't give the console focus. After playing with it more we think the problem is that exiting the command palette doesn't return focus to the previously focused widget. Grzegorz will investigate.
- **Using npe2 adaptor by default**: Draga demoed.
- We noted that there's a couple of plugins with lots of users that will be affected by the lack of start-up behaviour e.g. `napari-skimage-props`, and users may not connect the plugin menus missing with the warning dialog. We will work on the dialog copy to make it simpler, list known potentially affected plugins i.e. all current npe1 plugins in a gist, and update the troubleshooting page with a general point e.g. "if you have installed a plugin and it doesn't seem to have done anything, try turning off the npe2 adaptor".
- Tim noted that if you turn on the `Use npe2 adaptor` setting in 0.5.6 bundle, with `napari-skimage-props` installed, napari crashes and won't restart. This is an already-fixed and released bug in npe2 and won't affect future bundles. Grzegorz mentioned you can hackily reset the settings on Windows by editing the title of the shortcut and adding `--reset`. He added this to the [existing issue](https://github.com/napari/napari/issues/4177#issuecomment-2672877450).
- There are a few changes required to the `napari-plugin-manager`. Draga opened [a draft PR](https://github.com/napari/napari-plugin-manager/pull/131) making the manager respect the adaptor setting, but is struggling with testing and will ping Grzegorz if she can't figure it out. We also need to drop Python 3.9 for the plugin manager. Draga will open separate PR
- **0.6.0 bundle**: We may need some updates to the packaging repo due to updated dependencies that may have broken things (see [packaging/#223](https://github.com/napari/packaging/issues/223)). Juan will take a look.
- **Shapes benchmarks**: Grzegorz is [working on](https://github.com/Czaki/napari/commit/671880a8f65a0615cba39bd5e3fbd4a5153e54e4) benchmarks for shapes triangulation performance. Will open a PR soon.

Action items:
- Juan: add axes to the viewer handedness example
- Juan: investigate any necessary changes for packaging repo for 0.6.0
- Grzegorz: investigate focus issue for command palette
- Draga: keep trucking on npe2 adaptor

## 2025-02-06/07

Attending: Draga, Grzegorz, Tim, Carol, Sesan, Peter

- Tim: needs help with PR [#7528](https://github.com/napari/napari/pull/7528)
- overall motivation: idea that napari is really good at quick loading and also creating figures for publication
- improve overlay experience for the canvas to support accessibility and figure export
- one aspect is exposing font-size via the UI rather than console
- what, if anything, is the difference between canvas font size vs. interface font size
- somewhere fontsize is being inherited in the GUI, but not clear where
- GB: there's also the concept of high-resolution screenshots newly introduced
- DDP: seems to me that there's two settings here: font-size inherited from the theme for the viewer interface and font-size overlayed over the canvas. Exporting figure should be somehow tied to the size of the exported figure
- PS: export seems like a separate issue, kinda like creating a powerpoint or poster, you match the font-size to the size of the figure
- PS: I actually think even overlay elements should be different - aspirational
- GB: no good mock-up for editing of scale bar
- PS: we should just have a dock widget with the scale bar properties
- GB: should persist in settings
- PS: yeah but settings should be default, and widget is for preparing a specific figure
- GB: saving presets
- Actions: issue for UX font size, overlay font size, export font size
- Tim will make issue
- Peter: Community feedback requested on small UI change PR: https://github.com/napari/napari/pull/7569
- layer button says pan/zoom but it doesn't zoom, zoom always works and in 3D it doesn't pan but orbits the camera
- this PR changes it to Move Camera
- We should make an issue for updating the tooltip to make it clear that the bracketed bit is a shortcut
- perhaps update to <> or []
- Draga will make issue
- Tim: grid mode
- why not add a separation between the layers?
- shift with a percent of data size?
- also setting canvas color irrespective of theme? [Old issue #3970](https://github.com/napari/napari/issues/3970)
- possibly also a keyword for export

## 2025-01-10

- Juan: wants to release asap, made an alpha candidate
- Flip handedness PR [#7488](https://github.com/napari/napari/pull/7488)
- Right shoe now looks like a right shoe, whereas previously it would look like a left shoe!
- Peter is a big fan, because mouse embryos are backwards also on main when loaded
- public data of the mice: https://www.mousephenotype.org/data/embryo
- Click on one of the orange or blue rectangles under E14.5-E15.5 or E18.5 MicroCT on the Embryo Data Availability Grid for any gene you’re interested in. There’s a download button for low res, high res, and analytics on the next page. Have fun!
- scroll down to Embryo Data Availability Grid
- e.g. https://www.mousephenotype.org/embryoviewer/?mgi=MGI:1922730
- triangulation
- to test it you need to install `napari[optional]` and then turn on the setting
- Peter says you need an example that you can use to show the difference in performance, because it may not be obvious
- Specifically, what's the expectation for the user
- is it going to fix shapes with holes?
- not sure, but Grzegorz reckons we should fix it in the compiled code because then it will be fast whereas the current PR for this is very slow

## 2024-11-12/13

- Wouter: https://github.com/napari/napari/pull/7209
- Draga: add test for malformed data
- Wouter: https://github.com/napari/napari/pull/7099
- Juan: 0.5.5 release, next steps
- Draga: npe2 feedstock
- https://github.com/conda-forge/npe2-feedstock/pull/26#issuecomment-2529236335
- Draga: layer controls refactor
- https://github.com/napari/napari/pull/7355/files
- :point_up_2: add your agenda items here!

## 2024-11-28/29

- Juan: xarray + climate data + napari demo
- including discussion about flipping axes
- Juan: review 0.5.5 release PRs
-
- :point_up_2: add your agenda items here!

## 2024-11-14/15

-
- :point_up_2: add your agenda items here!

## 2024-10-03/04

- RGB merge/split issue https://github.com/napari/napari/issues/1199
- Problem with merge to stack -> convert to RGB is that we may not know which axis to use as the RGB stack, so we need an actual GUI for selecting which axis should be used as the channels
- Problem with merge as RGB is that the ordering of the layerlist is confusing because first layer is at the bottom
- Juan thinks we should reverse on merge
- Draga thinks users will be confused by this
- Separate issue is that maybe we should reverse the order of the layerlist UI element, OR add indices to the layerlist so that it's obvious which way to read it
- Peter and Draga think the layerlist elements should be ordered top to bottom
- As a first pass though, we can just check the colormaps of the layers and use those, and raise error if the colormaps aren't assigned
- Juan to open an issue about the error messages staying up longer
- Peter is already working on PR for that, something is borken though
- advised to push it and ping Daniel
- Sesan joined! He's been working with Wouter-Michiel and dropped in to say hello. Working on exporting ROI screenshots
- pretty much ready, but trying to write test
- some confusion between when to use viewer and when to user qt_main_window
- implementation is pretty clear and clean, assuming we only take rectangular ROIs
- suggested just adding that to the docstring
- we return the list of numpy arrays if there is no paths
- we should use this for the test, rather than relying on writing to path
- https://github.com/napari/napari/pull/7209
- Draga's immediate next priority is to make the npe2 shim true by default and start raising warning dialogs when a plugin is shimmed
- this dialog should include a date for when the shim will be non-turn-offable
- :point_up_2: add your agenda items here!
- [Juan] (time permitting) [roadmap](https://github.com/orgs/napari/projects/24/views/2) revisit

## 2024-09-19/20

- [Juan] automatic reset contrast limits https://github.com/napari/napari/pull/5136
- Peter thinks the PR is confusing and too magic and opaque
- Juan, Draga, Peter think the solution should involve providing more information to the user to use the continuous contrast limits or the once button
- [Draga] refactor layer controls https://github.com/napari/napari/pull/6219
- high priority because long term it enables a lot of things
- functionality becomes even more critical if we decide to move to layer groups, another button for contrast limits etc.
- high value, but not a blocker of current functionality
- one concern is that it's a significant UI change
- might benefit from longer RC phase for a week/10 days
- docs videos might need re-recording etc.
- seems like folks actually **do** want this, so it would be a shame to fully icebox it
- Action: Draga will look at the PR implementation through the lens of whether it can be split up somehow for ease of review, and discuss with Daniel. Draga and Peter will play with the actual layer controls and raise any known issues. Goal is to actually get this in, ideally with a small revertable PR that actually does the swap. Need to also consider long-term keybinding changes
- [Juan] default step size for int spin boxes https://github.com/pyapp-kit/magicgui/issues/667
- Peter doesn't have much of an opinion but initial gut feeling is that default step size should be 1
- also suggested the hold and go faster, but Grzegorz thinks that would be a huge lift
- typing is the escape hatch though
- Draga thinks default that's not 1 is unhinged, especially since you **can** change it as a plugin dev
- related: superqt PR to make the slider endpoints adaptive
- PR: https://github.com/pyapp-kit/superqt/pull/172
- related issue: https://github.com/napari/napari/issues/6644
- [Draga/Lucy] Keybindings UX questions
- Should plugins be able to declare keybindings that overwrite napari defaults
- what do we do with a conflict here
- what about two plugins declaring the same keybinding
- JNI: plugins should be able to overwrite defaults, it's a very common usecase
- nothing should happen
- Peter: absolutely not, but that would change if I could see and change keybindings
- Lucy: that would be an option
- Peter: if a plugin is conflicting with **any** of my current keybindings, then on plugin **load**, I should be alerted that a plugin is trying to contribute conflicting keybindings, and given the option to discard them
- JNI: some kind of notification of conflicts is good. Options: yes overwrite all, deactivate all, inspect, don't overwrite but ask me later about this plugin
- Possibly long term we want to consider some form of "remember this response" option, when there are **lots** of plugins newly installed and the user will be faced with heaps of dialogs, but for now we are happy with just popping as many dialogs as it takes to resolve all plugins with conflicts
- plugin-plugin conflicts are the same situation, because the current keybindings are "mine". we don't want different behaviour in this case
- currently, plugins can "overwrite" keybindings by requesting the `viewer` and using the decorators to declare keybindings/mousebindings. Long term, this is behaviour we want to fully deprecate, as we won't easily be able to collect these keybindings and show them to the user for editing/disabling. we want plugin devs to fully move towards the declarative manifest keybindings
- npe1 deprecation
- a key priority
- Draga will prioritise planning and getting the ball rolling on npe1 deprecation ahead of implementing NAP6
- initial feeling from Peter and Juan was that NAP6 is more important
- Draga pointed out that there is a huge maintenance burden for it, and that removing all the npe1 code would greatly simplify contributing, and open up work on other key stuff e.g. improving our file opening behaviour, richer import/export dialog etc.
- this changed Juan and Peter's minds and they agreed that we should make concrete plans to deprecate npe1 and start adding warnings etc.
- we want to start adding deprecation warnings for plugins that can't be shimmed
- we don't want to turn off the shim right now, but we do **eventually** want to get rid of it and only support npe2 native plugins
- Draga will check
- why the 'use npe2 adaptor' checkbox seems off by default
- how many plugins are actually npe2 native
- if you have an npe1-shimmable plugin and use the adaptor, what happens with any "on import" stuff the plugin was doing
- Peter will update the issue about setting env var usage, because it might also affect the shim checkbox
- Juan agrees that we should decouple the conversation about adding 'start-up items' to manifest and npe1 deprecation. We don't want to wait for consensus and implementation on the former, before continuing with the latter

## 2024-09-05/06

- Draga & Lucy were in the weeds with keybinding implementations!

## 2024-07-25/26

- Andy
- Some progress on pushing feature based style encoding
- Vectors style encoding GUI: https://github.com/andy-sweet/napari/compare/style-collection...andy-sweet:napari:vectors-with-style
- two large parts to the properties work proposed in 2866
- use a dataframe to keep features, you can style based on dataframe features
- we have mechanisms to do this for points, vectors and shapes but shapes do it in their own way
- started on vectors layer to add features to the GUI!
- pulling out the `QtColorControls` into a super-widget that we should be able to use for other layers too
- contrast limits slider isn't done but probably needs to be
- Andy will open a WIP PR somewhere with a video so we can discuss
- Peter:
- napari-plugin-manager repo:
- continual loading of plugins (current) or search only (ala VS Code)
- https://github.com/napari/napari-plugin-manager/pull/51
- current main of napari-plugin-manager, not yet released, has some improvements
- it tries to show you a browsable list of plugins, but it can't load all at once so it's a little odd
- VS code currently does a 'search-based' list where nothing comes up until you search stuff
- someone at scipy did like that you can browse within the install manager
- fetching is throttled so that you don't actually freeze the GUI
- but for some machines the fetch is very slow
- if you search, the search query **does** get brought up quicker
- draga: i lean towards only showing on search, and improving the filtering options with categories, file types etc.
- :point_up_2: add your agenda items here!

## 2024-07-11/12

- 0.5.0 released!!! 🥳
- Questions and demos welcome
- What's next? 0.5.1 discussion
-
- :point_up_2: add your agenda items here!

## 2024-06-27/28

- 0.5.0 release discussion
- Menu contribution
- Multi-canvas updates
- :point_up_2: add your agenda items here!

## 2024-06-13/14

- Menu contributions
- edit menu vs. layer menu items
- ng manifest
- context menu contributable
- restrict it first for now and then open an issue for opening it up and see if people want it
- layers menu always works on selected layer(s) or opens a widget is the guideline
- plugin developers need to be careful with the `enablement`s of commands to make sure they can actually act on the selected layer
- needs to go into the NAP
- builtins name next to command?
- Peter (and Juan and Draga really): emphatic no. builtins is just unqualified and at the top
- Copier/cookiecutter
- dealing with users running old command
-
- :point_up_2: add your agenda items here!

## 2024-05-30/31
- 0.5.0 Release
- 0.5 milestone should be aspirational
- patch version should be reserved for things that need to get merged
- docs about rendering (https://napari.org/stable/guides/rendering.html) need to be updated - async is different, see issue: https://github.com/napari/docs/issues/237
- https://github.com/napari/napari/issues/6925 - points in 3d issue
- bisect to find cause points to:
- https://github.com/napari/napari/pull/6896/files#r1602264036
- is reverting that change sufficient and correct?
- why do tests miss such a problem?
- author list
- plugin manager visibility
- npe2api is still not doing anything with the manifest visibility
- need to update it to not index hidden plugins at all
- should be done for 0.5.0
- Peter: towards 0.5.0 release:
- https://github.com/napari/napari-plugin-manager/pulls
- https://github.com/napari/napari/issues/6489
- update icon in Labels to match polygon in shapes
- change termination criterion to match
- match existing behaviour of Shapes but add preference for both tools that would set the behaviour preferred by Linux users
- :point_up_2: add your agenda items here!

## 2023-05-25

- Isabela can't attend, but wanted to let you all know that the additional layer controls design review time will continue. [Join on zoom](https://czi.zoom.us/j/96202485842) at [4pm Pacfic time (click for your timezone) on Wednesday, 25 May.](https://arewemeetingyet.com/Los%20Angeles/2023-05-25/13:00/napari%20viewer%20layer%20controls%20design%20review). Anyone can join!

## 2023-05-11

- Isabela: Layer controls update. We'll be setting some dedicated time to review the current mockups in a separate meeting. [Join on zoom](https://czi.zoom.us/j/97849109920) at [1pm Pacfic time (click for your timezone) on Tuesday, 16 May.](https://arewemeetingyet.com/Los%20Angeles/2023-05-16/13:00/napari%20viewer%20layer%20controls%20design%20review). Feel free to join!

## 2023-04-27

- Isabela: Layer controls update. Mockups at [napari/napari #5358](https://github.com/napari/napari/issues/5358#issuecomment-1526643253)
- Where to start contributing? Is there anywhere that's blocking someone's work?
- Reworking labels on issues may help find/prioritizing
- Good first issue label might be recently cleared. This seems good on the documentation side.
- [napari/napari #5608](https://github.com/napari/napari/issues/5608) autocontrast leads to oversaturation?
- :point_up: add new agenda items to this list! :point_up_2:

## 2023-04-13

Draga, Andy, and Juan were present and basically turned it into a mini PR-party. Discussed:

- [#5440](https://github.com/napari/napari/pull/5440) is cool! Should get pushed over the line.
- [#5648](https://github.com/napari/napari/pull/5648) got merged :tada:
-
- :point_up: add new agenda items to this list! :point_up_2:

## 2023-03-30

- Gen would like to know how to set up GitHub Actions CI for use with napari
- :point_up: add new agenda items to this list! :point_up_2:

## 2023-03-16

- Andy/Grzegorz/Juan: dask cache bug update ([Zulip thread](https://napari.zulipchat.com/#narrow/stream/212875-general/topic/dask.20cache.20error.20.235591/near/342365173))
- Isabela: Layer controls update. Working on the draft mockups!
- Grzegorz: design should be responsive, so that grouping can be more compact on small screens
- Juan: tabs could help, but only on small screens
- Grzegorz: important to be able to see mode of interaction at a glance, as well as selected label

## 2023-03-02

- Isabela: Layer controls update. [Takeaways from the work so far](https://github.com/napari/napari/issues/5358#issuecomment-1450945010) as we lead into visual design rounds.
- Juan: [The fourth dimension and the case of the missing slider - napari/napari #154](https://github.com/napari/napari-animation/issues/154)
- suspicion: [`qt_dims._update_ndisplay`](https://github.com/napari/napari/blob/c43a2e7c0181b5c4ed877fb1f59cae6f4d0ff0d2/napari/_qt/widgets/qt_dims.py)
- Andy: [Multiscale 3D rendering warning should happen once only - napari/napari #5588](https://github.com/napari/napari/issues/5588)
- the pyproject.toml only applies to tests
- suspicion: https://github.com/napari/napari/blob/c43a2e7c0181b5c4ed877fb1f59cae6f4d0ff0d2/napari/utils/notifications.py#L272

## 2023-02-02
- Kandarp: survey discussion (analysis requests; other questions of interest)
- https://bit.ly/napari-survey-sheet (comment on sheet or [email me](mailto:[e-mail]))
- Last year's analysis linked here: https://twitter.com/jnuneziglesias/status/1613839615030628353
- Isabela: Layer controls update. Sorting controls and working on competitive analysis.
- Looking for validation on the [sorting info](https://docs.google.com/spreadsheets/d/1RCHD4Wfb9D5Lf2eG_F-U4SgLTwtp_kLzudVJOysWW5Y/edit?usp=sharing). Is there a good place to get this?
- Juan: home page PR / docs WG share out
- Juan/Genevieve/Kyle: progress on multiscale rendering

## 2023-01-19
- Andy: planned work around named dims, types & units
- we've wanted named axes, types & units for a while
- especially since napari is a general purpose array viewer, we want this to be very lightweight
- JNI: big issue is that viewer's 0,1,2 dimensions and that's inconsistent with numpy broadcasting. Solution is to use -1, -2, -3 which is consistent for numpy broadcasting.
- AS: there are a couple of issues listed in this vein. They're a bit scary
- Issue by Alister on this [#3882](https://github.com/napari/napari/issues/3882)
- Issue by Juan: [#906](https://github.com/napari/napari/issues/906)
- Related issue by Nick: [#14](https://github.com/napari/napari/issues/14)
- AS: demo of napari-metadata plugin where he tests things out. One problem: axes order is set for all layers in the viewer, not for each layer independencly
- AS: Two approaches
- prototype, NAP, etc.
- initially, I'm taking the exercise the existing napari API as far as it will go to support the analysis workflows to understand where it breaks down, and whether a plugin solution could be good enough for both CZI and viewer
- also a good way to test & share something without putting burden on community for building, reviewing & consensus
- plugin is intended as something to share more easily internally at CZI
- it's public and it's already exercising what we could do, how it could work
- main limitation is dims are viewer wide and we highlight limitations with that
- single unit for scale bar per viewer, and it does actually adapt as you zoom in and out
- very very experimental plugin: https://github.com/andy-sweet/napari-metadata
- Draga: [command palette PR](https://github.com/napari/napari/pull/5483/files#diff-4a91486b6af0fd2c8031ee31c536776b6827299e0eb42f485826d4562270d3db)
- We definitely have concerns about the widgetiness of the changes in components
- Would like this to ideally be a thinner layer on top of `app-model`
- I'll follow up with a comment and then look into it a bit further to come up with a hopefully leaner path

## 2022-12-22
- Announcement: Take the short napari annual survey! https://bit.ly/napari-survey-c
- The team uses the survey to capture big picture feedback, that is vital to ensuring napari serves the needs of the imaging community and making strategic changes.
Every 10th completed survey respondent will receive a $100 Amazon gift card.<br>
Please share with all your napari-using colleagues and friends!
- Command search palette scope and design share out ([issue #5340](https://github.com/napari/napari/issues/5430))
- Feedback
- to close out the search, one option is to use the esc key
- top search result to be selected by default
- potential to start with a list of potential commands to give users an idea of what's possible
- [NAP-6](https://github.com/napari/docs/pull/77) is live on contributable menus :tada:
- Brief intro
- Current discussion

## 2022-10-27

- Isabela: [Plugin manager and bundled app installation manager](https://github.com/napari/napari/issues/4952) work has been happening! I want to spread the word and invite you all to give feedback.
- Now that the plugin manager tracks the plugin install source (ie. pip or conda), maybe that should also be surfaced in `napari info` since it is already something asked for in support tickets.
- For the installation manager, how does a default napari install get chosen? It may be that the lastest installation is default by (ha ha) default and can be changed manually. This needs to be confirmed.
- Meeting frequency and purpose. The calendar has a lot of meetings on it, but meetings like this have been lighter on the agenda. Is this what we want? Where is a good place to have this discussion?

## 2022-10-13

- Kandarp + Justin: Demo and feedback on napari hub [activity dashboard feature](https://www.figma.com/proto/d3t84J9Uzmj0GZnYROzdQX/Activity-Dashboard?page-id=854%3A8139&node-id=854%3A8144&viewport=109%2C201%2C0.14&scaling=min-zoom&starting-point-node-id=854%3A8140&hotspot-hints=0&hide-ui=1)

## 2022-09-29

- FYI: Participate in UX study on evaluating plugins with metrics!
- Sign up [here](https://calendly.com/imaging_czi/plugin-metrics-study?utm_campaign=2022h2&utm_source=meeting) for a 45-60 minute session or [learn more](https://napari.zulipchat.com/#narrow/stream/212875-general/topic/Participate.20in.20UX.20study.20on.20evaluating.20plugins.20with.20metrics)
- Andy: release update
- may branch to free up `main`
- let's do it
- `imshow` improvements
- should just be updating default parameter values
- macOS briefcase-based bundle test volunteers?
- https://github.com/napari/napari/pull/5152
- artifacts: https://github.com/napari/napari/actions/runs/3152777529
- Genevieve: Napari on M1, some xcb errors
- "source of truth" is https://forum.image.sc/t/napari-tensorflow-aicsimageio-stardist-care-n2v-pyclesperanto-running-native-on-apple-silicon-m1/55051/40
- But Genevieve says issue is conda is failing right now on empty environment -- possibly dependency has been updated and broken install?
- There are no M1 mac instances on Github actions, but they are available on CirrusCI. This is new, so no-one has looked into setting this up yet.
- Switching from pyqt5 to pyqt6 might help sidestep this problem (there are more wheels available for pyqt6, it's better supported)

## 2022-09-15

- Andy/Juan: [NAP-4](https://github.com/napari/napari/pull/5052) / [arch group update](https://napari.zulipchat.com/#narrow/stream/296574-working-group-architecture/topic/Meeting.202022.2F09.2F13/near/298820492)
- Juan: [NAP-5!](https://github.com/napari/napari/pull/5084) (sorry, I'm excited it's finally public :sweat_smile:)
- Draga: can folks weigh in on [#5079](https://github.com/napari/napari/issues/5079)
- [:point_up: add items here :point_up:]

## 2022-09-01

- nathan: plugin working group
- app model
- should form backbone of command structure, replacing ActionManager
- tracking issue: https://github.com/napari/napari/issues/4860
- app model includes menu items
- existing menus are getting migrated to new menu system
- there is one core one that needs to reviewed/pushed forward
- Qt menus are automatically populated after this
- in-n-out: independent of app model
- used in app model
- jordao: graph layer update
- not too much recent progress
- also not blocked
- working with nodes only, but for large numbers of nodes (e.g. 5m)
- andy: arch working group
- PR up for review against main: https://github.com/napari/napari/pull/5003

## 2022-08-18

- Andy: Async updates. [napari/napari #4959](https://github.com/napari/napari/pull/4959) needs review!
- Peter: color map work!
- Adding the `minimum` blending mode (along with inverted color maps, tooltips, and status bar message).
- Andy: "A key point is that the canvas background color is also blended with the images."
- [Discussion #3914](https://github.com/napari/napari/discussions/3914) and [PR #4875](https://github.com/napari/napari/pull/4875). Related [PR #4201](https://github.com/napari/napari/pull/4201).
- Isabela: plugin manager design changes are on the horizon. Follow the discussion and/or add your thoughts at [napari/napari #4952](https://github.com/napari/napari/issues/4952). I'm trying to loop in other plugin manager issues as well to see if this work can help close some things.
- related to [packaging working group roadmap](https://github.com/orgs/napari/projects/20)
- Blank [calendar](https://napari.org/stable/community/meeting_schedule.html). [The issue](https://github.com/napari/napari/issues/4933) might be resolved by [napari/napari #4944](https://github.com/napari/napari/pull/4944)

## 2022-08-4

- Jun: NPE2 questions about the desired user flow and use cases for plugins adding to menus.
- Isabela: design and development community feedback. Informal look into the questions and potential actions to make sure I (and maybe other designers!) can support you all better.
- Immediately actionable:
- Clarify repo labels. Is `design` referring to napari’s architecture design, or UX/UI design?
- Community clarity on what design includes. So far there has been a focus on visuals only, which is fine, but not complete in my mind.
- We can auto-assign issues to designers, how do we decide when we need review on a PR? And what do we need to provide so it can be reviewed (ie. screenshots for when design review is requested)?
- Future actions we can take:
- Documented design system/approach (even based on the current state and not waiting for some ideal version)
- Identify why some contributors do not want to add UI/contribute to the viewer? Is that something we are okay with? Do we need to support them differently?
- Identify common napari units and design choices we have made for them already.
- Notes
- [PR notes in spreadsheet form](​​https://docs.google.com/spreadsheets/d/11CR_dDg3OX1dnDrJgMHEm-z5f-Go9HoIFnw_Ld9q2dY/edit?usp=sharing)
- [PR notes as “card” slides](https://docs.google.com/presentation/d/1AH7K0XHF3ZyIsQK-OtEslOae6IQnJ69E8uyL7Tc3NcY/edit?usp=sharing)
- Discussion about user interaction design (vs visual design)
- Lots of inconsistencies with user interaction behaviour across different layer types, whenever different modes selected, etc. Should be more consistent.
- Zoom behavior is different on different layers and doesn't always have visual indicator https://github.com/napari/napari/issues/4837
- There must be so many more of these inconsistencies, how do we figure out where they all are?
- [Previous design hueristics audit 2020](https://github.com/napari/product-heuristics-2020)
- Do a keybinding comparison across different layertypes
- Do we need slightly more complicated tasks than the last UI design audit, so we can find
- Missing user interactions
- slice interpolation for labels (experimental PR over at zarpaint https://github.com/jni/zarpaint/pull/32)
- propagation of a new label ID across timepoints (Draga wants this. Perhaps https://www.napari-hub.org/plugins/napari-nD-annotator could help?)
- Gen wants a label "laser cut" function. Eg: two touching nuclei in a labels layer, you want to cut across the join to separate them. Sure, you could try a watershed split, but that's a bit slow and often you have to re-merge extra unwanted fragments later. Instead, what I want is like a label laser line that will relabel several slices deep at once. This will relabel pixels across the join, but leave any background pixels untouched. Then I can use the fill tool on one side of the touching nuclei.
- TODO: Draga/Gen to add an issue (first in zarpaint? Then in napari proper)

## 2022-07-07

- Juan/Nick: NumFOCUS meeting
- Andy:
- Isabela: [Re: 06-09 discussion](https://hackmd.io/VSaKh4hMQ12Bn7uWD_ij6A?both#2022-06-09) of [layer control UI work](https://github.com/napari/napari/issues/3975#issuecomment-1029514216) since we had a different group of people today.

## 2022-06-23

- Nathan: npe2 update
- Nathan: menu items
- how does one plugin declare it wants to go in another plugin's menu
- what to do with name clashes
- napari/npe2#161
- hackmd -> nap. Nathan+Juan to schedule time and hack
- Draga: cookiecutter
- Juan+Andy: tiny async code mergeable?

### Action items:

- point to plugin issues npe2 issue in Zulip
- nathan + Juan to hack on napari menus nap

## 2022-06-09

- Jun/Jaime: Request for comments for [NAP-2 approval](https://github.com/napari/napari/pull/4602). Main discussion points are summarized in the PR description.
- Isabela: layer controls UI
- Following up on [work from way-back forever ago](https://github.com/napari/napari/issues/3975#issuecomment-1029514216)
- Three angles to consider: consistent controls (ie. slider, drop down, etc.) for layer controls, how the tabs interact, how we sort/group layer controls ([messy sorting ideas started here](https://docs.google.com/spreadsheets/d/1RCHD4Wfb9D5Lf2eG_F-U4SgLTwtp_kLzudVJOysWW5Y/edit?usp=sharing)).
- Isabela: another alt text event in August?

## 2022-05-26

- Release update:
- revert supporting both napari builtin plugins
- add formats support for our npe2 builtin reader
- change display name to 'napari-builtins'
- Future: pull out builtins to its own napari-builtins package

- Jun<>Draga: ABRF GUI file opening workflow

- napari <> [astronomers](https://foggie.science/who-we-are.html) meeting happened this morning
- background: "We primarily use napari for visualizing 3D gas information in the galaxy evolution simulations called FOGGIE (Figuring Out Gas & Galaxies In Enzo, where Enzo is the name of the code the simulations are run in). We typically use yt (https://yt-project.org/) for reading in the datasets and quantitative analysis, but yt does not have an interactive tool so “playing around” with visualizing the data is very difficult."
- their requests
- A read-out of the vector of the angle of view, so that the same angle in the viewer could be reproduced at a later time
- This is viewer.camera.angles
- Axis ticks or some other way to get a physical location/size of a particular feature identified by-eye in the visualization
- viewer.scale_bar.visible = True
- viewer.scale_bar.unit = 'Mpc'
- A way to visualize a large amount of particle data in 3D
- Andy helped them resolve this live: setting particle size < 1
- Didn’t quite have time to mention this one, but: a way to save the viewer image to file that’s maybe a bit more streamlined than taking a screenshot
- setting a tracks layer for a "parcel" instead of a point
- ability to dynamically downsample their data (simulated data, ~20GB per snapshot (and they have ~2500 snapshots for a full simulation run))

- Talley: napari-spacemouse demo

- LayerGroups: Isabela proposed thinking of groups as labels rather than a tree/DAG (directed acyclic graph)

### Last week's Agenda

- Jun: Bundle PRs
- [Bundle update](https://github.com/napari/napari/pull/4422) PR needs to go in and needs review
- [Declarative bundle](https://github.com/napari/napari/pull/4404) file PR also needs discussion
- Draga: adding reader preferences to the GUI

## New action items

------

At the end of the meeting:
- Copy the contents of this document to a new file in https://github.com/napari/meeting-notes
- Clear out the Agenda from last meeting