Version: (using KDE 4.3.4) Installed from: Unspecified Linux When the user presses Delete in the View mode N times, he expects N photos to be deleted. He can make this decision because the filmstrip shows him the next few photos. However, instead of caching the Delete function, Digikam tries to delete the deleted photo, leading to an error "XYZ photo does not exist". Steps to reproduce: 1) In View mode press Delete repeatedly
You mean the mode where one image is large with a thumbnail bar at the bottom? This does not apply when in the icon view mode, does it?
I also noticed this in the icon view. Simply press delete two times with fast speed there.
> You mean the mode where one image is large > with a thumbnail bar at the bottom? Yes. > This does not apply when in the icon view > mode, does it? I can reproduce there as well.
Ok. I assume the problem is this: - first delete - KDE process started to delete file - file is deleted - ** - digikam is notified that something happened - digikam triggers scanning - scanning is done, database is updated - view is notified about change - album listing is started - ** - album listing results are received in main thread, view is updated When pressing delete in the time between the **, the described behavior will occur.
The easiest solution would be to move the focus on to the next item when pressing delete?
SVN commit 1080759 by mwiesweg: When deleting images, move to the next index. CCBUG: 224052 M +31 -1 digikamimageview.cpp M +5 -3 imageviewutilities.cpp M +1 -1 imageviewutilities.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1080759
Dotan, Please test and report using code from svn trunk. I would to close this file for 1.1 release Thanks in advance Gilles Caulier
I'm in dependency hell, Gilles, and I won't be testing this SVN, sorry. But this issue should be easy to test: just click Delete three times quickly, and check that three photos were deleted without an error being thrown.
Suggested test successful (item do not disappear immediately, but cursor moves to next entry, so three key pressed will delete three images)
I'm still not convinced that this is a solution that fulfills the user's expectations. If I'm pressing delete I expect an immediate response of the GUI with removing the selected items. If this is not possible, a progress dialog should appear. Can't we hide the items immediately after pressing delete and unhide them in case the kde deletion progress reports an error?
On which level should we filter out the deleted images? Filter model? I agree that the current behavior is not good, it's simply to long until the images are removed.
Would it be possible to put this in an extra filter model (DeleteHidingFilterModel) that only does this one thing so it can be reused? This filter model could simply "intercept" the delete action and hide all selected items immediately until they disappear from the core model or re-enable them on an error.
This can be a lot of work because the view expects an ImageFilterModel which expects and ImageModel. It may be easier to extend the ImageFilterModel.
But then it cannot be reused for the eg. the tree views.