Interest to create Flatpak for 3D Slicer, have issue with GUISupportQtOpenGL not found

Thank you very much for the information. And it is a problem of modern software to have dependencies in so many projects, especially if there is a different version per linux distribution.

To be able to maintain it, I think I would have to be a direct participant of the project because now the Flatpak platform or at least the repository allows only to publish the packaged application for the authors of the original software.

Nevertheless, I think it would be an important step forward to continue with the task of transporting it to a framework such as flatpak to facilitate access to different users for this application.

1 Like

While having a stable flatpak makes sense, there is no point for preview versions, which change nightly. The other issue, is it even possible to install Slicer in a single read/only location (e.g., /usr/local/Slicer) and have the user files (extensions, pip packages) etc go in a local folder?

I would like to see this happening and I definitely could contribute to this. I’m not acquainted with Flatkpaks, but in general terms, there are two issues that complicate the integration of 3D Slicer with package systems:

  • One of the issues (as pointed out earlier in the thread and in the reference provided by @jamesobutler) is the superbuild approach, as many packaging systems require network isolation. In the SystoleOS project, we have the same issue and have been advancing on building 3D Slicer without the superbuild (so far, Slicer without python support is available). I hope for further advances during PW38.

  • Another issue is the divergence of some of the underlying dependencies from the official projects (most notably VTK, and to a minor degree, ITK). This makes difficult the co-existence of Slicer and other projects without some isolation mechanisms.

It may be possible to hack our way through (i.e., repo injection, etc) to make a Flatpack with the superbuild (@jcfr posted some snippets earlier in this thread). In my view, it would be better to invest some effort to make 3D Slicer possible to build without the superbuild as this will improve the overall quality of the 3D Slicer project and facilitate other packaging approaches beyond Flatpak and GNU/Linux systems.

There is not much progress since last time because Slicer relies on super build. I think when Slicer can build without network, it would be much easier to build and maintain Slicer flatpak.

Hi Andy,
I would like to be able to package Slicer inside with flatpak. Could you share the progress you made or comment on how far you got to go from there?
Thanks a lot

@Andythe_great, @luarpy we celebrated PW38 last week and we got good progress in the SystoleOS project. Most of this progress can be utilized for breaking the superbuild. I could support this initiative by transferring this and any future progress in the SystoleOS (and more, if needed).

@Andythe_great @RafaelPalomar where would you like to maintain the project progress and comunication?

I have been thinking about how we might approach this case. It seems to me that while we try to solve the superbuild issue in Slicer, which doesn’t work, we could adapt the configuration files and download the dependencies through several scripts launched from a main one.

This way we do not force changes in the original project files and make only the right changes for this particular case. The changes should be no more than indicating where the dependencies are located with respect to the packaging path.

Then we would only have to apply the packaging via flatpak and everything should be fine (I’m sure bugs will come up during the process).

I have created this repo and given @luarpy full access

As there are still some uncertainties related to the development and the maintenance of this project I think it is prudent to have it as a separate project. We can discuss with the Slicer core developers if at some point this could be integrated in the Slicer organization. @pieper, @lassoan, @jcfr, do you think this is a good plan?

I have quickly scanned the Flatpak documentation and found this info about bundled dependencies (Dependencies — Flatpak documentation):

As will be seen, bundled dependencies can be automatically 
downloaded as part of the build process. It is also possible 
to apply patches and perform other transformations.

Having bundled dependencies directly linked to the repositories used by the Slicer superbuild and the SystoleOS patches available in the SystoleOS/gentoo-overlay repository is one possibility. In the SystoleOS project we are trying to contribute all these patches to 3D Slicer, but some of them might take time and some others might not even be accepted.

Yesterday I was preparing some of the main files: manifest.yaml (also the one made by @Andythe_great), icon image and *.destkop file. All according to flatpak format. So I can do a push to start with something.

I also have a script I was preparing to automate the configuration process prior to packaging.

On the subject of what you indicate, I also read it but I did not understand how or what is meant by these libraries. I would have liked to find an example showing how to indicate the libraries to download.

1 Like

@luarpy, this is great.

