Undo and CTRL+Z Absolutely Must Be Granular for Every Action

This is still currently an issue in version 29.11.29

I believe this is on the roadmap, and there might be other posts about it, but I’ll reiterate. I hope it’s fairly high on the priority list too. Currently, if you do hours of work within a filter, like adding many keyframes, and you press Undo or CTRL+Z, the entire filter and all your work will disappear, with no way to recover the loss. It’s extremely catastrophic to say the least.

My suggestion in the meantime is to save your Shotcut file VERY often, like every minute or 5 minutes at the very least. Or alternatively use Backup and Save, if you prefer to maintain a version history in case a file gets corrupted during save.

Basically, the undo does not support granular level things such as adding individual keyframes. It only supports much higher level actions like adding a filter.

I just lost quite a bit of work due to this very unfortunate weakness in the undo feature. Thankfully I have a good habit from long in the past of saving every so often, so I didn’t lose as much work as I might have otherwise.

1 Like

I understand your point but having undo for every single field change on a filter would be rather unpleasant, I think a better solution would be to to merge all small filter changes that are consecutive into just the initial state (so if you change the opacity’s keyframes 15 times in a row it is only one undo to the intitial state, but if you change opacity, then add a new filter, then switch back and change the same opacity again it will make a new entry).

Of course, right now there’s no undo at all for filter changes and I’ve also been burned a few times. I’ve since learned to live with it (as you say, using save) but it is on the roadmap.

1 Like

Let’s agree to disagree. It’s the same scenario in other programs. Imagine Photoshop, where instead of undoing a single brush stroke CTRL+Z undid 35,000 brush strokes in your masterpiece, and you were back to a blank page. Digital paint artists like Manga or anything similar need and expect this granularity. I’ve seen them draw a single stroke 30 times and undo it before liking its shape and moving on to the next stroke. Uh, yikes if there is no granular undo! I’d rather have undo every single action individually and have the ability save as many undo states as I wish or have a history panel like most programs of a similar nature. This is why most software allow you to set the number of undo steps that are saved in preferences. First thing I do when I use a new software is to go into preferences and set this as high as possible.

If I’m working on keyframing a long sequence, it can take 3 or 5 hours. Just grinding through adding keyframes one by one. I have no reason to exit the keyframe mode and do something else if that is my task for the day. To have all that work vanish in a single keystroke is a nightmare. I’m very thankful I saved maybe an hour before, but I still lost a lot of work.

As soon as I discovered this severe deficiency, I immediately started using the backup and save feature, like every few minutes. I’ll hopefully never make that mistake again. I wouldn’t really call it a “mistake” as in “user error”… because most software has a granular undo. It’s shocking to see hours of work disappear instantly. I don’t think any user would expect or enjoy that behavior. The only exception is that in Word Processors, not every single character typed is a different undo set… but it also doesn’t take you back to an empty page every time you press CTRL+Z, which is practically speaking what happened to me in Shotcut today.

Again though, I’m glad it’s on the roadmap.


There is an exception to this granularity that I would agree with you on - where it goes too far. But going too far is very rare. Ironically it’s in a competing product, DaVinci Resolve. It has too much granularity in it’s undo in some situations, which is the first time I’ve ever seen it in any software. If you drag certain controls around, it’ll sometimes save multiple undo states between where you drag and where you drop the control. It’s almost like it’s saving state with a frame-per-second nature, even if you are still holding down with your mouse and haven’t released yet. Imagine dragging a circle from left to right in Inkscape or Illustrator in your document, and it creates several undo states across the page for that one mouse action. Kinda nutty, but this is what DaVinci Resolve sometimes does. So to get the node or slider back to where you started dragging it, you might have to undo several times. This is obviously overkill.

Actually, I just thought of a second example of overkill. A few apps I use consider object selections as undoable actions. This is dumb imo. For example, select a box, then select a circle, back and forth, and each object selection is something that can be undone. I can’t understand why this would be a desirable function. I can’t remember which software does this, but it’s something I use somewhat frequently.

In my opinion, any function that changes the document in any way should be undoable. But if it’s just zooming, scrolling the window or selecting an object, nah, not necessary to undo that.

