Let's talk about Undo

[jacky]

Now, with jacky's refinement (which does not have to be optional) I see only one option left here for On undo:
[ ] Always prompt before undoing an action (dialog: sure to undo...)

I think this prompt should only come on a left click on the button or on Ctrl+Z, but not when selecting an action via the popup or via the action log dialog.

Sounds alright, except for one thing: I'm pretty sure anyone who hasn't been involved in this thread will assume that if the option says "Always prompt" it will mean always prompt, regardless of whether or not the undoing was triggered from a button/KS or a menu, and they could see this lack of prompt despite an option that says "Always prompt before undoing" as a bug.

[TheQwerty]

Any refinements should come at a later stage. It's tough enough to get the basics going, and they are already very hot stuff.

Which is why I only asked if you've given such a thing any thought.

I'm certainly not expecting it to be part of the Historical Action Manager version 1.0.
Maybe 1.1.

[admin]

Now, with jacky's refinement (which does not have to be optional) I see only one option left here for On undo:
[ ] Always prompt before undoing an action (dialog: sure to undo...)

I think this prompt should only come on a left click on the button or on Ctrl+Z, but not when selecting an action via the popup or via the action log dialog.

Sounds alright, except for one thing: I'm pretty sure anyone who hasn't been involved in this thread will assume that if the option says "Always prompt" it will mean always prompt, regardless of whether or not the undoing was triggered from a button/KS or a menu, and they could see this lack of prompt despite an option that says "Always prompt before undoing" as a bug.

I will drop the "always" :

[ ] Prompt before undoing the last action

The last action covers that uncertainty when you just click the button. When you select the action from a menu, it's not the "last" in that sense but an explicit choice.

English: is "previous" better than "last"? I think so because when going backward in aciton history, previous is the better term, right?

[jacky]

I will drop the "always" :

Yeah, that and adding the notion of "last action" -- Perfect solution!

English: is "previous" better than "last"? I think so because when going backward in aciton history, previous is the better term, right?

No native speaker here, but I'd prefer last actually. Because I believe the usual phrasing is "undo last action" not "undo previous action" There is, to me, is difference. As in, when referring to a "list" (e.g. moving in an history) previous/next is better (notion of movement/moving through the list or something I guess), but not here -- it's the last thing you did.

[j_c_hallgren]

[ ] Always prompt before undoing an action (dialog: sure to undo...)

I think this prompt should only come on a left click on the button or on Ctrl+Z, but not when selecting an action via the popup or via the action log dialog.

Sounds alright, except for one thing: I'm pretty sure anyone who hasn't been involved in this thread will assume that if the option says "Always prompt" it will mean always prompt, regardless of whether or not the undoing was triggered from a button/KS or a menu, and they could see this lack of prompt despite an option that says "Always prompt before undoing" as a bug.

I will drop the "always" :

[ ] Prompt before undoing the last action

When I requested "in all cases", I meant it! So that means "always" is needed as I can just as easily pick the wrong item from a menu via a mispositioned cursor as hitting the Undo icon on the TB, so yes, even though it may seem overkill to some, I'd want the extra layer of protection to confirm, ok? Even if that "all" has to be via a tweak, which I know isn't ideal as we're trying to limit those, but it would handle both types of users.

The last action covers that uncertainty when you just click the button. When you select the action from a menu, it's not the "last" in that sense but an explicit choice.

English: is "previous" better than "last"? I think so because when going backward in aciton history, previous is the better term, right?

Yes, 'previous' would be preferable to 'last' for this situation but jacky is correct in that it's more common to use 'last'...but you could also say 'requested'/'selected' as that would be a bit more generic.

[avsfan]

This is sounding very exciting!

I'm also wondering if you're planning to include redo functionality as well -- I'm guessing so, but wanted to check... Since it sounds like you're implementing a list so multiple undo steps are available, you could also have a means to go forward again...

