• MatchPoint algorithms are not detected on macOS, even though the search path is correct. Works on Windows and Linux.

Replaced install() in CMake/mitkFunctionCreateMatchPointDeployedAlgorithm.cmake with MITK_INSTALL() macro as the algorithms were deployed to the wrong destination on macOS.

In T23343#116298, @floca wrote:

I would have (minor) concerns with directly merging it. The comments raised for the last commit.

Pushed new branch T25191-v2018.04-beta.

Pushed new branch T24727-FixMacOSInstaller.

Pushed new branch T25183-FixRemainingInstallIssues.

I have written a script that fixes the issue mentioned above and the installed MitkWorkbench does work now!! We have to decide how we handle this situation. Personally I'm pretty sick of all this macOS quirks for now and would vote for modifying the script so that it can be run from our install script at the right place.

Yes, that's definitely an issue. However, even fixing QtWebEngineProcess wouldn't be enough as each and every Qt framework contains these paths relative to @executable_path. We should go for @rpath.

Uh, maybe the path @executable_path/../Frameworks/QtWebEngineCore.framework/Versions/5/QtWebEngineCore isn't correct because it should (?) be relative to QtWebEngineProcess instead of MitkWorkbench.

Not sure if this is somthing we should fix befor the now release?

Okay, I think I got a step further. I added the USE_SOURCE_PERMISSIONS parameter to the MITK_INSTALL() macro for the QtWebEngineCore.framework/Helpers directory. The QtWebEngineProcess application, located in a subdirectory, is now recognized as executable by fixup_bundle() and fixed up. Still, using the method above there is the following message although the QtWebEngineCore file is at the correct location:

Pushed new branch T24628-dcm-toolkit-update.

In T25042#160695, @floca wrote:

What should happen now, assuming that the second image has a higher layer and is visible? Currently the topmost node that will be retrieved will be the second image (Heart). Is this correct, since time step 3 lies between 0 and 103 ms? If so, then why do we experience a workbench crash?

Because your are still thinking in time steps (of the world time geometry) instead if thinking in time points and asking what would be the appropriate time step of this image (in its time geometry of the image) at the given time point.
So correct would be:

auto globalStep = render->GetTimeStep(); //[globalStep == 3];
auto globalTimePoint = worldTimeGeometry()->TimeStepToTimePoint(globalStep ); //[globalTimePoint == 3]
auto currentStep = image->GetTimeGeometry()->TimePointToTimeStep(globalTimePoint ); //[currentStep == 0]

Now we use currentStep (0) and tada no crash and the correct volume associated with the global time point.

Yes, I meant time point. So using the time stepper and setting it to step 3 we'll get the time point 3. This time point lies between 0 and 103 of the second image so we "round" to the next smaller time step (in TimePointToTimeStep with if (timePoint < *pos)), which will give us time point 0 => time step 0.

In T25042#160682, @kalali wrote:

I'm currently trying to understand the problem to possibly fix the bug together with the T24173.
I loaded two datasets:

• LinearModel_4D_arbitrary_time_geometry.nrrd from MITK-Data\3D+t-ITKIO-TestData and
• the image from MITK-Data\3D+t-Heart

This should be fixed in conjunction with T25042: How to handle update informations in heterogeneous time geometries and out of bound situations and T24767: Workbench crashes when loading two 3D+t images with different number of time steps, because an unfixed UpdateStatusBar in the DisplayInteractor could also cause crashes like in T24767.

Pushed new branch T24472-PythonViews5.

We have discussed it.

We have discussed that task. It was agreed that the statusbar is not the right place to put this information. It was also agreed that the feature (showing the value of the current position) should not be skipped and is used in many applications.

Pushed new branch T24472-PythonViews4.

Pushed new branch T24472-PathonViews3.

Pushed new branch T24472-PythonViews2.

Pushed new branch T25052-Wrong_COUT_in_DICOM_reader.

Pushed new branch T24472-CatchPythonErrors.

Pushed new branch T24472-DiffPython.

And another thing: update requires clean builds of DCMQI and DCMTK, so continuous clients will probably fail

Ok, I updated my fork to use the latest DCMQI with our modifications as well as a new jsoncpp version which solves the compilation issues. As a side effect, we have to update DCMTK, but I think it should be worth it before the release.

The accute problem is fixed. But the LevelWindow and widget need some treat and refactoring (see also T24962).

Also merged fixed for T24886: MITK workbench freezes due to infinite loop in QmitkSliderLevelWindowWidget::paintEvent

Pushed new branch T24942-MatchPoint_mapping_must_currect_origin.

Pushed new branch T24968-MakeQt5.10.1MinimumRequiredVersion.

We found out that volume visualization works as expected when following the described steps:

• Close rendering display
• Open MITK-Data/3D+t-Heart (rendering display is opened automatically)
• Switch on volume visualization
• No crash :)

Should be fixed in the alpha branch now.

Pushed new branch T24957-MitkDICOMReaderServices.

I have seen the fixes deactivating QNetwork in 1881c497af3e4b810d131a2c05bb819e485bf4e7 . However this also removed the
-n option command line option to disable networking. This option is used by the plugin generator tests. I could remove it there, but @kislinsk I think we should discuss the general strategy.

This is a follow-up error when Doxygen wasn't found for building the documentation. Without doxygen, the BLUEBERRY_USE_QT_HELP is disabled. So everything's fine.

Just tested the branch T24609-v2018.04-alpha with Ubuntu 18.04 / Qt 5.9.5 / gcc 7.3.0 and it compiles without errors in default configuration. I can also start the workbench.

I did an export DYLD_PRINT_LIBRARIES=1 and started both the installed version and the built version of MITK and this is suspicious:

I talked to @metzger. Apparently we use a fork of DCMQI by @nolden. So we can go the fast way for now and patch it there. Even without coding it should be possible to hand in the patch above via the web UI and it probably can be merged by a click on a button in the web UI, too.

The problem was that I didn't reset the _install_DESTINATION variable at the end of mitkInstallRules.cmake and hence following calls to the macro assumed the last set destination as default destination. In this case, the provisioning files was installed into Frameworks/QtWebEngineCore.framework instead of the Contents/MacOS directory.

Wow, seems like most of the issues is resolved by manually copying the MitkWorkbench.provisioning.install file to the installer directory as MitkWorkbench.provisioning. We must check why this file isn't installed anymore (macOS-specific? CMake 3.11?).