Reading your very specific example, where you are changing the same property a bunch of times… maybe I could see undoing it as a group. But adding new keyframes is quite a different scenario to that example. I think I’d still go for full granularity though, at least that would be my vote. Undo every action that genuinely changes the document, as long as it isn’t something like typing 1000 is 4 undos for 1, 0, 0, and 0. That’s an obvious overreach. In web design terminology, it would be something like save change or create undo state on “defocus,” when the input box is de-selected, or the object is dropped, etc.

The Resolve example is exactly what I was initially thinking. I don’t do a lot of keyframing (did not think anyone would do multiple hours of keyframing) but I see your point now, one hour of work with no possibility of undo does sound terryfying.

I could see a middle ground of only saving a undo state after X minutes (configurable, maybe default 5 minutes) when dealing with successive multiple edits. Alternatively (and I guess easier to implement) would be a rolling autosave feature which continually keeps the last 1, 5 and 15 minutes files.


Why would you save once an hour?!? In this software or any other software… Just save dude. Ctrl+s, or even better, Ctrl+Alt+s (creates a backup in addition to saving). You can’t blame other people for saving once a day and then not being able to recover intermediate states.

That said, I saw a pull request on GitHub that says undo for filters is ready for testing. So I’m sure it’ll be available soon enough. But still, save your work or don’t be surprised when you lose something. In this software or any other.

1 Like

It’s usually not an issue honestly. If you’re in the zone, doing a repetitive task like adding hundreds of keyframes, you don’t usually think of saving constantly, nor would one expect software to crash or cause issues in such a scenario. It’s a very simple, lightweight thing.

It’s one of those situations “you’d have to be there.” If I made a video of my editing process, I’m pretty sure everyone would say, “Oh, I get it now. That makes sense. I see what you are saying now.”

Sadly, saving often basically means, “Expect software to be unstable and crash.” Most software is not unstable. Even Shotcut is not unstable, at least for me. I’ve only crashed it once in all my use. So being in the mindset to save constantly shouldn’t really be necessary. But because of the lack of undo, I’m definitely doing it now. Again though, it’s basically saying, “Since software is lacking a common feature, do a weird, incessant behavior to compensate.” Or perhaps a different perspective to make it even more clear is this: “Oh cool, software has an undo feature, so why would I worry about saving after every change I make? If something weird happens once in a while, I’ll just press Undo to reverse it. [Presses Undo] Oh @#, that undid 34000 actions in one button press! :face_vomiting: :rage:” I think the better answer is, “I hope they fix that so I don’t have to do weird, incessant behavior.” :upside_down_face:

It’s actually the reverse of what y’all are thinking too, I believe. I just wanted to undo the last node change I made, not go hundreds of steps backward. So I press CTRL+Z once, and ALL the changes are gone, and the filter is removed… because the only thing that made a state to be undone that whole time was “add filter”… not all the hundreds of keyframe changes. It’s very jarring and unexpected behavior.

But they already know this, and it’s on the list to do, so I’m satisfied. If someone said, “Nah, you don’t need undo for that” then I’d be like “uh, yes we do!”

I don’t expect a bunch of people to watch this, but this might clear things up for granular undo use case consideration, developers to see what’s going on, other users to see why it’s so jarring and unexpected, etc, etc, etc.

1 Like

As a relatively new Shotcut user, I just discovered this today. It’s really disruptive and making me seriously consider using other software. I see people have been talking about this since at least 2021:

Undo for filters is coming in version 24.01 due by the end of the month, but it does not include granular actions on keyframes or filter parameters. All of those get rolled up into a “Change ___ filter” undo history item. It does not matter how long people have asked for it.


I feel your pain, Triple-M. I’ve learned to live with it by doing the Backup and Save often and carefully planning my actions. Basically I just never press CTRL-Z, because it’s catastrophic when working on filters! Since discovering this shortcoming, I haven’t lost any work due to my change in practices. But yes, it’s annoying and not up to the barebones standards and expectations of how software should work. That said, I’m just happy it’s on the roadmap, coming soon. Pretty sweet! It’ll be a giant improvement.

I recommend looking at and using the History panel. Did you know can click in that?

That is a cool panel… but it doesn’t address or solve the filters problem (since granular filter changes don’t currently create an entry in the History panel). The road-mapped update and further refinements after feedback surely will solve this Filters issue though. Thanks for sharing about the history panel. It’s good to know it’s there.