Whenever I delete files I have to wait until the files are delete before I can continue browsing.
While it may not seem much of an issue having to wait 1 second to delete a single picture, it becomes a real time factor if you`re browsing through 2000 pictures to find 10 you like then you get almost 2000 seconds waiting for files to be deleted.
I`m using full screen mode so tagging would not work right?
Proposal 1:
Deletion as a background task:
XnView would schedule the files for deletion and the user can continue while the deletion takes place in the background.
Proposal 2 ( with extra benfits
):Pressing delete would not move the selected files to the OS` trash but to a trash-folder within XnView.
This trash-folder would be a meta-folder:
For the operating system the files would still be stored as normal but XnView would present them in a trash-folder (with a trashcan symbol).
"Deleting" files then would not move them to the OS` trash but XnView would add them to a data base`s list.
Psysically the files remain where they are until XnView`s trash-folder is cleaned.
So before finally deleting them the user could take a last look on everything in that trash-folder. Browsing the OS` trashcan is not possible so that would be a little extra-feature.
It would also allow to optionally display those files in the folders where the system has them stored but with a symbol (trashcan) that indicates those files will be deleted when emptying XnView`s trash-folder.
Finally, I suppose/hope, that would also solve the initial issue I had: The responsiveness.
I think that could be organized in a way that this virtual deletion process (adding the info that the file is to be deleted to a database instead of physically deleting them) is instantaneous. XnView would feel a lot faster and when deleting a great number of files in a session then it certainly would amount to a several minutes of saved time.