"Clear Selection" part of Undo/Redo Stack?

[metajake]

Hi all.

"Clear Selection" is part of the Undo/Redo stack. Should it be? Why or why not?

My scenario why not:

I have multiple elements in a layout. I make some changes. I like the changes, but I want to see the previous layout (and I neglected to make my changes to a duplicate layout). My solution (in a typical user experience paradigm) is to Undo my changes, make a copy of all the elements, then Redo the changes and paste my selection (of the elements in their previous layout) next to the revised elements.

I reported this as a bug ...

... but @Chris_K deemed it by design.

 

Might anyone on the development staff or otherwise, be willing to offer up a scenario in which "Clear Selection" should be part of the Undo/Redo stack?

User @Kal offers some good perspective on why "Clear Selection" should not be part of the Undo/Redo stack..

"undo/redo should be reserved for destructive actions. And sometimes space bar doesn't work [in the case that you want to Clear Selection, just to clearly view your layout] —say, if there is focus on a text field like Swatches > Opacity."

 

Thank you Affinity team, for your incredible software which I use everyday.

[Aammppaa]

Not an answer to your question, but I have always worked the other way around when I like where I am, but want to compare with where I was…

1. Copy the object.
2. Go back through history to earlier state.
3. Paste object.
4. Compare the two.

Alternatively: look into Snapshots https://affinity.help/designer/en-US.lproj/index.html?page=/DesignAids/snapshot.html?title=Using snapshots

1. Make a snapshot of where you are now.
2. Go back in History to find earlier state.
3. Copy object in its earlier state.
4. Restore the Snapshot.
5. Paste the object.

Or even…

1. Make snapshot of now.
2. Go back in History.
3. Make a snapshot of then.
4. Toggle at will between the two!

Hope one of these helps with your workflow.

[metajake]

@Aammppaa I see! This is a great, alternate (new way for me) to start using Affinity Designer.

Thank you so much.

[Kal]

Great suggestions Aammppaa. I do agree with metajake in principle though, that non-destructive actions (like deselecting an object) shouldn't be added to undoable history. Without thinking too hard about how or where this catches me out, I know it does from time to time. As I said on metajake's other post:

"Some people may remember that with InDesign CS3, Adobe started including non-destructive actions (switching to preview mode, showing and hiding guides, etc) in the undo/redo stack, and it was a nightmare. People hated it, and Adobe restored the previous behaviour. In Adobe apps, I like that the relevant selection comes back when you undo or redo."

The Adobe behaviour provides the best of both worlds I think… You can safely deselect an object without losing redos, but if you do undo or redo, you get your selection back.

[Zambetti]

This thread is a couple years old, but I'll revive it since it's still an issue three years later in 2021 (Affinity Designer 1.9.3 Mac).

It is often the case that I want to grab something from the past (undo many times, copy something, redo to where I was, and paste).

As it is now, when I go back many steps into the history via undo, then copy ... all my work is lost. It is quite frustrating. 

I cannot think of a useful purpose for non-destructive/non-editing actions to wipe out the undo/redo stack, does someone know of a reason why it's the way it is, or perhaps know of a workaround for this problem?

Edited July 7, 2021 by Zambetti
clarity

[Old Bruce]

Hi and welcome to the forums @Zambetti

Look for the little branch symbol in the history list (looks a bit like the letter h) after you do your copy. View > Studio > History to show hide the History panel.

[Zambetti]

Excellent. I didn't notice that branch icon. Interesting and unusual approach to undo-stack / history; sort of a versioning system approach, but a versioning system that is prone to loss upon retrieval. I'm inclined to agree with the previous discussion in the thread that non-modifying actions, such as selection-change or copy, should not trigger such a sequence; one that requires active intervention to preserve work, feels like the wrong trade-off. Maybe when I live with it for a while I will discover there are benefits of this approach that outweigh the obvious pitfalls. Regardless, it's very good to know that it's possible. I will keep a closer eye on the history panel from now on. Thank you for the tip and quick response.

Edited July 7, 2021 by Zambetti
semantic correction

[MikeTO]

I find the undo approach curious too but it's nothing I can't work around. It's functional.

Non-destructive actions are part of undo for every app it's just that they're typically grouped with destructive ones in the undo stack. If you move a box in most programs and then deselect it, Undo Move will move it back and reselect it.