Pushed new branch T27243-FixAutoloadDependency.

Pushed new branch T27245-DoxygenExtensionPoint.

Was removed meanwhile and revealed errors regarding plugins that depend on autoload modules.

Pushed new branch T27242-FixPackaging.

The recommended way of using QtOverload seems to be via macros in C++14 (our minimum C++ standard). There are also macros for const overloads and explicitly non-const overloads:
https://doc.qt.io/qt-5/qtglobal.html#qOverload

+1

In T27206#196190, @kalali wrote:

Also, concerning the super ugly version, I did this sometimes (although I'd prefer the QtOverload-way):

connect(mySpinBox, static_cast<void (QSpinBox::*)(int)>(&QSpinBox::valueChanged), mySlider, &QSlider::setValue);

In T27206#196185, @floca wrote:

That's a bit extrem. I wouldn't call the following statement super multiline or verbose:

connect(mySpinBox,  QtOverload<int>::of(&QSpinBox::valueChanged), this, &MyClass::OnChange);

Note that this is an alternative syntax, not a successor. For example, you can't use the new syntax for overloaded signals like valueChanged(int/double) of QSpinBox, or to be precise, it is possible but super ugly, verbose and multi-line. So I wouldn't recommend to systematically change everything to the modern C++ syntax but I think it is worth it to take lambdas into account which could result in the removal of quite some short slots that otherwiese are boilerplate with there declaration and definition compared to a single-line lambda.

Pushed new branch T27203-FixQmitkAbstractNodeSelectionTestOnHeadlessLinux.

This seems to break packaging on macOS. I merged into the master anyway as I will now to continue to completely rewrite our packaging.

Agree, but I also recommend to disable the auto-formatting in VS2019, as we had quite some inconsistencies in the past with it. When we agreed on a final clang-format, we should apply it to the whole code base (master) and after that look into reenabling the feature in VS2019.

Please do set the priority when creating an MITK task.

Set MITK_WHITELIST in build configuration so the configuration in the example above is now easier/shorter. You don't have to set the MITK_WHITELIST anymore, only the MITK_BUILD_CONFIGURATION.

The packaging does actually work contrary to what I wrote above, as I missed the .sh scripts that are necessary to start the actual executables. However, it does NOT copy the autoload services which is possibly the last TODO in this task.

I added all the DICOM-related IO services to the whitelist and renamed the build configuration/whitelist from MinimalCmdApps to CoreCmdApps. I adapt the example above to reflect the changes.

So adding a DICOM SEG to a directory already containing other DICOM files makes MITK unable to load the original DICOM files anymore.

Is it still a non-trivial thing? I thought we already have the possibility to handle DICOM references? I may miss the point here but when loading a DICOM image with a reference ID or whatever it is called and if this referenced image is present in the current scene, it should be taken into account, right?

Pushed new branch T27172-UpdateSupportedPlatforms.

The example above shows how to build MitkFileConverter in about 15 minutes. It uses Ninja as build system so do a sudo apt install ninja-build first. I also built the package target afterwards and it succeeded to package everything in a relocatable tarball, however, when executing the packaged MitkFileConverter, dependencies of MitkCommandline were missing. So this is something we have to investigate.

Pushed new branch T27170-MinimalBuild.

Pushed new branch T27168-DefaultRangeForSliceAndTimeAnimations.

Pushed new branch T25745-DontBuildGDCMManPages.