No-3D-rendering problem can also be forced via the render-menu "show crosshair" command.

Not only an OS X problem. Clearly not a feature if the option is named "Show only selected node". A programmers can understand that the crosshair is in fact 3 nodes but a user shouldn't have to.

Here's a PR that might (or not) solve your problem: https://github.com/MITK/MITK/pull/194

I am hesitant to integrate this pull request. I can understand the concern regarding invisible planes and agree that that should be solved. However just making all helper objects visible by default overshoots that target in my opinion.

On the assumption that you have a workflow requiring a lot of nodes in the datamanager (otherwise you do not really need "show only selected nodes"), it is very conceivable that the same workflow requires multiple helper nodes visible in the 4 window view (such as pointsets, planarfigures or even temporary segmentations) for a variety of different steps.

Leaving these in with the only node to be shown would result in a cluttered, incoherent scene where simplicity was desired.

Adding another property (like "always visible" or somesuch) strikes me as inelegant as well.

I am open to suggestions solving both of these problems.

I can't say I have the solution to that problem, but here's anyway what I would do:

• Never modify node without BaseData.
• If "Show helper objects" is checked: hide them too
• otherwise, don't.

Or simply add a new preference asking of they want to hide helper objects too?

I don't think there's a perfect solution, but I think this might displease less people :)

In T19683#100896, @goyette wrote:

• Never modify node without BaseData.

This should already solve the issue under discussion. That way we would avoid the whole helper object logic.

+1

Pushed new branch T19683-ShowOnlySelectedNodesCrosshairVisibility.

Would be good to leave the baseRenderer as an argument so that you can set the visibility of a specific node in a predefined base renderer (e.g. by using the RenderWindowManager). This is useful when using the new MultiWidget(Editor).

Pushed new branch T19683-ShowOnlySelectedNodesCrosshairVisibilty-baseRenderer.

Why are there now 2 actions? Did we miss some side effects with the base renderer?

Which 2 actions?

QmitkDataNodeShowSelectedNodesAction.cpp and QmitkDataNodeShowSelectedNodesAction2.cpp in Plugins/org.mitk.gui.qt.application/src/

Through merge conflicts.. The baserenderer argument was added in the master.

Pushed new branch T19683-ShowOnlySelectedNodesCrosshairVisibility-RandomAccess.

Could you elaborate on this? I don't get it: aren't we processing each single data node inside the data storage?

If you ask for all the nodes from data storage then you get also child nodes in random order. In the previous implementation, visibility of all child nodes of widgets are set to True when the widgets node is reached. Nonetheless, child nodes visibility were afterwards set to False in the outer loop.
Now the loop is only done on nodes in the first level that contain data, therefore crosshair nodes stay always visible.

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.

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

Pushed new branch T19683-ShowOnlySelectedNodesSecondLevel.

Is this solved?