Bug 246727

You can simply restore them using the normal trash restore operation.

No.
This results in an error message.

And how to know which images I just deleted? Perhaps I've got a row of images of the same subject, and only one of them perfectly sharp. If I delete the unsharp ones first and then later the sharp ones accidentially, I can go through all images again.

What is the message? I can't reproduce this here.

To solve the problem of finding the images just deleted I would vote for a column in the list view of the trash that manages a deletion date. Like this the feature is available for every other use case as well.

It complained about a folder not existing anymore. But
1. I didn't delete a folder in the meantime
2. All of the images I selected have been in folders that still exist.

A deletion date would be very helpful, that is true. I'd nevertheless vote for a built-in undo action (be it even only one step). E.g. if I'm deleting other files at the same time. Or is restoring from the trash complex?

For the deletion date please open a bug report against the kde lib providing the trash.

Undo seems to be possible using FileUndoManager from kio. We need to check this.

#246740 added.

Is this bug still active? If so, please extend this undo feature wish to all file system operations if there is already an API for file system level undo.

I recently accidentally moved about 1500 photos scattered over hundreds of albums on my NAS into a single album by searching for "similar" images and collecting them, not realizing that Digikam would also find images on the mounted NAS image collections... I just wanted to do this for local images. Now how would I get those moved images back into the right folders? :-(

I hope it is still active. To clarify. Usecase: You delete a bunch of photos, one by one and delete one too many (sound familiar?:-) A simple Ctrl-z to undo the last one would be a very quick and userfriendly way to solve such a mistake.

Adding ctrl-z to more operations is appreciated too. And of course a stack mechanism to undo not only the last but several operations would be great too.

*** Bug 400551 has been marked as a duplicate of this bug. ***

Git commit 27bf9d3c50e8484822ad6358856d696593626aee by Maik Qualmann.
Committed on 03/11/2018 at 21:52.
Pushed by mqualmann into branch 'master'.

add undo button to the trash view to restore items
this restore all deleted items since startup
FIXED-IN: 6.0.0

M  +2    -1    NEWS
M  +89   -17   core/app/views/trashview.cpp
M  +1    -0    core/app/views/trashview.h
M  +5    -0    core/libs/dtrash/dtrashiteminfo.cpp
M  +2    -0    core/libs/dtrash/dtrashiteminfo.h
M  +12   -0    core/libs/dtrash/dtrashitemmodel.cpp
M  +5    -0    core/libs/dtrash/dtrashitemmodel.h

https://commits.kde.org/digikam/27bf9d3c50e8484822ad6358856d696593626aee

This poses a problem in the other direction: When there is no undo possibility, it is indeed a problem when you accidentally delete a photo. On the other hand, when you "restore all deleted items since startup", it is also a problem: Imagine that you delete 1000 photos one day. Then you hibernate the computer and wake it up one week later, in order to go on editing. You then delete accidentally one picture and perform an undo. As a result, 1001 pictures would be undeleted. With bad luck, this would be unrecognized, and when you recognize it, probably the same 1000 pictures cannot be remembered, throwing away one day of editing.
It would be a much less surprising behavior if the undo was like you are used to it in other programs, undeleting one by one ordered by deletion time.

I'll find a solution tomorrow...

Maik

Git commit 58ed099e3ed5093ceaec96ddcc00c926f83c7b61 by Maik Qualmann.
Committed on 04/11/2018 at 07:58.
Pushed by mqualmann into branch 'master'.

undo last deleted items and use constant delete time

M  +13   -13   core/app/views/trashview.cpp
M  +2    -2    core/libs/database/utils/ifaces/dio.cpp
M  +20   -12   core/libs/dtrash/dtrash.cpp
M  +14   -8    core/libs/dtrash/dtrash.h
M  +2    -2    core/libs/iojobs/iojob.cpp
M  +8    -1    core/libs/iojobs/iojobdata.cpp
M  +4    -2    core/libs/iojobs/iojobdata.h

https://commits.kde.org/digikam/58ed099e3ed5093ceaec96ddcc00c926f83c7b61

Is the number of undeleted files configurable or determinable, at least afterwards?

I do not understand the question. Every undo step undoes the last deletion, that can only be one file or even thousands of files. Until the trash is empty. This works even after the restart.

Maik

OK, then I misunderstood this. I thought that the last n files are undeleted. As it seems, n=1, so no problem arises here.

Hello Maik,

Thanks for solving this bug. Great work. I will try it asap.
Merry Christmas!

In digikam-6.2.0-git-20190613T125237-qtwebkit-x86-64.appimage, where can I find it?

In the trash view the lower left button labeled "Undo"?

Maik

What is the "trash view" and how do I activate it?

I can't find the Undo button anywhere.

Created attachment 121451 [details]
undotrash.png

I had deliberately not responded because I could not imagine that it would not be found where the function is "hidden". ((:-)) I left my screenshot in German...

Maik

Indeed, now I have seen it. I thought that this is again an issue with the different Linux distributions...
By the way, what is the difference between "Rückgängig" and "Wiederherstellen"?

With "Rückgängig" (Undo) all files of the last deletion will be restored, which can be 1 or many image(s). With "Wiederherstellen" (Restore), the manually selected images are restored from the table view.

Maik

And another thing: When you are in the phase of cleaning up, images are deleted with one keypress ("Entf" or "Del"). The undo should also be possible with one keypress (Ctl-Z). Here, you have to stop what you are doing (presumably the light table), go to the trash bin and select "Undo", and then return to what you just did. This completely interrupts the work flow.

An undo of all last images is now possible. An undo with Ctrl-Z would presuppose that all other actions (apply metadata) can also be undone. Only deleting images would be illogical. For this purpose, however, already exists a bug entry. I close this bug now.

Maik