Requested code changes in pull request.

Merged into releases/2018-04.

Pushed new branch T26655-GizmoFix.

Not yet working. Tree doesn't collapse only the first time.

In T26451#186376, @jsolislemus wrote:

Apologies, but I am not sure I understand your first questions, but given your last statement:

No problem. A now fixed typo made it hard to understand.

Yes, unfortunately the current solution only works for first level.

I experienced a problem with that approach:
I have an image with many segmentation nodes as child nodes. If I want to hide all segmentation nodes except for one (using "show only selected node") it does not hide all other segmentation nodes because they are not on the first level.

I'm currently using this inside the semantic relations plugin and I'm thinking about moving the functionality to the data manager context menu or similar.

• creating a new segmentation via the segmentation view

Has been disabled for the BlackSwan Demo. A "re-initialize selected nodes" button has been added, which will reinitialize the geometry of both selected nodes only inside the currently active render window.

This is also necessary if a context menu action is defined within another plugin, which uses additional module-dependencies.

Pushed new branch T26588-cleanup.

Pushed new branch T26629-HandleIGTIOExceptionWhenSavingToolStorage.

Will be solved if D214 is accepted and merged.

Pushed new branch T24766-Fix-last-time-step-access.

Looks like one solution to the problem. For the other tracking devices, however it seems to be solved by adding the line

@eisenman @seitela Fixed this bug. Can i go ahead and merge it?

Pushed new branch T26611-EditToolTip_in_IGT-TrackingToolBox_not_working.

Pushed new branch T26658-Transducers.

Apologies for the delay in response..

Pushed new branch T26657-fix-picker-spacing.

Another idea would be to use our QmitkSelectionServiceConnector to connect the service bus with a slot of the level window manager / level window widget, such that each selection is noticed by the level window slider and the context menu can access the currently selected data nodes.
I looked into the implementation and I think this is something we can do, given the code that we have.
However, I support the idea of rethinking and redesigning the level window manager (resp. level window widget). There are a lot of conditions and checks which make the class complex and error-prone.

Pushed new branch T25804-Level-window-manager-as-selection-service-listener.

See E130-Projekte\MITK-Docs\MITK Schulung\2017 - MICCAI\DICOM_SEG_Gitbook

see T25483: different approach though: The idea is to change the level window slider while the "selected nodes" mode is enabled. This way, the level window will be applied to to all selected data nodes automatically and simultaneously.
The approach proposed here sounds more like using a node which has already a set LW and "propagating" this LW to different nodes (subsequently). I linked this task as we could discuss if this is something we want to have this feature additionally.

Speculating:
Maybe that was a bash environment side effect, i cannot reproduce this error on my GNU/Linux system where I use tcsh instead of bash.
The tcsh environment does not contain anything "conda" related, while bash does, if (ana|mini)conda is installed.

There are several things to point out here:

• We could split the class into a real mouse mode switcher that only changes the mouse mode .xml-config file for a new mouse mode.

A new class has been introduced that handles all basic MITK- and PACS- interaction .xml-files in T24357.

Has been solved on top of T26476.
This task will be closed if everything is merged to master and tested (wait for D212).

Pushed new branch T24357-Remove-MouseModeSwitcher.

A new class, the InteractionSchemeSwitcher has already been introduced in 9ab09bff137b. This class is used as a replacement for the MouseModeSwitcher. It it a simplified and cleaned version which reduces the responsibilities of the class: The service registration has been removed and is now done inside QmitkAbstractMultiWidget and DisplayActionEventBroadcast.
Additionally, the scheme switcher is adjusted to match the new scheme config files (see T24368): There is no difference anymore between a mouse mode and an interaction scheme (see T24368).
The new scheme switcher is used within the QmitkInteractionScheme and is currently tested with the QmitkAbstractMultiWidget.

Has been solved on top of T26476.
This task will be closed if everything is merged to master and tested (wait for D212).

Pushed new branch T24358-Remove-QmitkMouseModeSwitcher.

A new class, the QmitkInteractionSchemeToolBar has already been introduced in 9ab09bff137b. This class is used as a replacement for the QmitkMouseModeSwitcher. It it a simplified version which does not observe the mouse mode switcher / interaction scheme switcher. There is no observer tag and no block-functionality.
Additionally, the tool bar is adjusted to match the new InteractionSchemeSwitcher (see T24357): There is no difference anymore between a mouse mode and an interaction scheme (see T24368).
The new toolbar is used for the mxnmulwiwidgeteditor and is currently tested with the stdmultiwidgeteditor (see 732f754ad203).

Has been solved on top of T26476.

Pushed new branch T24368-Adjust-display-config-files.

I decided to go for having an own complete .xml-file for each mode, so I added the full definition for the different PACS modes.
The reason is that we want to have a consistent interaction scheme-handling which means either having full definition for both MITK and PACS modes or having base- and additional definition (like the original PACS modes). But changing the MITK configuration files to the base- and extra-mode variant requires event_variants to be empty in order to disable certain mouse events. Additionally any implementation needs to do two calls, one for setting the base-mode and one for adding the extra mode to make sure the correct base-mode is always set (e.g. switching from MITK to PACS). This was undesirable.

encryption works as expected

I'm not sure if this is a valid issue.
I can reproduce the observable result if I don't disable the segmentation tool. I'm still in the drawing mode if the segmentation tool is enabled. If I change the display interaction mode now (by enabling Crosshair rotation (or any other mode - also No crosshair rotation), the MITK interaction scheme is enabled and both interactions happen at the same time (navigating and drawing).
Disabling and re-enabling the tool will again overwrite the navigation interaction and allow to draw the segmentation without any problems.

I can not reproduce this.
After having deselected the Region Growing tool, I can use the left mouse button and move the mouse to scroll through the slices. "Normal" scrolling (does this mean scrolling using the mouse wheel?) does not work. Notice that you can always scroll by pressing the middle mouse and moving the mouse (regardless of the selected PACS mode).
However, in T26486 I changed the PACS mode such that you can always scroll through the slices using the mouse wheel (regardless of the selected PACS mode). The special PACS scroll mode still works for fast scrolling (left mouse button and mouse moving).

Has been solved on top of T26476.

Pushed new branch T24635-Prevent-infinite-scroll-loop.

Pushed new branch T26486-PACS-mouse-mode-with-mouse-wheel-scrolling.

Pushed new branch T26642-Restore-original-interactions.

Combine with T24356 (esp. T24368).

OK. But we definetly should talk about it before it is approached.

1. encoding File/Blob object to ArrayBuffer (needed as input for AES encryption) crashes browser (tested on Chrome) if file is bigger 1GB:
   • check chunking