When the last image in the folder is deleted, the image stays on screen, but is in fact removed. Steps to reproduce: 1/ Have a folder with two images 2/ Open the first image (view mode) 3/ Delete the first image using shift+del 4/ It moves to the next image, delete that one too Results: Second picture stays viewed on screen with its file removed Expected Results: The UI switches to Browse mode (or something else, but removes the deleted image from screen)
I can confirm the issue, and it is in fact more critical than it seems: In my case I had a folder with one image and several subfolders. I deleted the image in Gwenview; it stayed visible on the screen, but internally Gwenview had advanced to one of the subfolders. When I tried to delete the image again it deleted that folder instead (fortunately I had a backup). Steps to reproduce: - Prepare a folder with one image and one subdirectory - Open the image in Gwenview - Delete the image (Del or Shift-Del) - Gwenview silently advances to the folder. The only indication is that the Meta Information view in the top left corner changes to "1 folder selected". - Hit Delete again. Gwenview will delete the folder!
Git commit b55420b2ac3dc72ebffdb89dbb9e662d64950ecd by Valeriy Malov. Committed on 09/11/2017 at 14:52. Pushed by valeriymalov into branch 'master'. Try to keep ContextManager in sync with viewed files in MainWindow Summary: ContextManager now is responsible for switching to the directory containing requested URL and selecting it. However, if it is not possible, URL is still kept (in case of remote URLs), while selection is cleared (to avoid dragging in local files) MainWindow now relies on ContextManager's selection and/or selectedFileItemList instead of ThumbnailView selection. If selection & currentUrl are empty, refuse to open View tab, otherwise display selected items. This should prevent (reduce?) the amount of mismatches between which files user sees, and which files are being operated upon (e.g. by FileOpsContextManagerItem) Related: bug 355493, bug 275807, bug 306835 Test Plan: Tried playing around to make sure it doesn't break any old behaviour Tried deleting all image files while in View mode, to make sure we back out when we run out of images Tried opening an http url and check that operations apply to it unless we select something in browse tab And then remote image should be unloaded from the View tab since our actions will now affect user-selected items Tests pass but they don't seem to cover this? Reviewers: #kde_applications, gateau, rkflx Reviewed By: gateau, rkflx Subscribers: ngraham, rkflx, gateau Differential Revision: https://phabricator.kde.org/D8196 M +1 -11 app/fileopscontextmanageritem.cpp M +27 -70 app/mainwindow.cpp M +25 -2 lib/contextmanager.cpp M +1 -0 lib/contextmanager.h https://commits.kde.org/gwenview/b55420b2ac3dc72ebffdb89dbb9e662d64950ecd