As you might remember, Krita has a cumulative undo feature, which allows Krita to merge multiple brush strokes into a single undo step. It has never been popular, partially because it was really difficult to understand (and crashy ). I have just rewritten this feature to resolve the crashes and make it a bit more user friendly.
So it would be really helpful if you could test it and give your feedback!
The feature is hidden in under the button in “Undo History” docker:
The patch changes semantics of the feature a little bit. Now Krita starts to merge the strokes into a group either when the strokes become older than “Keep unmerged (time)” or when there are more than “Keep unmerged (actions)” unmerged strokes in the queue (whatever happens first).
For example, if you have “Keep unmerged (time)” set to 5 seconds, then all strokes older than 5 seconds will become merged. And if you have “Keep unmerged (actions)” set to 5, then last 5 strokes will be kept unmerged (unless they are merged using the time-based timeout).
The merge-groups are defined by “stroke-separation”. By default, if two strokes were made one after another with the delay smaller than 1 second, they will be considered a group and merged when the conditions trigger.
I would really like you to test the updated feature and it would be very nice to hear your feedback
Here are the things I’m not sure about:
Questions:
Is explanation in the configuration dialog understandable?
Do the tooltips in the dialog look okay and understandable?
Are the default values (5 sec, 5 actions, 1 second) okay or should be changed? I have a feeling, like “Keep unmerged (time)” should be increased to something like 30 seconds, though I’m not sure.
Is it okay that time- and history-length- based limits have the same priority? Perhaps, “Keep unmerged (actions)” should have a priority and Krita should keep a specific amount of actions unmerged whatever their age is? What do you think?
Should I rename “Keep unmerged (actions)” into “Keep unmerged (states)”? Which one is better?
Testing needed:
Test how merging works. Does it behave in an expected way?
Try changing options, especially in “curious” ways, when, e.g. unmerged actions limit is equal to undo limit
Try to use undo/redo, check if it works correctly. Especially the case, when you undo a couple of actions and start to paint right in this state (which discards the undone states)
Test “clean state” functionality:
Paint something on the canvas
Save the document: the document state is set into “clean” (no asterisk sign near the document name in the windows title)
Do some strokes until all states before the saved state are merged into the saved state. The document becomes “dirty” (the asterisk appears).
Switch to the “clean” undo state, which has “merged” suffix now. The document should become clean again.
Switch back to the latest state: the document is “dirty” again.
Do one stroke to ensure that a state after the clean state is merged into that (clean) state.
Now switching into this “clean” state does not make the document “clean” anymore, because the state contains unsaved changes.
I mostly remember the hot topic about visibility layer
Are these change pre-requisite to review the visibility layer undo/redo stack being taken in account through an option?
Looking the options provided for cumulative undo:
Not sure to have it hidden here is good thing
Is it possible to have it in krita main settings window, in a dedicated “Undo” tab, also taking in account the undo stack size?
I’m sorry for the startup issue, I forgot to include the asan library to the package. I have fixed that and reuploaded the package (the new one has suffix -dk2).
I have also uploaded the Linux Appimage package.
@Grum999, from the brief look your naming idea looks good. I will check in detail on Monday
I did a little bit of testing and it seemed to work from what I could tell, except for an issue with the modified/clean state. When undoing back to a save on the ‘(empty)’ state or other non-brushstroke command, it kept the document as modified, with the command before it being the one marked as unmodified in the latter case. I’m not sure if it’s only in certain circumstances or not.
When undoing back to a save on the ‘(empty)’ state or other non-brushstroke command, it kept the document as modified, with the command before it being the one marked as unmodified in the latter case. I’m not sure if it’s only in certain circumstances or not.
I’m not sure I can fully understand you explanation. I tried the following steps and they seem to work correctly:
Do a few brush strokes
Do a transformation with the Transform Tool
Save the document (document becomes “clean”)
Do a few more brush strokes (document becomes “dirty”)
Click on the “Transformation” undo state → the document becomes “clean” again.
“Exclude strokes from merge” now has full priority over the time-based merging. That is, this number of strokes will never be merged, however old they are.
A new option “Max group duration” was added. Now the groups cannot be infinite as before (that was a common complaint about the feature). The groups are limited by their duration (in seconds).
There are a few typoes in the help text: acoording → according excuded → excluded fomed → formed
I tried compiling it myself, and there were a few missing includes: kundo2stack.cpp and KisCumulativeUndoData.cpp were missing kis_debug.h KisCumulativeUndoModel.h was missing qobject.h
I find that moving the settings to the main preferences dialog makes it more work to get to if I’m trying to tweak the values. The undo stack size is something that won’t be changed often, but the cumulative undo settings are something users might play around with to find what works for them, or perhaps turn on or off depending on what they’re working on.
That said, I don’t have a particularly strong opinion on it. Maybe putting it in Preferences makes it easier to find for people who don’t use the Undo History docker, for instance.
Thank you for the feedback! I have pushed a fix to the issues you reported. It should work now
About the settings dialog: in the undo docker the option is completely undiscoverable. So, if we decide to put the configuration button into the dialog, it should be a copy of the functionality from the Preferences dialog.
I’m sorry, the previous package for Linux contained a wrong version of Krita (the first version of the cumulative undo, not the latest one). I have rebuilt it and now it has the latest version for sure!
@dkazakov Hey, I tested the appimage (the latest), I painted for an hour with it after activating Cumulative Undo (with the default settings).
Everything went fine, no bug, no lag, just painting. It’s really interesting how Krita can rewind like almost 20min of paintings with the default 99 undo. Here under a sketch I rewind totally and fast-forward with redo. Many steps were compressed together, it’s perfect.
The feature has been merged into krita-master. It should become available in tomorrow’s nightlies!
Before the merge I also implemented a small feature, now the strokes are not merged if they are painted with different brushes, colors , opacities or blending modes. They are also kept separate if applied to different layers
). I have just rewritten this feature to resolve the crashes and make it a bit more user friendly.
