[FR] Default UndoManager arguments to nullptr in all ValueTree methods

Feature Requests
1

When you need undoable actions, being able to simply provide a ValueTree with an UndoManager makes it incredibly simple. However, when you don’t need undoable actions it makes the code look a mess to have to pass nullptr in every method of a ValueTree.

Could the arguments simply all be defaulted to nullptr?

In addition, could we have a ValueTree use a “global” UndoManager since in 99% of cases you’d only use the one undo manager so it’s unnecessary to constantly pass it into every call.

So instead of explicitly passing an UndoManager to every method when I want it to be undoable, I could just call tree.setUndoManager(&myUndoManager); and all the methods will use that one, unless specified?

juce::ValueTree tree{ "Tree" };
tree.setProperty("value", 12); // Can't be undone

juce::UndoManager undoManager;
tree.setUndoManager(&undoManager);
tree.setProperty("value", 14); // Can be undone by undoManager

juce::UndoManager anotherUndoer;
tree.setProperty("value", 37, &anotherUndoer); // Can only be undone by anotherUndoer
7 Likes
2

100% agree – very annoying – rarely use the undo

1 Like
3

I do use the undoManager about 60-70% of the time, so I agree with both suggestions; default to nullptr, and use the setter to establish the undoManager for all.

1 Like
4

I agree. Implementation wise you could have the class own a undomanager pointer, which by default would be nullptr. Have this pointer be the default argument and a setter to map this pointer to an instance of an undomanager. Should be a non-breaking change?

1 Like
5

+1, this is a perfect case for default parameters. Is there any downside? Seems like a no-brainer to me.

2 Likes
6
3 Likes
7

Still, if you have an undo manager to pass in, is very tedious. Better to move mutations to a subobject:

auto x = juce::ValueTree()
    .withChanges(undoManager)
        .setProperty("a", 1)
        .addChild(...