I noticed that while having shapes selected and working with nodes or applying booleans, if I interact with the layers (i.e, turn visibility on/off, or lock/unlock) then return to the canvas and continue working with nodes, in some cases the undo does not recover the steps in order and/or leaves some steps out of the undo queue.
If the latter occurs there is no way to undo that step. When the issue occurs, going forward with redo and backward with undo also affects the interaction with the layers. I think the issue is related to the fact that the history may be including the interaction with the layers and not only the work inside the canvas, which is my expectation for the undo/redo.
For example, I had 5 circles, I changed mode from selection to direct selection, I was tweaking the position of some of the nodes of these circles. I needed to check other layers then turned on/off some of them, including the layer where I was working on; I returned to this layer to continue work, realised that I made a mistake so I tried undo a few times.
The result was that all the layers went first hidden, so I tapped redo hoping I could undo the undo but instead I lost control and was able to undo a few steps but leaving the step that I needed to fix permanently. The history seemed to go back including the operation that I did with the layers.
If the history is meant to include every single step so some users can run timelapse (not a feature that I use) this behaviour could be controlled with a setting in preferences for all users like me who need accurate undo/redo affecting only the work inside the canvas.
In any case, the current behaviour of including the operations outside of the canvas seems to cause bugs.
Is this undo/redo behaviour expected from Vectornator? Were you guys aware of this bug? It has happened to me at least a dozen times. I will try to avoid interacting with layers when I’m expecting undo operations but I believe this limits dramatically the normal workflow of Vectornator. We should be able to do anything outside of the canvas and expect that when we return to the canvas the history is preserved and the undo/redo will respond as we need.
Can you please confirm the above?
I’ve seen this issue and a few related ones (e.g fill lost on undo). When I contacted support, the response was:
we’re actually tracking this issue already but it’s hard to fix it because it’s caused by the system.
Thanks @llui85, I have run a few more tests and it definitely looks like it’s connected to the undo/redo functionality also saving into the history queue operations outside of the canvas. My understanding is that the undo/redo functionality is controlled inside Vectornator and not the iOS.
Hey Vectornator team, could you please advise about this bug?
@nyx I definately understand where you’re coming from; view operations probably shouldn’t affect the undo history, which they do (somewhat inconsistently) at the moment.
Part of the challenge of solving this is that it’s difficult to categorise what’s a “view” operation. For example, layer opacity is included in the image export (I think, I’m not at my iPad at the moment). It would make sense for this to be undoable - what if it was set to an important value before it was changed? As you say, this would be a good candidate for a setting.
This could also be a general design issue with the whole undo/redo concept - we tend to use the somewhat volatile undo buffer to store important data. I can’t really think of any programs that implement this well (maybe git, but that’s certainly not going to happen in Vectornator).
I have also been having this problem in a lot of different contexts. It happens almost every day that I accidentally move something I didn’t intend to, I hit undo, and the change is not fixed and something else is undone. Like, I accidentally moved a text block up higher when I had it where I wanted it, and then completed another action. I hit undo twice, the most recent action was undone, but moving the text block was not, and it just skipped to the action before that. The text block stayed in the spot I had unintentionally moved it and there was no record of where it had been before that.
This has honestly been such a frequent problem that it’s made me reconsider using Vectornator. I’m still a relatively new user but I don’t think I’ve ever encountered a program that just doesn’t undo correctly.
I genuinely cannot get undo/redo to register ANY node changes whatsoever. It will register deletions, line/object creations, copy/pastings pretty consistently but I can’t get the program to just undo a deletion or editing of a node.
For example: I put in an object (create a new one or paste one in). I edit or delete a node. I press undo, and the object disappears. If I then press redo, the object WITH the edited or deleted node reappears.
This is driving me nuts.
I cannot tell if this is inteded behavior or not, and the help documents are not helpful with this issue. This is the closest thread I have found to the issue I am experiencing, so I created an account to add in. IS the program supposed to save node editing as part of the undo/redo queue? If it isn’t that’s fine, I just need to find a different program.
FWIW I am running one of the original iPad Pros on 15.2.1; I’m going to try updating to 15.4 see if the issue gets any better, but my hopes aren’t high.
Okay! So coming back after updating to 15.4.1 (and Vectornator 4.7; previously I was on 4.6 I think?) seems to have greatly alleviated this issue for me. Don’t know which update fixed it, but I’m glad node editing is undo/redo-able now. ‘u’
Thank you for bringing this up.
We’re currently investigating issues related to the Undo/Redo history.
I will keep you posted as soon as I have an update.
You may have noticed that we have launched a recent update, 4.8.0.
If you haven’t yet, please try out this latest version and let us know whether the issue related to undo/redo persists for you.
If you have any questions or feedback, feel free to reach out.