Our application has a fixed segmentation workflow comprised of several segmentation steps. Each step may create 1 or more segments, select it and execute 1 or more segmentEditorEffects.
The problem with the current undo/redo functionality is that it cannot save the selected segment history along with the segmentation state after the user executes a segmentation step. Also the segmentationHistory does not save the applied effect name.
I would like to access some how this information so I can set up my custom undo/redo logic according to our segmentation steps so it is easy to navigate for the user.
Maybe accessing this signals would be useful:
But the segmentEditorWidget.SegmentsTableView should be public I think.
Any ideas of how to solve this? Would Slicer core need to be updated for this use case? What would be the best way to do it?
If the default segmentation states that are saved are ideal for your workflow then you can disable undo/redo in the segment editor and instantiate your own
vtkSegmentationHistory class and save and restore states whenever you see fit.
An optional “description” input argument could be added to vtkSegmentationHistory::SaveState(). Effects could put in that description what they are about to do, such as “Erode by 3mm”. That description could be shown in the undo/redo button tooltip. Pull request is welcome (i.e., you implement it and Slicer developers review and integrate).
The currently selected segment is available in the segment editor node. You can observe that node if you want to get notified about selection change.
I was able to bypass the problem by using the info here: Observe modified segment - #2 by lassoan to create a log of executed effects (I could do that because we have segmentation steps that execute sequentially fixed segmentEditor effects or allow user-interactions like paint effect)
And we decided to only give support to undo/redo the paint steps of our workflow.
However, there is a bug on the segment editor that breaks our custom undo/redo logic.
Thanks for reporting the issue, indeed some of the saved undo states were indeed unnecessary - requiring users to do extra undo/redo clicks. The problem is now fixed.