2026.02.17 Weekly Meeting

Community Weekly meetings
1

Tomorrow, we will be having our next weekly hangout at 10:00 AM ET until 11:00 AM ET.

Anyone is welcome to join at this link: https://bit.ly/slicer-googlemeet-hosted-by-kitware

Agenda:

Please post to this thread to put a topic on the agenda! We will try to prioritize agenda items during the meeting.

Thanks
Sam and Ebrahim

2

I will attend and will be available to assist with whatever is needed to ensure telemetry can be tested on a server.

3

I would like to discuss vtkAddon and if it would make sense to move it to the Slicer repo.

4

I would like to discuss Slicer#9010.

5

If we have the time, I would also like to discuss Slicer#9030

6

Notes from the meeting:

Telemetry (Bernardo, Sam)

  • Bernardo ready to ensure telemetry can be tested on a server.
  • Sam ready to work on this soon.

CTK website (Sam)

  • MediaWiki is very end of life, and Sam is in talks to get the ctk website taken down.
  • Sam working on exporting site data to put up something new
  • Original Wiki
  • Work in progress here

Slicer wiki (Andras, Sam)

  • Where are we at with getting rid of this?
  • Some images don’t load

vtkAddon (Thibault)

  • Does it make sense to move vtkAddon to Slicer?
  • Doing so would address a pain point in SlicerCore sdk deveopment.

vtkAddon consists of things that should be integrated into VTK but for some reason or other the VTK team did not take ownership of them, so they remained as Slicer-specific things that belong in VTK.

Could it be split? Some things in vtkAddon belong in Slicer, while other things in vtkAddon really belong in VTK.

But splitting would be a whole thing, and simply moving the entire thing into Slicer would vastly accelerate getting slicer core sdk together.

CI process for putting together vtk-based python packages

Thibault suggests: Move vtkAddon to Slicer, so that it can go into SlicerCore, and then afterwards we could still split things up.

Andras suggests: vtkaddon could remain a standalone, pure VTK-based Python package installable via pip to maximize its usability outside of Slicer. Future looking: Slicer should adopt modern VTK development patterns like trampoline classes to make its components more Pythonic and allow for easier derivation and customization. The same modular packaging approach should be something we can use to spin out other Slicer components, like MRML nodes, as independent Python packages to simplify the overall build process.

Teem (Thibault)

(General agreement that this is a good change.)

Windows build machine (Ebrahim)

  • Auto-login now set up on a new user on bluestreak, which is configured to run the nightly job while logged in.
  • Test failures related to missing opengl things are gone, making Windows dashboard clean again.

pip_install features PR (Ebrahim)

  • Slicer#9010
  • Andras can review
  • Move to slicer.packaging, re-importing to util only pip_install/pip_uninstall and what’s for backwards compatibility (to encourage people to start using slicer.packaging)
  • Inline documentation is too verbose
    • Maybe some examples can be moved to being tests

Test failure due to Windows clipboard (Ebrahim)

Could also just remove the test as it’s not an essential test.

Maybe in general it’s better not to access the clipboard in automated tests… imagine a password being in someone’s clipboard.

Claude SKILLS file(s) for 3D Slicer dev

  • Discussion on creating a sub repo to store claude skills to help Claude in developping Slicer based extensions & applications.
  • Skills would be separate from the main Slicer repo as the skills will vary depending on context.
  • Steve will test Claude skills on his end before creating / submitting a dedicated repo on the subject
7

are there upcoming meetings please? I would like to join

8

They are on Tuesday mornings – look for the announcement for tomorrow’s which should come out soon.