Ignore or remove a Segment Editor undo state

Support
1

If I have a workflow like the following:

Load CT and create a Segmentation
Use Paint effect on red slice
Use Paint effect on green slice
Set a tag on the first segment of the segmentation node
Use Paint effect on yellow slice

In the application I’m working with, the “tag set” operation is done in the background and the user is not aware of it. I’d like for that “tag set” operation to not count as a state that can be undone. For example, if the user were to click the segment editor undo button three times, the three Paint effect changes would be undone. As opposed to the current functionality which would undo two of the three paint effect changes and the “tag set” change.

I’ve tried to do this by:

  1. Temporarily turning off undo/redo for the segment editor, setting the segment tag, and re-enabling undo/redo. Doing this with qMRMLSegmentEditorWidget::setUndoEnabled clears the undo history. It seems like undo/redo at the scene level has this type of functionality via vtkMRMLScene::SetUndoOff and vtkMRMLScene::SetUndoOn but I haven’t found anything similar for the segment editor.
  2. Removing the last undo state from the stack, but I haven’t found where that’s exposed in the API.

Am I missing a way to accomplish this behavior?

2

I have also wanted in the past an alike feature for a project, my use-case was to compress 2 or more segmentation modifications into only one undo/redo step on the segmentation history chain

3

I also bumped into this problem, especially the second one.

My opinion is that it would be quite simple to enable such non-standard operations, by opening the API of the SegmentationHistory, but it is hidden behind Pimpl classes.

@lassoan what do you think? Could we expose a few methods in the segment editor widget about the undo history?

4

Probably the best would be to implement a bool BlockSaveState(bool) method in vtkSegmentationHistory (similar to blockSignals method in Qt), which could temporarily block all undo save requests. It would be probably quite simple to implement and the operation would be faster and use less memory than implementing methods to delete (merge) undo states.