XYplorer Beta Club

zer0 wrote: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

No, Sticky Selection has nothing to do with this sort of situation.

Keeping the selections after a rename when this rename changes the order of items is not easy because, well, the items changed their names and their order. Tough.

Question: You do 3 actions. Then you undo the second (using non-sequential undo). Then you decide to undo all 3 using cumulative undo. Now, should the second (already undone) action be redone, or should it be skipped because it is already undone? Currently it's redone, but now I think it should rather be skipped.

admin wrote:Question: You do 3 actions. Then you undo the second (using non-sequential undo). Then you decide to undo all 3 using cumulative undo. Now, should the second (already undone) action be redone, or should it be skipped because it is already undone? Currently it's redone, but now I think it should rather be skipped.

I can see that this could go either way depending on what the exact action was, so while I dislike excess pop-ups, maybe one just for that type of action allowing user to pick "redo"/"skip" would give the maximum flexability?

admin wrote:Question: You do 3 actions. Then you undo the second (using non-sequential undo). Then you decide to undo all 3 using cumulative undo. Now, should the second (already undone) action be redone, or should it be skipped because it is already undone? Currently it's redone, but now I think it should rather be skipped.

I think it should be skipped. This is simply because I feel that in order to redo an undo that undo has to be undone and then redone, which is a lot of ado (almost a pun there ). The way I see it in my head is taking a step back and then a step forward to stay on the same spot, is that what a redo of undo essentially is? On the other hand, for the sake of flexibility, I won't oppose a tweak to enable redo of an action that has already been undone

admin wrote:Keeping the selections after a rename when this rename changes the order of items is not easy because, well, the items changed their names and their order. Tough.

I think I could fix that.

admin wrote:Question: You do 3 actions. Then you undo the second (using non-sequential undo). Then you decide to undo all 3 using cumulative undo. Now, should the second (already undone) action be redone, or should it be skipped because it is already undone? Currently it's redone, but now I think it should rather be skipped.

I'd definitely go for skipped, as that makes most sense (to me). Of course what would be the very best would be that, on AL, one can select multiple actions (holding Ctrl/Shift) and ask for a cumulative undo of those, thus allowing one to undo multiple actions at once in the reverse order they were done, all the while skipping some in between and whatnot...

Also, I find it counter-intuitive that a right-click on an item on the AL doesn't trigger the ctxt menu for that (right-clicked) item, but the one selected, even if not visible. Especially though given how pretty much everywhere else in XY when it applies it works as expected, and selects said item and triggers its ctxt menu... (List, Tree, CKS...)

admin wrote:Question: You do 3 actions. Then you undo the second (using non-sequential undo). Then you decide to undo all 3 using cumulative undo. Now, should the second (already undone) action be redone, or should it be skipped because it is already undone? Currently it's redone, but now I think it should rather be skipped.

I think is should be skipped, otherwise it would be to difficult* to spot what will be happen.
( * maybe not while testing but if you would be in the middle of some real work.)

- i undo one
- i undo all -- and would expect to have undo all now, and not redo one of the list again


- i undo one
- i undo all -- and redo the first again in one stroke ... would be too tricky.

jacky wrote:

admin wrote:Question: You do 3 actions. Then you undo the second (using non-sequential undo). Then you decide to undo all 3 using cumulative undo. Now, should the second (already undone) action be redone, or should it be skipped because it is already undone? Currently it's redone, but now I think it should rather be skipped.

I'd definitely go for skipped, as that makes most sense (to me). Of course what would be the very best would be that, on AL, one can select multiple actions (holding Ctrl/Shift) and ask for a cumulative undo of those, thus allowing one to undo multiple actions at once in the reverse order they were done, all the while skipping some in between and whatnot...

Also, I find it counter-intuitive that a right-click on an item on the AL doesn't trigger the ctxt menu for that (right-clicked) item, but the one selected, even if not visible. Especially though given how pretty much everywhere else in XY when it applies it works as expected, and selects said item and triggers its ctxt menu... (List, Tree, CKS...)

I agree with skip and with right-click select.

I also agree with multi-select but currently my list does not support this. Comes in Undo 2.0...

PS: what I could do is checkboxes! "Undo all checked items..." that would match similar interfaces in XY...

admin wrote:I also agree with multi-select but currently my list does not support this. Comes in Undo 2.0...

PS: what I could do is checkboxes! "Undo all checked items..." that would match similar interfaces in XY...

Sure, that would work too. (Only thing is that checkboxes without multi-select mean that to select say 10 items, you need to click 10 times, whereas w/ multi-select only two while holding shift for the second one. It just makes things easier... )

jacky wrote:

admin wrote:I also agree with multi-select but currently my list does not support this. Comes in Undo 2.0...

PS: what I could do is checkboxes! "Undo all checked items..." that would match similar interfaces in XY...

Sure, that would work too. (Only thing is that checkboxes without multi-select mean that to select say 10 items, you need to click 10 times, whereas w/ multi-select only two while holding shift for the second one. It just makes things easier... )

True. Plus I had other plans for the checkboxes: take out specific actions from the Undo/Redo stuff (while still keeping them in the log), like to make them untouchable.

In 8.50.0023 This does not work on my XP system. Instead, a file that was below undone file prior to undoing is selected.

zer0 wrote:In 8.50.0023

Code: Select all

    ! Undo Rename: List selections were lost or wrong when items were
      renamed and repositioned due to their new name. Fixed.

This does not work on my XP system. Instead, a file that was below undone file prior to undoing is selected.

Hmm, I wonder what's going wrong. Works fine here.

admin wrote:Hmm, I wonder what's going wrong. Works fine here.

I narrowed it down even further. If a rename is done manually (go into rename mode, type new name yourself, press enter) and then undone, then selection is kept. If a rename is done using a script, which it is in my case, then selection is lost.

zer0 wrote:

admin wrote:Hmm, I wonder what's going wrong. Works fine here.

I narrowed it down even further. If a rename is done manually (go into rename mode, type new name yourself, press enter) and then undone, then selection is kept. If a rename is done using a script, which it is in my case, then selection is lost.

Thanks, that helped!

admin wrote:Thanks, that helped!

No, thank you - problem fixed!