Just a thought... (though it's probably already done!)

[admin]

This is sounding very exciting!

I'm also wondering if you're planning to include redo functionality as well -- I'm guessing so, but wanted to check... Since it sounds like you're implementing a list so multiple undo steps are available, you could also have a means to go forward again...

Just a thought... (though it's probably already done!)

Sure!

[admin]

[ ] Always prompt before undoing an action (dialog: sure to undo...)

I think this prompt should only come on a left click on the button or on Ctrl+Z, but not when selecting an action via the popup or via the action log dialog.

Sounds alright, except for one thing: I'm pretty sure anyone who hasn't been involved in this thread will assume that if the option says "Always prompt" it will mean always prompt, regardless of whether or not the undoing was triggered from a button/KS or a menu, and they could see this lack of prompt despite an option that says "Always prompt before undoing" as a bug.

I will drop the "always" :

[ ] Prompt before undoing the last action

When I requested "in all cases", I meant it! So that means "always" is needed as I can just as easily pick the wrong item from a menu via a mispositioned cursor as hitting the Undo icon on the TB, so yes, even though it may seem overkill to some, I'd want the extra layer of protection to confirm, ok? Even if that "all" has to be via a tweak, which I know isn't ideal as we're trying to limit those, but it would handle both types of users.

The last action covers that uncertainty when you just click the button. When you select the action from a menu, it's not the "last" in that sense but an explicit choice.

English: is "previous" better than "last"? I think so because when going backward in aciton history, previous is the better term, right?

Yes, 'previous' would be preferable to 'last' for this situation but jacky is correct in that it's more common to use 'last'...but you could also say 'requested'/'selected' as that would be a bit more generic.

It's not necessary anymore because I decided to show only the next undoable action in the popup, so only this:

Code: Select all

Next Undo item
- (sep)
Action Log...

I don't think a prompt is necessary here. Or I give you a general "Prompt everything always"

Reason for showing only one: it should not be that easy to do non-sequential undos (which can easily mess things up).

[zer0]

No, "Undo last script" would be a very bold promise. On this level Undo is not realistic. You can however use the action log to undo a bunch of sequential actions in one go.

Understood. To add further, it's not unreasonable for scripts to feature many file operations (10+, for example). Will there be a limit in the action log to how many last actions can be done? What will govern the length of that log: all file operations in XY since its start or set number? Will each pane have its own log?

I know you said that refinements will come later, but if they aren't thought of now they may be difficult to implement in the future.

[admin]

No, "Undo last script" would be a very bold promise. On this level Undo is not realistic. You can however use the action log to undo a bunch of sequential actions in one go.

Understood. To add further, it's not unreasonable for scripts to feature many file operations (10+, for example). Will there be a limit in the action log to how many last actions can be done? What will govern the length of that log: all file operations in XY since its start or set number? Will each pane have its own log?

I know you said that refinements will come later, but if they aren't thought of now they may be difficult to implement in the future.

The action log is global (all panes, all tabs). It currently holds 100 actions (where e.g. a mass rename = 1 action, not many). But I will probably make this totally configurable (= infinite if you like).

[j_c_hallgren]

Reason for showing only one: it should not be that easy to do non-sequential undos (which can easily mess things up).

Well, that may be true in some cases but not in general I think...much of what I do is single function operations and totally unrelated to other functions, so I may well want to undo only the rename of a shortcut (that was then followed by a copy of other totally unrelated files followed by a create of a new folder, etc.) and thus a non-seq undo is required because the following functions were proper and desired and shouldn't be affected.

It's up to the user to know what linkages exist between the entries in action log and if they (entries) are described sufficiently, it should be clear if that would cause a problem.

[admin]

Reason for showing only one: it should not be that easy to do non-sequential undos (which can easily mess things up).

Well, that may be true in some cases but not in general I think...much of what I do is single function operations and totally unrelated to other functions, so I may well want to undo only the rename of a shortcut (that was then followed by a copy of other totally unrelated files followed by a create of a new folder, etc.) and thus a non-seq undo is required because the following functions were proper and desired and shouldn't be affected.

It's up to the user to know what linkages exist between the entries in action log and if they (entries) are described sufficiently, it should be clear if that would cause a problem.

You will be able to do that, but through a safer interface: the action log.

[j_c_hallgren]

You will be able to do that, but through a safer interface: the action log.

Oh..ok...the way it was written before wasn't quite that clear so I just wanted to make sure...and then if one can select desired item via log, the need for a optional confirm prompt come into play...at least for me!

This was reinforced by the last time I un-deleted something from Recycle Bin in WE...I was on the wrong one and had a heck of a time finding where it put it back to so I could re-delete it (where I had to confirm delete so a matching one on undo seems ideal).

[serendipity]

Reason for showing only one: it should not be that easy to do non-sequential undos (which can easily mess things up).

Well, that may be true in some cases but not in general I think...much of what I do is single function operations and totally unrelated to other functions, so I may well want to undo only the rename of a shortcut (that was then followed by a copy of other totally unrelated files followed by a create of a new folder, etc.) and thus a non-seq undo is required because the following functions were proper and desired and shouldn't be affected.

It's up to the user to know what linkages exist between the entries in action log and if they (entries) are described sufficiently, it should be clear if that would cause a problem.

You will be able to do that, but through a safer interface: the action log.

Something to ponder on while we are one it (keeping in mind that refinements will come later):
Since you already know the broad categories of undos: like rename (list, catalog, tree and elsewhere), copy/move/backup file, catalog related, toolbar related etc etc, how about an option to show those undo logs as an organized (categorized) list?
That way if I just have to undo a rename i directly go to the related category and undo it, as opposed to hunting through the mess of 100+ actions.
Another way to categorize would be to have it the way you planned it now but assign different colors or different font types or whatever way you think will help users identify different undo actions.
Just my opinion.

[zer0]

I hope that we can still talk about "Undo"

I have a feeling this was mentioned, but I don't recall who and where and I can't find either, so here goes: "Is there a reason why a file, on which an Undo operation is performed, looses selection? For example:

1. Selected a file
2. Run a script to rename as <curfolder> // focus on that file remains
3. Clicked Undo arrow
4. Undo was done, but selection was lost. Not even having Sticky Selection on helped!

This is unexpected behaviour to say the least because a) selection was there prior to running a script and b) sticky selection is there to avoid exactly this sort of situation