Multi Level Undo/Redo

[scruffyduck]

We are re-writing the old Undo/Redo system and in the process we expect to make it possible to undo actions that are earlier than the last one. There are a couple of ways to do this.

First select a past action and undo it (or redo it). - The results of this might be unpredictable depending on what else you have done since.

Second is to select a past action in the list and have ADE undo everything back to an including that one - or redo everything. This is the way programs like Visual Studio work and I can see that it is both predictable and safe - but how useful overall - saves you backtracking one at a time though.

Third - let's not bother with undo/redo except for the last action

 

[danfoster]

In answer to your question: "but how useful overall?"

Very useful

 

[GHD]

In answer to your question: "but how useful overall?"

Very useful

My answer would be "Not at all".

 

[scruffyduck]

It is always nice to have a debate

 

[danfoster]

My answer would be "Not at all".

What's your own preference? The third choice (having discounted the second )?

What if you wanted to try moving a taxiway (with all its many links and interconnections to other taxiways etc.) a few feet one way or another, and then decided after some additional intermediate work, that the end result was worse than what you had before? Surely a couple of clicks on the undo function in the knowledge that everything would be back to square one is useful? It's a bit like having a multitude of back-ups, with the freedom to select exactly the one which suits your purpose best.

EDIT: I probably argued that a bit strong, because I read choice three as being "can only undo last action" in the sense that you can only click undo once! Obviously that's ridiculous...

 

[GHD]

What's your own preference? The third choice (having discounted the second )?

A single-level undo. With the proviso that I could repeat the action, and that an undo would not undo an immediately preceeding undo (if you see what I mean).

 

[scruffyduck]

A single-level undo. With the proviso that I could repeat the action, and that an undo would not undo an immediately preceeding undo (if you see what I mean).

Not really - undo one at a time and redo one at a time?

 

[GHD]

Not really - undo one at a time and redo one at a time?

What I mean is that Undo would undo a previous edit, a second Undo immediately afterwards would undo the edit previous to that undone by the previous Undo

Consider it as a stack:

edit 1
edit 2
edit 3
undo (undoes edit 3)
edit 1
edit 2
undo (undoes edit 2)
edit 1
redo (reinstates edit 2)
edit 1
edit 2

etc.

 

[tgibson]

I would prefer Undo/Redo that allows you to Undo each action in turn with a click of the Undo button. If I want to undo the action I did three times ago, I click the Undo button 3 times and action, 1, 2, and 3 are undone in order. Same for redo.

This is what I am used to.

This isn't single level undo (i.e. you can't undo any action but the last), and it's not the multi level redo you describe above (selecting from a list). So I don't know how to vote...

 

[scruffyduck]

I would prefer Undo/Redo that allows you to Undo each action in turn with a click of the Undo button. If I want to undo the action I did three times ago, I click the Undo button 3 times and action, 1, 2, and 3 are undone in order. Same for redo.

This is what I am used to.

This isn't single level undo (i.e. you can't undo any action but the last), and it's not the multi level redo you describe above (selecting from a list). So I don't know how to vote...

That's what I would call single level undo Tom. ADE had unlimited levels of undo but currently only a single level undo per action as you describe.

Multi level undo is look at a list of actions and select one in the past to restore the state of the airport to that point.

To be accurate the new system in ADE will allow you do continue with single level (or step) undo if you wish.

 

[danfoster]

I would prefer Undo/Redo that allows you to Undo each action in turn with a click of the Undo button. If I want to undo the action I did three times ago, I click the Undo button 3 times and action, 1, 2, and 3 are undone in order. Same for redo.

This is what I am used to.

This isn't single level undo (i.e. you can't undo any action but the last), and it's not the multi level redo you describe above (selecting from a list). So I don't know how to vote...

I think what you want is option 3, but the way option three is worded make's it seem like only one undo can be achieved. That's why I initially argued against it. However, my current understanding is that option three allows multiple undo - it's just that for every undo you must click the "undo" button, rather than being able to "shortcut" straight to an earlier state (which I think is what option two is about).

Single level undo does not mean that you can only undo one action. It means that you can only undo one action at a time.

Have I got that right?

ps. George, I do see what you mean - and I love the way you explained it too

EDIT: Whoops, cross-posted. Jon has now clarified, thanks.

 

[mdm248111]

I like both ideas!

 

[scruffyduck]

I like both ideas!

Well THAT is NO help at all Michael

 

[BASys]

Hi Folks

Jon -
Selectable undo please.

Particularly relevant to co-located items.

My workflow and aims may be bizarre
but I often need to move items aside,
peform a different object move,
then reinstate original item's placement.

HT makes sense
ATB
Paul

 

[scruffyduck]

Hi Folks

Jon -
Selectable undo please.

Particularly relevant to co-located items.

My workflow and aims may be bizarre
but I often need to move items aside,
peform a different object move,
then reinstate original item's placement.

HT makes sense
ATB
Paul

Why not use Send to Back for the top item if you want to get to one under it?

 

[BASys]

Hi Folks -

Why not use Send to Back for the top item
if you want to get to one under it?

Jon -
My apologies.
Works beautifully.

IIRC it wasn't implemented last time I'd performed this task,
(see Suggestions thread),
I'm only now getting back to working on those AFDs.



Still would prefer the option 1,
as I'm sure there was some other reason for doing so.
(Will post if I remember what).



Thanks again
ATB
Paul

 

[scruffyduck]

No worries. I can't remember when we added that.

 

[Pyscen]

Thats a tough question,... though a continuous undo sometimes is nice,... memory could be a problem down the road... I guess the question could be then: How far would you like the undo/redo go? 5 back or 10 back etc. Of course, undo's/redo's could be written onto disk temporarily (solves the memory problem then). So I guess my original answer should be changed!

'round and around she goes, where she stops nobody knows....

 

[scruffyduck]

Thats a tough question,... though a continuous undo sometimes is nice,... memory could be a problem down the road... I guess the question could be then: How far would you like the undo/redo go? 5 back or 10 back etc. Of course, undo's/redo's could be written onto disk temporarily (solves the memory problem then). So I guess my original answer should be changed!

'round and around she goes, where she stops nobody knows....

The new code that handles this allows a limit to be set on the number of levels. We will probably make it available to the user to set. Generally the amount of memory required by each transaction (what gets stored when you do something so that it can be undone/redone later) is not that great (less than 1Kb each). I think the new code should be more memory friendly than the existing code as well.

I have seen systems where the whole object (in this case it would be the project) is saved each time the state changes - this is horrible from both memory and speed of course. The new ADE system will just store the state of object properties before any changes are made so that they can be undone/redone later. Thus 100 transactions in the undo/redo stacks should be less than 1Mb.

 

[Pyscen]

The new code that handles this allows a limit to be set on the number of levels. We will probably make it available to the user to set. Generally the amount of memory required by each transaction (what gets stored when you do something so that it can be undone/redone later) is not that great (less than 1Kb each). I think the new code should be more memory friendly than the existing code as well.

I have seen systems where the whole object (in this case it would be the project) is saved each time the state changes - this is horrible from both memory and speed of course. The new ADE system will just store the state of object properties before any changes are made so that they can be undone/redone later. Thus 100 transactions in the undo/redo stacks should be less than 1Mb.

Sounds Great!! So I would like to definately change my answer then, Give us as many possble changes as our systems allow please!