Hello, this code from the script repository creates a slice view widget in a separate window:
Then I selected a background volume in this new view and went to the segment editor module, but couldn’t use the effects (for the Paint effect for example, the brush cursor does not appear over this new slice view). What is missing to make it work?
Thank you.
The Segment Editor gets the list of views from the layout manager. Any additional views are ignored.
To change this, you would first need to create a method in the Segment Editor widget that provides a list of views (this method could use the layout manager by default but could take some extra custom view nodes). Then you would need to update the widget (and a couple of effects that needs a view list) to use this method instead of asking the list of views from the layout manager.
Thanks for your response, @lassoan.
But from what I’ve read on the qMRMLSegmentEditorWidget code, it uses the layout manager, as you described, to list the slice view names as in here.
If I use the layout manager to list the sliceview names, I get my custom slicewidget listed on the python console:
slicer.app.layoutManager().sliceViewNames()
(‘TestSlice1’, ‘Red’, ‘Yellow’, ‘Green’)
The first one is not considered somehow by the cpp code?
The segmentation is displayed on the custom slicewidget just fine, the effects are not.
Also, I’ve noticed another issue with the adjust window/level tool, the functionality works but the mouse pointer does not change when using it at the custom slicewidget.
You are right, the layout manager returns all view names, not just those that it owns, so that should not prevent segmentation interactions. It seems that the render window interactor that the Segment Editor widget adds observers to, is not the one that actually receives the events. I did a little debugging but it was not obvious what is the root cause of this.
Any near future investigations on this issue, or thoughts on how we could bypass this problem? Sorry for asking this, but it is something we really need in an important module that we are developing.
Thanks again Andras,
Giovanni
Can you explain how you are using this extra slice viewer and why you decided to create a new one instead of using an existing layout view?
Hi James, the user of our module can add slice views via interface (as many as he wants, with interface space limitations, of course), to compare many similar volumes side by side.
This module also allows segmentation (the user has to select the “active” volume that he wants to segment, and we set up the necessary segmentation node and master volume on the Segment Editor widget that is embeded in our module).
I see. So you are trying to implement arbitrary screen layout grids · Issue #2384 · Slicer/Slicer · GitHub regarding the ability to set up a dynamic layout view based on user selections. Where the user can define their own custom layout of viewers rather than picking from a predefined list.
Could you instead define a certain number of slice viewers to define a hard constraint? You would register specific layouts of slice viewers instead of trying to dynamically create new ones. I suggest this based on the uncharted territory of manually creating slice views and having all the functionality of segment editor and cursor icon and stuff work appropriately. Creating new slice views has probably only been supported in a basic sense of viewing volume nodes, but not much more.
I agree. Generating the XML view descriptions on-the-fly is simpler to implement and maintain and more robust than adding views outside the view layout.
If you want to go with creating views outside the view layout then you need to debug the view creation and figure out why the mouse event observations are added to the wrong render window interactor object.
Here is how you can define a new layout and register it as a layout to choose.
https://slicer.readthedocs.io/en/latest/developer_guide/script_repository.html#customize-view-layout
Hello, sorry for the delayed response. I managed to develop what we needed using layouts, but in the end it is still much more convenient (for this case) to be able to play around with the slice widgets freely, as if they were just another widget.
I think that maybe the example in the script repository, referenced in the beginning of this topic, should have a warning about the lack of segmentation interaction with these custom slice views, to save some time if anyone starts to develop something with them and end up in a dead end like I did.
Thanks for your time to help solve this issue.
Giovanni
One thing that I forgot to mention. Disabling these interactor style actions for a slice view, renders the Data Probe inoperative (not displaying the intensities when the mouse is over the slice view).
sliceViewInteractorStyle = sliceWidget.sliceView().sliceViewInteractorStyle()
sliceViewInteractorStyle.SetActionEnabled(sliceViewInteractorStyle.Translate, False)
sliceViewInteractorStyle.SetActionEnabled(sliceViewInteractorStyle.Zoom, False)
sliceViewInteractorStyle.SetActionEnabled(sliceViewInteractorStyle.Rotate, False)
We need to not allow the user to do these actions (the view is configured automatically).
This has been fixed quite long time ago (several months, maybe a year ago).
We are using the Slicer from 2021-09-13
Try this code in recent official Slicer release and let us know if you don’t see the Data Probe updating:
sliceViewInteractorStyle = slicer.app.layoutManager().sliceWidget("Red").sliceView().sliceViewInteractorStyle()
sliceViewInteractorStyle.SetActionEnabled(sliceViewInteractorStyle.Translate, False)
sliceViewInteractorStyle.SetActionEnabled(sliceViewInteractorStyle.Zoom, False)
sliceViewInteractorStyle.SetActionEnabled(sliceViewInteractorStyle.Rotate, False)
Uh oh. I was very mistaken about the version we used. The date is from a compiled version of ours, not from the Slicer released date. The Slicer used was from 30/09/2020 revision 29402, exactly a year ago.
I tested your sample code in both the Latest Stable Release (revision 29738) and Latest Preview Release (revision 30272).
The bug is present on the Latest Stable and is fixed in the Latest Preview. We will update our compiled version, since the problem is fixed. Thanks Andras.