Simple "undo" function
Simple "undo" function
A simple "undo" function for actions like move to trash, move, copy, rename etc. would be useful to me. There is a "Edit > Undo" function already implemented, but I couldn't figure out what it's supposed to do.
Re: Simple "undo" function
Hi sasha,
Yep, it would be useful, but this task is very complex and I have no idea when can I get into it.
Hopefully somewhere in 1.1.x, maybe later.
Mike.
Yep, it would be useful, but this task is very complex and I have no idea when can I get into it.
Hopefully somewhere in 1.1.x, maybe later.
Mike.
Re: Simple "undo" function
Since the UI is currently being redesigned, I'm gently pushing this thread up again. Undo is among the most important of the principles of UI design. I think NC would greatly benefit from supporting it.
Re: Simple "undo" function
Undo is one of the things that could be cool, in theory. But in my mind the code for that would be very, very tricky to write (especially once you factor in scripting and external tools) and difficult to debug. Lots of edge cases that would come up only once in a blue moon, with potentially disastrous effects.
But in about 20 years of using Total Commander on Windows I've never missed undo. I don't even know if it has it or not
Probably not. I'm weird though, so take it with a grain of salt
But undo for me is something that could be left for 2.x or 3.x.
But in about 20 years of using Total Commander on Windows I've never missed undo. I don't even know if it has it or not
![Wink ;)](./images/smilies/icon_e_wink.gif)
![Wink ;)](./images/smilies/icon_e_wink.gif)
Re: Simple "undo" function
Finder seems to have quite a long "undo memory", e.g. you can delete or rename items etc. and undo these actions even after changing the current folder.darek wrote:But in my mind the code for that would be very, very tricky to write (especially once you factor in scripting and external tools) and difficult to debug. Lots of edge cases that would come up only once in a blue moon, with potentially disastrous effects.
Now take a look at Forklift 2: here, you can undo only the last action and only while you stay in the current folder. The latter would be perfectly fine for most of the cases I wished I had undo in NC. With these constraints, it seems not a terribly hard thing to keep track of.
Btw, also a TC veteran here
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: Simple "undo" function
I don't think there needs to be an undo for copying files (cp, ditto), because you can simply delete the copy, if you did something wrong; whether you undo the copying or delete the copy, it both results in one additional user action, the only difference being that CMD-Z is kind of a universal keyboard shortcut you don't need to learn anymore. (But so is CMD-BACKSPACE.
)
Undo is good for moving files (mv), and the latter would automatically include not only Move, but also Rename or Rename in Place (which are both the same as Move), move to trash, and standard keyboard operations like CMD-C and ALT-CMD-V, the macOS way of doing CMD-X + CMD-V (Cut & Paste). [Which, by the way, makes me wonder: in Nimble Commander there is a Cut command (CMD-X), but it's always greyed out; imho the Cut menu item could be totally eliminated, because we have the Move functionality, and the above-mentioned (safe!) macOS way with CMD-C + ALT-CMD-V.]
In my view there shouldn't be an Undo for Delete & Delete Permanently, which is the NC function corresponding to rm -rf, right? If you choose to actually delete (remove) a file for real, and you've also passed the safety prompt, there shouldn't be an undo for that, because it's a destructive process/command. (Undoing this would imho be quite complicated, because you would have to recreate the file at the original path from the unlinked file contents, which HFS obscures by design.) However, just moving a file/directory to the trash is fine for undo, because it's a move command (see above), and .Trash is just a directory on your volume, only hidden, not fully obscured.
How to do it? I'm not a programmer, I just do some little shell scripts here and there, but my gut tells me database, e.g. sqlite. In Preferences the user should be able to set the maximum amount of undo steps, and then you just add (or remove) the necessary amount of rows in the undo.db. Then NC only needs the file's/directory's original path and its new path (which NC has anyway), and needs to write those into the "old" and "new" columns in the undo.db's next empty row. If there is no empty row, contents of row no. 1 are deleted for * (all columns), and the contents of rows 2->n are moved up to rows 1->(n–1), and row n receives the current operation's new old & new paths in the respective columns. In case of a user's undo command, NC would simply access the undo.db, read the contents of the old & new column in the last row that has no (null) content, internally parse the whole row contents into new and old path, internally select the file/dir at the new path, and then move that to the old path, then upon success delete the contents of the respective row in undo.db. Seems kinda simple to me, actually.
Three possible problems:
(1) for security reasons the database should be encrypted, so Preferences would need a button, which would enable the user to rebuild the database in case it becomes corrupted (like the VACUUM command in sqlite).
(2) When bulk moving many paths to new paths at once, e.g. 1000 files from one directory to another, that operation should only occupy one column in the undo.db, not 1000. (!) So NC shouldn't write paths to the undo.db rows as default strings, but as arrays, which would result in one additional parse, if the user asks NC for an undo.
(3) Nimble Commander should always wait for the user's final action. If he hits CMD-C, but then CMD-V next, it's a copy command (or duplication, if it's in the same directory), and undo isn't necessary; if he hits ALT-CMD-V next, it's a move command, and then the two paths (path arrays) are written into undo.db.
To speed up the process, the last move operation's paths (path arrays) could be kept in active memory, not written to disk. Only when the user issues the next move command on a file/dir, then NC should write the previous paths (path arrays) to disk (to the undo.db). There should be a limit on the array size, though; anything too big should be written to disk immediately, either to a tmp file or directly into the undo.db.
(PS: I can't say if undo should be applied to synchronized folders.)
EDIT: There would also need to be a redo database, so the database file should have two tables, one "undo", one "redo", each with two columns, "old path" and "new path", and each with as many columns as the number of undo steps the user has specified. Then, if the user calls Undo (CMD-Z), the paths (path arrays) from the undo table are moved over to the redo table in the same database, and when the user calls Redo (SHIFT-CMD-Z), then the values are moved again from the redo table to the undo table. (And so on.)
![Wink ;)](./images/smilies/icon_e_wink.gif)
Undo is good for moving files (mv), and the latter would automatically include not only Move, but also Rename or Rename in Place (which are both the same as Move), move to trash, and standard keyboard operations like CMD-C and ALT-CMD-V, the macOS way of doing CMD-X + CMD-V (Cut & Paste). [Which, by the way, makes me wonder: in Nimble Commander there is a Cut command (CMD-X), but it's always greyed out; imho the Cut menu item could be totally eliminated, because we have the Move functionality, and the above-mentioned (safe!) macOS way with CMD-C + ALT-CMD-V.]
In my view there shouldn't be an Undo for Delete & Delete Permanently, which is the NC function corresponding to rm -rf, right? If you choose to actually delete (remove) a file for real, and you've also passed the safety prompt, there shouldn't be an undo for that, because it's a destructive process/command. (Undoing this would imho be quite complicated, because you would have to recreate the file at the original path from the unlinked file contents, which HFS obscures by design.) However, just moving a file/directory to the trash is fine for undo, because it's a move command (see above), and .Trash is just a directory on your volume, only hidden, not fully obscured.
How to do it? I'm not a programmer, I just do some little shell scripts here and there, but my gut tells me database, e.g. sqlite. In Preferences the user should be able to set the maximum amount of undo steps, and then you just add (or remove) the necessary amount of rows in the undo.db. Then NC only needs the file's/directory's original path and its new path (which NC has anyway), and needs to write those into the "old" and "new" columns in the undo.db's next empty row. If there is no empty row, contents of row no. 1 are deleted for * (all columns), and the contents of rows 2->n are moved up to rows 1->(n–1), and row n receives the current operation's new old & new paths in the respective columns. In case of a user's undo command, NC would simply access the undo.db, read the contents of the old & new column in the last row that has no (null) content, internally parse the whole row contents into new and old path, internally select the file/dir at the new path, and then move that to the old path, then upon success delete the contents of the respective row in undo.db. Seems kinda simple to me, actually.
Three possible problems:
(1) for security reasons the database should be encrypted, so Preferences would need a button, which would enable the user to rebuild the database in case it becomes corrupted (like the VACUUM command in sqlite).
(2) When bulk moving many paths to new paths at once, e.g. 1000 files from one directory to another, that operation should only occupy one column in the undo.db, not 1000. (!) So NC shouldn't write paths to the undo.db rows as default strings, but as arrays, which would result in one additional parse, if the user asks NC for an undo.
(3) Nimble Commander should always wait for the user's final action. If he hits CMD-C, but then CMD-V next, it's a copy command (or duplication, if it's in the same directory), and undo isn't necessary; if he hits ALT-CMD-V next, it's a move command, and then the two paths (path arrays) are written into undo.db.
To speed up the process, the last move operation's paths (path arrays) could be kept in active memory, not written to disk. Only when the user issues the next move command on a file/dir, then NC should write the previous paths (path arrays) to disk (to the undo.db). There should be a limit on the array size, though; anything too big should be written to disk immediately, either to a tmp file or directly into the undo.db.
(PS: I can't say if undo should be applied to synchronized folders.)
EDIT: There would also need to be a redo database, so the database file should have two tables, one "undo", one "redo", each with two columns, "old path" and "new path", and each with as many columns as the number of undo steps the user has specified. Then, if the user calls Undo (CMD-Z), the paths (path arrays) from the undo table are moved over to the redo table in the same database, and when the user calls Redo (SHIFT-CMD-Z), then the values are moved again from the redo table to the undo table. (And so on.)
Re: Simple "undo" function
What you describe way more complicated than what I had in mind. In a nutshell, I would like NC to be able to undo
- the last move-to-trash operation (not delete permanently!)
- the last rename operation (not batch rename!)
using Cmd-Z as long as I don't change the current folder. Just in case the user accidentally messes up, realizes the mistake and instantly wants to undo the action. That's part of good UI design principles and since UI is currently being overhauled, I wanted to push this thread up.
Re: Simple "undo" function
We're not in disagreement. If you find a way to undo move-to-trash and last-rename, then you have a way to easily undo any move & rename operation, rename any file/directory, move to anywhere, from anywhere (provided NC has privileges), even across volumes, to remote servers probably too. So it would be wise to apply the undo functionality to all move operations. (Renaming is also a move operation.)
It gets a bit trickier if you want more than one undo/redo step, and if you want to apply it to more than one object in one stroke, but I can't believe that it's very complicated.
It gets a bit trickier if you want more than one undo/redo step, and if you want to apply it to more than one object in one stroke, but I can't believe that it's very complicated.
Re: Simple "undo" function
Sasha, I understand your point and won't argue with this is really important piece of software.sasha wrote:Since the UI is currently being redesigned, I'm gently pushing this thread up again. Undo is among the most important of the principles of UI design. I think NC would greatly benefit from supporting it.
Undo/redo system, however, is a quite solid task, deserving at least a whole version iteration to develop.
I'm all in UI reconstruction itself, and adding any new major features on top of it will push the delivery time into stratosphere.
v1.1.5 was released in Sep2016, and I still hope to release v1.2.0 in Feb2017 (and frankly this is optimistic) - this will be five months gap between version releases already. It's really not the pace I want to see.
Re: Simple "undo" function
Hello,
puzzled why cmd+z just doesn't work I searched the forum and found this thread.
So the obviousness is really not implemented..?
ok, last post was in january - you had no time left because auf features for an update.
What about now/next?
IMHO, UNDO is not just important but it's a base feature.
Please give it a try.
puzzled why cmd+z just doesn't work I searched the forum and found this thread.
So the obviousness is really not implemented..?
![Shocked :shock:](./images/smilies/icon_eek.gif)
ok, last post was in january - you had no time left because auf features for an update.
What about now/next?
IMHO, UNDO is not just important but it's a base feature.
Please give it a try.