Version: 2.6 (using KDE 4.6.4) OS: Linux Selected pictures remains selected after leaving to "Start Page" and it is possible to work with them as usual even if you can not see it. This is quite dangerous especially in combination with moving into trash with no confirmation. This situation is described in steps to reproduce. Precondition: No confirmation is required for movind into Trash (default in KDE nowadays). Create a copy of folder with pictures. Reproducible: Always Steps to Reproduce: * Navigate into the folder you created according to precondition. * Select all pictures. * Leave to Start Page, no matter if you use "Esc" key or "Start Page" button from Menu. * Hit "Delete" key Actual Results: All previously selected pictures are moved into Trash (and you did NOT see it!). Expected Results: Pictures HAS BEEN DESELECED as you entered "Start Page" and therefore no action is taken. OS: Linux (i686) release 2.6.38-8-generic Compiler: cc
I am able to reproduce this. I might accidentally delete files. Other functions like Rename, Copy to, Move to also work. On going to start page, the file should be deselected.
Thank you for the feedback.
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 326190, 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