# 2026.03.31 Weekly Meeting

**URL:** <https://discourse.slicer.org/t/2026-03-31-weekly-meeting/46615>\
**Category:** Weekly meetings\
**Created:** [March 30, 2026, 5:15pm UTC](https://discourse.slicer.org/t/2026-03-31-weekly-meeting/46615 "2026-03-30T17:15:12Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sam\_Horvath](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/sam_horvath/32/3092_2.png) [@Sam\_Horvath](https://discourse.slicer.org/u/Sam_Horvath)\
**Post date:** [March 30, 2026, 5:15pm UTC](https://discourse.slicer.org/t/2026-03-31-weekly-meeting/46615/1 "2026-03-30T17:15:12Z")

</div>

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](https://bit.ly/slicer-googlemeet-hosted-by-kitware)

* * *

> **Weekly Meeting**
>
> **Starts:** March 31, 2026, 10:00am (America/New\_York)\
> **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

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [March 30, 2026, 5:20pm UTC](https://discourse.slicer.org/t/2026-03-31-weekly-meeting/46615/2 "2026-03-30T17:20:48Z")

</div>

We should check into this extensions issue:

> [@Mac preview release fails to load extensions in the Extension Manager](https://discourse.slicer.org/t/mac-preview-release-fails-to-load-extensions-in-the-extension-manager/46612/1):
>
> Hi, I installed the latest Slicer Preview Release 2026-03-29 (Slicer 5.11.0 revision 34472) on Mac. I noticed that the extensions are not loading in the Extensions Manager: I checked cdash and noticed many errors, even for extensions that should work like SlicerRT. Thanks!

---

<div class="post-metadata">

**Author:** ![amyers](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/amyers/32/82504_2.png) [@amyers](https://discourse.slicer.org/u/amyers)\
**Post date:** [March 31, 2026, 1:58pm UTC](https://discourse.slicer.org/t/2026-03-31-weekly-meeting/46615/3 "2026-03-31T13:58:59Z")

</div>

I have a question for @lassoan about Total Segmentator after installing it for the first time.

---

<div class="post-metadata">

**Author:** ![ebrahim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/ebrahim/32/13403_2.png) [@ebrahim](https://discourse.slicer.org/u/ebrahim)\
**Post date:** [March 31, 2026, 4:45pm UTC](https://discourse.slicer.org/t/2026-03-31-weekly-meeting/46615/4 "2026-03-31T16:45:58Z")

</div>

Notes from the meeting today:

## OHIF extensions (Steve Pieper, Gordon Harris, Bill Wallace, Alireza Sedghi)

Follow up from [2026.03.10 Weekly Meeting - #3 by ebrahim](https://discourse.slicer.org/t/2026-03-10-weekly-meeting/46418/3#p-132538-ohif-andrey-gordon-1)

Slicer exposes a lot of its inner workings to the outside python layer, so a lot of what we call “scripted modules” is code that reaches into what’s happening in Slicer at runtime and manipulates things. This is not done as naturally with web apps, at least with their traditional design. When you use Slicer you are not just using an applicaiton but also a development environment. When just using a web app like OHIF you are really more of a consumer of the app and not directly exposed to “hooks” to make changes.

OHIF also tries to have a marketplace, but you can’t do a 1-click (or few-click) install. Slicer you just click to install an extension and then restart. A web application you’d have to re-deploy.

Dynamic deployment is possible for OHIF and there is at least one example out there of a deployment where different users get different layouts and buttons and such.

Leaving dynamic deployment aside, what about just the marketplace aspect? Like the Slicer Extension index but for OHIF, even if it is only at first allowing developer-level OHIF users access additional funcionality.

Some examples of how to approach OHIF customization:

- [Viewport Overlay Customization | OHIF](https://docs.ohif.org/platform/services/customization-service/viewportoverlay/)
- [Segmentation Customization | OHIF](https://docs.ohif.org/platform/services/customization-service/segmentation/)

A small marketplace-like thing, _modes_: [https://ohif.org/modes](https://ohif.org/modes)  
Many of them are built-in, but for example [https://ohif.org/modes/nun-db-extension](https://ohif.org/modes/nun-db-extension) is something you’d install as an “extension”.

But it is different in many many ways to Slicer extensions.

[Project week](https://projectweek.na-mic.org/) will be at MIT at the end of June, and this is a good opportunity to get face to face discussions and plan out architectural experiments around these ideas.

## Extensions issue

> [@Mac preview release fails to load extensions in the Extension Manager](https://discourse.slicer.org/t/mac-preview-release-fails-to-load-extensions-in-the-extension-manager/46612/1):
>
> Hi, I installed the latest Slicer Preview Release 2026-03-29 (Slicer 5.11.0 revision 34472) on Mac. I noticed that the extensions are not loading in the Extensions Manager: I checked cdash and noticed many errors, even for extensions that should work like SlicerRT. Thanks!

It is being worked on!

---

<div class="post-metadata">

**Author:** ![ruffsl](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/ruffsl/32/80858_2.png) [@ruffsl](https://discourse.slicer.org/u/ruffsl)\
**Post date:** [April 6, 2026, 6:24pm UTC](https://discourse.slicer.org/t/2026-03-31-weekly-meeting/46615/5 "2026-04-06T18:24:03Z")

</div>

Is there still scheduled Weekly meeting tomorrow? I posted a draft PR for building with Nix:

> <https://github.com/Slicer/Slicer/pull/9101>
>
> FYI: This is the draft PR for Slicer development on Nix that I mentioned being a… WIP around two team meetings ago. 
> 
> \## Background & motivation
> 
> This PR adds a \[Nix flake\](https://zero-to-nix.com/concepts/flakes) (\`flake.nix\`) that provides a one-command, fully reproducible development environment for building Slicer from source on \[NixOS\](https://nixos.org), plus the upstream-friendly fixes required to make that build succeed against system-provided dependencies.
> 
> The flake itself is opt-in: it lives at the repository root and has zero effect on existing Linux/macOS/Windows build paths. The accompanying CMake fixes are not Nix-specific — they make Slicer's superbuild robust on any system whose dependencies don't follow the \[Filesystem Hierarchy Standard\](https://en.wikipedia.org/wiki/Filesystem\_Hierarchy\_Standard) (FHS), or that mixes system and bundled libraries.
> 
> \<details\>
> \<summary\>\<b\>Why a Nix flake?\</b\> (click to expand)\</summary\>
> 
> \[Nix\](https://nixos.org/) is a purely functional package manager with a \[25-year history\](https://edolstra.github.io/pubs/phd-thesis.pdf) and an \[80,000-package\](https://search.nixos.org/packages) standard library (\[Nixpkgs\](https://github.com/NixOS/nixpkgs)). A \*flake\* is just a \`flake.nix\` + \`flake.lock\` pair at a project root that declares the complete set of inputs (compilers, libraries, tools) and outputs (development shells, packages, container images) for that project.
> 
> For an existing C++/CMake project like Slicer, three properties of flakes are interesting:
> 
> 1. \*\*Pinned, bit-for-bit reproducible inputs.\*\* The companion \`flake.lock\` records the exact Git commit of every dependency tree (Nixpkgs, third-party flakes) plus content hashes for any prefetched sources. Two developers running \`nix develop\` six months apart get byte-identical Qt 6.10.2, GCC 15.2.0, CMake 3.31, system Python 3.12 + scientific stack, etc. (\[reproducibility\](https://zero-to-nix.com/concepts/reproducibility), \[pinning\](https://zero-to-nix.com/concepts/pinning))
> 
> 2. \*\*Hermetic dev shells.\*\* \`nix develop\` drops you into a shell where \`PATH\`, \`CMAKE\_PREFIX\_PATH\`, \`PKG\_CONFIG\_PATH\`, and friends point only at the dependencies declared in \`flake.nix\`. Tools accidentally installed in \`/usr/local\` can't leak in, eliminating "works on my machine" drift. (\[hermeticity\](https://zero-to-nix.com/concepts/hermeticity), \[dev environments\](https://zero-to-nix.com/concepts/dev-env))
> 
> 3. \*\*Declarative, one-file dependency manifest.\*\* Compare the \[current Linux build instructions\](https://slicer.readthedocs.io/en/latest/developer\_guide/build\_instructions/linux.html) — separate \`apt-get install\` lines for Ubuntu, Fedora \`dnf\` lines, manual notes about Qt path layout, version compatibility tables — to the equivalent Nix expression: a single attribute set listing \`qt6.qtbase\`, \`cmake\`, \`gcc15\`, \`python312\`, etc. The flake serves as both documentation and an executable build environment. (\[declarative programming\](https://zero-to-nix.com/concepts/declarative))
> 
> This is the same value proposition that has led projects like \[llvm/llvm-project\](https://github.com/llvm/llvm-project/blob/72d4ce9889a0bae9645de1a07cb051d0205cb964/lld/utils/speed-test-reproducers/collect.nix), \[openzfs/zfs\](https://github.com/NixOS/nixpkgs/blob/nixos-25.11/pkgs/os-specific/linux/zfs/generic.nix) to ship Nix flakes alongside their conventional build systems.
> 
> \</details\>
> 
> \<details\>
> \<summary\>\<b\>Why NixOS specifically? — and why the CMake fixes are not NixOS-specific\</b\> (click to expand)\</summary\>
> 
> \[NixOS\](https://nixos.org/manual/nixos/stable/) is a Linux distribution that takes Nix's reproducibility model and applies it to the whole operating system. Critically for this PR, NixOS deliberately rejects the \[Filesystem Hierarchy Standard\](https://en.wikipedia.org/wiki/Filesystem\_Hierarchy\_Standard): there is no \`/usr/include\`, no \`/usr/lib\`, no single Qt prefix. Every package lives at its own content-addressed path under \`/nix/store/\`, e.g.:
> 
> \`\`\`
> /nix/store/w4q31b93w262q2b75ri3jc7m3xd4i31h-qtbase-6.10.2/
> /nix/store/abc...-qttools-6.10.2/
> /nix/store/def...-qtdeclarative-6.10.2/
> \`\`\`
> 
> The Qt 6 installation that on Ubuntu lives under \`/usr/lib/qt6/{bin,include,lib}\` is, on NixOS, \*\*split across separate prefixes per Qt module\*\*. This breaks several assumptions in Slicer's CMake:
> 
> \- \`find\_program(lconvert PATHS ${qt\_root\_dir}/bin)\` only knows about qtbase, but \`lconvert\` lives in qttools.
> \- \`QLibraryInfo::HeadersPath()\` returns qtbase's include dir, so PythonQt's generator can't find \`QtUiTools\` headers in qttools.
> \- Slicer's \`External\_QtTesting.cmake\` and friends assume \`${Qt6\_DIR}/../../..\` is the install root.
> 
> These are not NixOS curiosities — the same split-prefix layout shows up in:
> 
> \- \*\*\[Conan\](https://conan.io/)\*\* package manager (each library in its own cache directory)
> \- \*\*\[vcpkg\](https://github.com/microsoft/vcpkg)\*\* with manifest mode (per-feature subpaths)
> \- \*\*\[Spack\](https://spack.io/)\*\* in HPC environments (per-package install prefixes by design)
> \- \*\*\[Homebrew\](https://brew.sh/)\*\* with \`--prefix\` overrides
> \- \*\*Container images\*\* assembled from multiple base layers (Qt from one layer, ITK from another)
> \- \*\*Distro packages\*\* with non-standard layouts (Debian's multiarch, Fedora modules)
> 
> Each CMake fix in this PR (\`find\_program\` fallback for Qt tools, \`find\_package(Qt6 ... CONFIG)\` auto-detection, system header path discovery for PythonQt, etc.) makes Slicer build on \*any\* of these systems, not just NixOS. Validation on NixOS happens to be the most rigorous test for FHS-independence because NixOS will catch any hard-coded path assumption immediately.
> 
> \</details\>
> 
> \<details\>
> \<summary\>\<b\>Why "system packages" (\<code\>Slicer\_USE\_SYSTEM\_\*\</code\>) is the force multiplier\</b\> (click to expand)\</summary\>
> 
> Slicer's superbuild builds \*\*VTK, ITK, DCMTK, Python, libffi, TBB, JsonCpp, RapidJSON, HDF5, LibArchive, zlib, OpenSSL, curl, SQLite,\*\* and dozens of other third-party libraries from source. On a current laptop a clean build from cold cache takes hours of CPU time even with \`ccache\`. This is fine for release engineering but painful for the inner loop of "edit a CMake file, see if it broke anything."
> 
> Nixpkgs already ships pre-built binaries for almost every one of these libraries, served from \[cache.nixos.org\](https://cache.nixos.org/) via Nix's \[content-addressed binary cache\](https://zero-to-nix.com/concepts/caching). When the flake declares (e.g.) \`pkgs.vtkWithQt6\` as a buildInput, \`nix develop\` substitutes a cached binary download for what would otherwise be a 45-minute VTK rebuild — and the \`flake.lock\` still pins the \*exact\* VTK version, so reproducibility is preserved.
> 
> The \[\`Slicer\_USE\_SYSTEM\_\*\` cmake flags\](https://github.com/Slicer/Slicer/blob/main/SuperBuild.cmake) already exist for many libraries but are sparsely implemented — several were \`FATAL\_ERROR\` stubs (\`message(FATAL\_ERROR "Slicer\_USE\_SYSTEM\_TBB is not yet supported")\`) and several superbuild children (CTK in particular) didn't propagate the flags to their own inner builds. This PR fills in those gaps for \*\*VTK, ITK, DCMTK, TBB, JsonCpp, RapidJSON, libffi, and Python\*\*, then exposes them in the flake via a \`useSystem\` toggle map:
> 
> \`\`\`nix
> useSystem = {
> VTK = true; # use nixpkgs vtkWithQt6
> ITK = false; # build from source — needs Slicer/ITK fork patches
> DCMTK = false; # build from source — must match ITK's bundled copy
> tbb = true;
> JsonCpp = true;
> # ...
> };
> \`\`\`
> 
> This per-library granularity matters because Slicer's superbuild pins forks of VTK and ITK with downstream patches that aren't yet in any released upstream version (e.g. ITK's \`AxesReorder\` API used in \`vtkITKImageSequenceReader\`, merged upstream as \[InsightSoftwareConsortium/ITK#5476\](https://github.com/InsightSoftwareConsortium/ITK/pull/5476) but not in any 5.4.x release). For those libraries we keep the superbuild path; for everything else we get the cache.
> 
> \</details\>
> 
> \<details\>
> \<summary\>\<b\>Scope & non-goals\</b\> (click to expand)\</summary\>
> 
> This PR \*\*does\*\*:
> 
> \- Add a \`flake.nix\` + \`flake.lock\` opt-in development environment
> \- Fix CMake assumptions about FHS layout in Slicer's superbuild and CTK
> \- Add real \`find\_package\` paths where \`Slicer\_USE\_SYSTEM\_\*\` flags were \`FATAL\_ERROR\` stubs
> \- Apply two NixOS+NVIDIA runtime workarounds via environment variables in the flake's \`shellHook\` (no source patches)
> \- Fix two GCC 15 / C23 compatibility issues that affect any modern toolchain, not just Nix
> 
> This PR \*\*does not\*\*:
> 
> \- Change the default build path on Ubuntu, macOS, or Windows (verified by reading every changed \`External\_\*.cmake\` to confirm new code paths are guarded by \`if(Slicer\_USE\_SYSTEM\_\*)\`)
> \- Require any reviewer to install Nix to evaluate the changes — the CMake fixes stand on their own and can be reviewed as ordinary CMake patches
> \- Add a new CI target (a follow-up PR could add a \`nix flake check\` job to \`.github/workflows/\`)
> \- Ship pre-built binaries or vendor any third-party source
> \- Modify Slicer's existing Linux build documentation (a follow-up could add a Nix section)
> 
> \</details\>
> 
> \## Summary
> 
> Adds a Nix flake providing a reproducible development environment for building Slicer from source on NixOS, plus the upstream-friendly fixes required to make that build succeed using system-provided packages instead of the superbuild's bundled copies.
> 
> The flake exposes a \`useSystem\` toggle map that drives \`Slicer\_USE\_SYSTEM\_\*\` cmake flags, allowing developers to opt into system VTK, DCMTK, TBB, JsonCpp, RapidJSON, libffi, and Python — substituting cached binary downloads for hours of compilation while still preserving full reproducibility via the \`flake.lock\`.
> 
> \## Changes
> 
> \### Build system fixes (upstream-friendly)
> 
> These fixes make Slicer's superbuild work on any system whose dependencies don't follow FHS layout, or that mixes system and bundled libraries. \*\*None are Nix-specific\*\* — they benefit Conan, vcpkg, Spack, Homebrew, multi-layer container builds, and distro packages with non-standard layouts equally.
> 
> \- \*\*\`ENH: Auto-detect Qt6 on CMAKE\_PREFIX\_PATH when Qt6\_DIR is not set\`\*\* — Probe for Qt6 via \`find\_package(Qt6 ... QUIET CONFIG)\` before falling back to Qt5, enabling package managers (Nix, Conan, vcpkg) to work without explicit \`-DQt6\_DIR\` or \`-DSlicer\_REQUIRED\_QT\_VERSION\`.
> \- \*\*\`BUG: Fall back to find\_program for Qt tools on split-prefix systems\`\*\* — On systems where Qt modules are installed in separate prefixes, \`lconvert\`/\`lrelease\`/\`lupdate\` live under \`qttools\` rather than \`qtbase\`. Add a \`find\_program\` fallback when the tool is not found at the expected qtbase-relative path.
> \- \*\*\`ENH: Add support for building against system TBB / RapidJSON / JsonCpp\`\*\* — Replace \`FATAL\_ERROR\` stubs in \`External\_tbb.cmake\`, \`External\_RapidJSON.cmake\`, and \`External\_JsonCpp.cmake\` with real \`find\_package\` paths and target-property extraction.
> \- \*\*\`ENH: Propagate system VTK/ITK/DCMTK flags to CTK superbuild\`\*\* — CTK is itself a superbuild with an outer and inner build; matching \`CTK\_USE\_SYSTEM\_\*\` flags must be forwarded, plus a \`VTK\_VERSION\` propagation fix in CTK's \`VTK.cmake\`.
> \- \*\*\`BUG: Guard vtkWin32OutputWindow.h include behind \_WIN32 in test drivers\`\*\* — The test driver template unconditionally included a Windows-only header (\`vtkWin32OutputWindow.h\`), breaking the build whenever VTK was compiled without Windows support. Use \`vtkOutputWindow.h\` as the primary include and conditionally include the Win32 variant.
> \- \*\*\`COMP: Fix ITK C flags for GCC 15 compatibility\`\*\* — GCC 15 defaults to C23, where empty \`()\` declarations mean \*zero\* parameters, not unspecified. ITK's bundled MINC library uses old-style \`()\` declarations with arguments, causing build failures. Force \`-std=gnu17\` for ITK's C code as a workaround. (Affects any GCC 15 user, not Nix-specific.)
> \- \*\*\`COMP: Disable PythonQt uitools wrapping for Qt 6\`\*\* + \*\*\`WIP: Disable multimedia support to work around PythonQt Qt 6 generator bug\`\*\* — The PythonQt code generator silently fails to produce uitools/multimedia wrappers under Qt6 due to unported Qt5-era class references in \`typesystem\_\*.xml\`. No Slicer code uses these bindings.
> \- \*\*\`ENH: Re-enable PythonQt uitools wrapping and fix NixOS Qt header paths\`\*\* — Patches CTK's \`PythonQt.cmake\` to pass \`--include-paths\` to the generator with extra Qt module include dirs discovered via \`find\_path(HINTS ENV CMAKE\_PREFIX\_PATH)\`. Restores \`qt.QUiLoader\` availability on split-prefix systems.
> \- \*\*\`ENH: Build CTK AppLauncher from source with Qt6 for native Wayland support\`\*\* — The pre-built CTKAppLauncher binary is statically linked against Qt5 and cannot load Qt6 platform plugins, producing \`Could not find the Qt platform plugin 'wayland'\` warnings on Wayland sessions. When building with Qt6, build the launcher from source so it dynamically links against the system Qt6.
> \- \*\*\`BUG: Fix CTKAPPLAUNCHER clone failure after Qt6 branch merged into main\`\*\* — Pin to a commit hash instead of the deleted \`add-qt6-support\` branch.
> \- \*\*\`ENH: Remove unused couchdb dependency from extension manager requirements\`\*\* + \*\*\`ENH: Remove deprecated nose dependency from python-numpy system check\`\*\* — Drop dead/archived Python dependencies (couchdb v1.2 archived 2017, nose deprecated 2015) that block system Python use.
> 
> \### Symbol-conflict fixes
> 
> When Slicer mixes system and bundled copies of the same library, ELF symbol interposition can cause runtime crashes during static initialization or destruction. These fixes pick a single source of truth per library.
> 
> \- \*\*\`BUG: Fix HDF5 dual-library symbol conflict by using system HDF5 for ITK\`\*\* — When system VTK loads \`libhdf5\_cpp.so\` alongside ITK's bundled HDF5, C++ symbol interposition causes \`H5::PredType\` static-initialization warnings on stderr at startup. Setting \`ITK\_USE\_SYSTEM\_HDF5=ON\` ensures a single HDF5 copy.
> \- \*\*\`BUG: Disable system DCMTK to fix crash on exit\`\*\* — System DCMTK and ITK's bundled DCMTK create dual \`DcmCodecList\` global registries; during shutdown the dynamic linker destroys them in undefined order, causing a \`free(): invalid size\` abort in \`libCTKDICOMCore\` triggered from \`libITKIODCMTK\`'s static destructors. Building DCMTK from source via the superbuild ensures a single copy.
> \- \*\*\`ENH: Disable system ITK in Nix flake\`\*\* — nixpkgs ITK 5.4.5 lacks Slicer-specific patches required by \`vtkITKImageSequenceReader\` (the \`AxesReorder\` enum on \`NrrdImageIO\`, \[merged upstream as InsightSoftwareConsortium/ITK#5476\](https://github.com/InsightSoftwareConsortium/ITK/pull/5476) but not in any 5.4.x release) and Slicer-specific remote modules (MGHIO, IOScanco). ITK must be built from source via the superbuild until ITK 5.5 ships and the remaining custom-namespace patch is upstreamed.
> 
> \### NixOS runtime workarounds
> 
> These two fixes address NVIDIA proprietary driver bugs that surface when running Slicer on NixOS. They are wired through environment variables in the flake's \`shellHook\` and \*\*make no changes to Slicer source code\*\*, so they have no effect on any other platform.
> 
> \- \*\*\`BUG: Fix QtWebEngine crash caused by NVIDIA kernel driver bug\`\*\* — Chromium (inside QtWebEngine) scans \`/proc/self/mem\` at startup, reading 64 bytes from every VMA. On systems with NVIDIA GPU mappings (driver 595.x Open Kernel Module, kernel 6.18+), this triggers a NULL pointer dereference in the kernel's \`nvidia\_vma\_access\` callback, which oopses and SIGKILL's the process. Fixed with a two-layer \`LD\_PRELOAD\` interposer (\`blockProcMem\`) that returns \`EACCES\` from \`open\`/\`openat\` and \`EIO\` from \`pread\`/\`pread64\` for \`/proc/self/mem\` (Chromium handles both errors gracefully), combined with \`QTWEBENGINE\_CHROMIUM\_FLAGS="--disable-gpu --no-zygote"\`. VTK's 3D OpenGL rendering is unaffected.
> \- \*\*\`BUG: Fix Volume Rendering crash caused by GLX context conflict on NVIDIA\`\*\* — VTK's \`vtkXOpenGLRenderWindow\` calls \`glXMakeCurrent\` during initialization (in \`vtkRenderViewBase\` → \`ctkVTKChartView\` setup for the Volume Rendering tab), which fails with X11 \`BadAccess\` on NVIDIA when another GL context is already current on the thread. Setting \`VTK\_DEFAULT\_OPENGL\_WINDOW=vtkEGLRenderWindow\` causes VTK to instantiate \`vtkEGLRenderWindow\` instead, avoiding GLX entirely.
> 
> \### Flake (\`flake.nix\`)
> 
> The flake provides:
> 
> \- A \`devShell\` with all build-time dependencies (CMake, GCC 15, Qt 6.10, libXt, OpenSSL, etc.)
> \- All runtime dependencies (\`xcb-util\`, \`pcre2\`, \`qt6.qtwayland\`, \`pipewire\`, \`libgbm\`, Vulkan ICDs)
> \- A \`useSystem\` toggle map driving \`Slicer\_USE\_SYSTEM\_\*\` flags
> \- \`ccache\` wired via \`CMAKE\_C\_COMPILER\_LAUNCHER\` and \`CMAKE\_CXX\_COMPILER\_LAUNCHER\`
> \- A \`slicer-cmake\` wrapper script for shell-agnostic flag passing
> \- \`gdb\` for debugging
> \- Python 3.12 via \`python312.withPackages\` with all packages required by the superbuild's \`python-\*\` system-package checks pre-bundled
> \- The two NixOS runtime workarounds (\`blockProcMem\` \`LD\_PRELOAD\`, \`VTK\_DEFAULT\_OPENGL\_WINDOW\`, \`QTWEBENGINE\_CHROMIUM\_FLAGS\`) wired into the \`shellHook\`
> 
> \## Test plan
> 
> \### Existing-platform regression (proves we didn't break anything)
> 
> \- \[\] Ubuntu 24.04 / Qt 5 build with default cmake flags completes and tests pass
> \- \[\] Ubuntu 24.04 / Qt 6 build with default cmake flags completes and tests pass
> \- \[\] macOS Qt 6 build with default cmake flags completes and tests pass
> \- \[\] Windows Qt 6 build with default cmake flags completes (vtkWin32OutputWindow include guard verified harmless)
> \- \[\] PythonQt uitools wrapping still produces correct bindings on Ubuntu (unchanged code path when \`--include-paths\` is not needed)
> \- \[\] CTKAppLauncher pre-built binary path still used for Qt5 builds
> 
> \### NixOS validation (proves the new path works)
> 
> \- \[x\] \`nix develop\` enters a working build environment on NixOS unstable
> \- \[x\] \`slicer-cmake\` configures the superbuild without errors using the \`useSystem\` defaults
> \- \[x\] \`make -j$(nproc)\` completes the full superbuild
> \- \[x\] Slicer launches and the main 3D viewer renders
> \- \[x\] Loading a sample volume (\`MRHead\`) and switching to the Volume Rendering tab does not crash
> \- \[x\] Opening the Extension Manager (QtWebEngine) does not freeze the process
> \- \[x\] Wayland session: no \`Could not find the Qt platform plugin 'wayland'\` warnings on stderr
> \- \[\] \`qt.QUiLoader\` is importable from Slicer's Python console

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [April 6, 2026, 8:28pm UTC](https://discourse.slicer.org/t/2026-03-31-weekly-meeting/46615/6 "2026-04-06T20:28:28Z")

</div>

yes, there should be a meeting tomorrow, but I’m doublebooked so I’ll join late if it’s still going on.

---

<div class="post-metadata">

**Author:** ![Sam\_Horvath](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/sam_horvath/32/3092_2.png) [@Sam\_Horvath](https://discourse.slicer.org/u/Sam_Horvath)\
**Post date:** [April 7, 2026, 2:43am UTC](https://discourse.slicer.org/t/2026-03-31-weekly-meeting/46615/7 "2026-04-07T02:43:10Z")

</div>

> [@2026.04.07 Weekly Meeting](https://discourse.slicer.org/t/2026-04-07-weekly-meeting/46673):
>
> 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](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