Here is a ChatGPT-generated manifest bundling an ITK and a VTK. Does it look plausible? Keep in mind that we need to use Slicer/VTK and Slicer/ITK instead of vanilla ITK and VTK:

  "app-id": "",
  "runtime": "org.freedesktop.Platform",
  "runtime-version": "20.08",
  "sdk": "org.freedesktop.Sdk",
  "command": "app",
  "finish-args": [
  "modules": [
      "name": "ITK",
      "buildsystem": "simple",
      "build-commands": [
        "tar -xzf InsightToolkit-5.1.2.tar.gz",
        "cd InsightToolkit-5.1.2",
        "mkdir build",
        "cd build",
        "cmake ..",
        "make install DESTDIR=${FLATPAK_DEST}"
      "sources": [
          "type": "file",
          "path": "InsightToolkit-5.1.2.tar.gz"
      "name": "VTK",
      "buildsystem": "simple",
      "build-commands": [
        "tar -xzf VTK-10.3.1.tar.gz",
        "cd VTK-10.3.1",
        "mkdir build",
        "cd build",
        "cmake ..",
        "make install DESTDIR=${FLATPAK_DEST}"
      "sources": [
          "type": "file",
          "path": "VTK-10.3.1.tar.gz"

Getting this to work would be a good starting point. I hope we can rely on the stock Flatpak runtime system for everything below VTK. This is de dependency graph for Slicer on SystoleOS (no python support yet):

 * dependency graph for sci-medical/Slicer-9999
 `--  sci-medical/Slicer-9999
   `--  sci-medical/ctk-0.1.0  (sci-medical/ctk)   [python]
   `--  sci-libs/vtkAddon-0.1.0  (sci-libs/vtkAddon)   [python]
   `--  dev-qt/qtcore-5.15.8-r1  (dev-qt/qtcore) amd64
   `--  dev-qt/linguist-tools-5.15.8  (dev-qt/linguist-tools) amd64
   `--  dev-qt/qtmultimedia-5.15.8  (dev-qt/qtmultimedia) amd64  [widgets]
   `--  dev-qt/qtopengl-5.15.8  (dev-qt/qtopengl) amd64
   `--  dev-qt/qtsql-5.15.8  (dev-qt/qtsql) amd64
   `--  dev-qt/qtxmlpatterns-5.15.8  (dev-qt/qtxmlpatterns) amd64
   `--  dev-qt/qtx11extras-5.15.8  (dev-qt/qtx11extras) amd64
   `--  dev-qt/qtsvg-5.15.8  (dev-qt/qtsvg) amd64
   `--  dev-qt/qtwebengine-5.15.8_p20230112  (dev-qt/qtwebengine) amd64
   `--  dev-qt/qtwebchannel-5.15.8  (dev-qt/qtwebchannel) amd64
   `--  dev-qt/qtscript-5.15.8  (dev-qt/qtscript) amd64
   `--  dev-qt/designer-5.15.8  (dev-qt/designer) amd64
   `--  dev-libs/rapidjson-1.1.0-r3  (dev-libs/rapidjson) amd64
   `--  dev-libs/jsoncpp-1.9.5  (dev-libs/jsoncpp) amd64
   `--  dev-libs/qRestAPI-9999  (dev-libs/qRestAPI) ~amd64
   `--  sci-medical/CTKAppLauncherLib-1.0.0  (sci-medical/CTKAppLauncherLib) ~amd64
   `--  sci-medical/teem-1.12.0  (sci-medical/teem) ~amd64
   `--  Slicer-CLI/SlicerExecutionModel-1.0.0  (Slicer-CLI/SlicerExecutionModel)
   `--  sci-libs/itk-5.3.0  (sci-libs/itk)   [vtkglue deprecated]
   `--  sci-libs/vtk-9.1.0  (>=sci-libs/vtk-9.1.0)   [qt5 rendering gl2ps]
   `--  dev-util/cmake-3.24.3  (>=dev-util/cmake-3.23.1) amd64
   `--  dev-util/ninja-1.11.1-r2  (>=dev-util/ninja-1.8.2) amd64
   `--  dev-vcs/git-2.39.1  (>=dev-vcs/git- amd64  [curl]

It is the most unexpected answer possible hahahahahaha :rofl:. It seems to be fine but needs some changes. I wrote it in YAML because it allows to add comments to the document.

This is what I wrote based in the documentation of flatpak and using the Weasis Flatpak project as an example:

app-id: org.slicer.Slicer
runtime: org.freedesktop.Platform
runtime: '22.08'
sdk: org.freedesktop.Sdk
base-version: '22.08'
command: slicer
  # X11 + XShm access
  - --share=ipc
  - --socker=x11
  # Wayland access
  - --socket=wayland
  # Needs to talk to the network:
  - --share=network
  # Needs to save files locally
  - --filesystem=xdg-documents
  - --filesystem=xdg-download

  - name: VTK
    buildsystem: cmake
    builddir: true
    - -DVTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2=YES
    - -DVTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig=YES
    - -DVTK_MODULE_ENABLE_VTK_FiltersExtraction=YES
    - -DVTK_MODULE_ENABLE_VTK_FiltersFlowPaths=YES
    - -DVTK_MODULE_ENABLE_VTK_FiltersGeometry=YES
    - -DVTK_MODULE_ENABLE_VTK_FiltersParallel=YES
    - -DVTK_MODULE_ENABLE_VTK_ImagingMorphological=YES
    - -DVTK_MODULE_ENABLE_VTK_ImagingStatistics=YES
    - -DVTK_MODULE_ENABLE_VTK_ImagingStencil=YES
    - -DVTK_MODULE_ENABLE_VTK_InteractionImage=YES
    - -DVTK_MODULE_ENABLE_VTK_RenderingVolumeOpenGL2=YES
    - -DVTK_MODULE_ENABLE_VTK_TestingRendering=YES
      #- /bin
      - type: archive
        sha256: bc3eb9625b2b8dbfecb6052a2ab091fc91405de4333b0ec68f3323815154ed8a

  - name: CTK
    buildsystem: cmake
    builddir: true
      - -DCTK_QT_VERSION=5
      - -DCTK_ENABLE_PluginFramework=ON
      - -DCTK_ENABLE_Widgets=ON
      - type: git
        url: git://
        commit: ec9fcee532fd9cdff74f96479197f626d8c71fe5

  - name: CTK-PythonQt
    buildsystem: cmake
      - -DPythonQt_Wrap_QtAll=ON
      - type: git
        url: git://
        branch: patched-9
  - name: Slicer
    buildsystem: cmake
    builddir: true
      - -DSlicer_VTK_VERSION_MAJOR=9

      - mkdir -p build
      - cd build
      - cmake ../Slicer/Slicer
      - make
      - mv Slicer-build/* ../app/
      - install -D slicer.png /app/share/icons/hicolor/400x400/apps/org.slicer.Slicer.png
      - install -D -t /app/share/applications/ org.slicer.Slicer.desktop
      - type: file
        path: org.slicer.Slicer.desktop
      - type: file
        path: org.slicer.Slicer.png
      - type: git
        url: git://
        tag: main

A good mix of the two is a good start. Would you mind to make it a PR so I can give it a shot? As I see the problem now we can go a long way by translating the SystoleOS packages to this yaml representation.

UPDATE: Based on the discussion held on 2023.02.07 Weekly Meeting with the Slicer core devs, it seems reasonable to try approaching the Slicer flatpak under a superbuild approach rather than a non-superbuild as I initially proposed. Reasons: (1) some of the SystoleOS patches may take time to land on the Slicer code base, some might not even make it; (2) the distributed Slicer should be the same (or very similar) regardless of whether this is a flatpak or a redistributable linux binary, as of today this a superbuild-based.

@luarpy and @RafaelPalomar have started putting together a Flatpak manifest generator for Slicer (this is needed to set the right versions for the dependencies in the manifest) in here: GitHub - RafaelPalomar/Slicer-Flatpak: Flatpak for 3D Slicer. The final manifest will go on its own repository (so far, GitHub - RafaelPalomar/org.slicer.Slicer: Flatpak repository for Slicer). It is still a non-usable work-in-progress, where we try to reproduce the suggestions above by @jcfr.

It is great to see all the progress with the build. I can help with runtime questions. More specifically: what folders can be read-only and what temporary and persistent writable folders we need for application settings, extensions, Python packages, DICOM database, cached downloads, etc.

This is great @lassoan, thank you. For sure we will need help to deal with the runtime configuration. We’ll keep updating on the progress of this.

1 Like

I leave two interesting pieces of information I found recently:

  1. I don’t think it would affect this development, but Ubuntu is planning to drop Flatpak integration by default (users will still be able to install the support manually as it is for many other distributions). More information on this post:
  1. Also found an interesting FOSDEM 2023 talk about Flatpaks, Snaps and AppImages from an OpenSUSE developer:

What’s the TL;DW for this?

From worse to better:

  1. AppImages: “fail in everything they set out to do” → Don’t use them.
  • Linux apps running everywhere → They don’t
  • Easy to install apps as in Windows or Mac → They are not.
  • Provide applications without the need to ‘get into a distribution’ or ‘build for a different distributions’ → Practically, you need to learn every distro and build one.
  1. Snaps → Practically confined to Canonical ecosystems.
  • Still very limited to Ubuntu ecosystem (won’t deliver confinement in most Linux distributions).

  • Very dependent of Canonical. There is a pricing model for serious delivery of apps and there is no open-source delivery option (open format, but not open delivery).

  1. Flatpak → The only option ready for primetime
  • Reasonable isolation model. The client is easy to integrate in any Linux distribution

  • Translates licensing and dependencies freedom and responsibility to the packagers

1 Like