Wow! I still feel like I started using Opus sometime this year, I didn't realize that much time passed already! 
They say time passes faster the older you get, but I'm not that old yet (I think)... 
I still hope for some more improvements regarding content refresh speed upon deletion, for me this is the only regular user-experience let-down when using Opus.
We'll keep an eye out to see if it is ever not instant for us, and investigate if we can see it. So far (since the thread was resurrected) we haven't seen any delays between deleting things in Opus and them being removed from the lister.
That only leaves us with the option of trying random things to see if it helps solve or diagnose what's happening on other systems, but that won't work if there's no feedback for a year and a half after making the change. 
If you can think of anything for us to try, we'd be happy to. (e.g. Deleting on certain types of drives, or similar.)
Yup, I'm pretty sure the two step deletion thing is still going on. More pronounced on networked drives, but still present on local drives.
Quick test on a network drive:
lol. is this a video faceoff? I'm out. 
It's an intermittent phenomenon in my experience. I can remember it occurring within the last two weeks. If I get a spare moment, I'll try & recreate the situation sans video.
Ok, just tested it on a local drive with a ~30 files and observed the two step deletion.
Also did it on a networked drive and observed the same.
ps. like your cat censors!
I was about to make a thread with this exact request! Glad to see I'm not the only one who's bothered by this.
I was thinking it could be implemented in such a way that , to give the illusion that the deletion is instant, the files (well, the icons) could be immediately hidden from the file view/lister, while the files are being deleted "in the background"?
That would definitely be a psychovisual improvement
Or, perhaps, the "delete" command performs the following function:
I'm not sure but as far as I can remember move operation is also affected by this issue. This makes sense as move is the same as copy+delete for particular file. Unfortunately, I tried to test this a second ago and was unable to reproduce content refresh speed delay. I will try it later.
I think your first idea (the illusion) is very similar to the one I already suggested:
[quote="daroc"]I think that even if OS doesn't provide information on file changes quick enough, it should affect only external changes, not those made by DOpus. If I operate on files with DOpus, I'm pretty sure it knows whether a file has been deleted/moved successfully or not. And if yes, it should remove it from display immediately.
Or at least immediately after move/delete operation is completely finished (eg all selected files were deleted), if refreshing display after each file is deleted might affect performance.[/quote]
Moving files to subfolder before delete might severely affect performance (I just thought about FTP sites, but I'm not sure if they are also affected by this issue; will try to test it later). Imagine what would happen if you moved files to a subfolder and then an error occurred. And then, if DOpus tries to move them back to original folder, it turns out that another application already created files with same names so it's impossible to get back to the original state.
Anyway, before any kind of hiding files, DOpus has to be completely sure that the item it is hiding is really deleted.
I'm trying to do some tests with FTP, which might give you much information on where this issue come from, if test will confirm FTP sites are also affected.
I don't know how it works by design (maybe DOpus intentionally doesn't refresh listers too quickly due to performance reasons or just to prevent "flickering" of files in displays) but I will describe what I see when copying files to sFTP and deleting files from it.
I tried to copy 10 very small txt files (1 or 2 bytes each) to sFTP site. Each file is copied about 0.3 second. Files didn't appear in remote folder lister immediately after they were copied (one by one) but appeared in two or three turns. Eg. 5 files in first turn and the other 5 files in second turn. Or 1 file in first turn, 6 files in second turn and then 3 files in third turn.
When deleting files on sFTP it was very similar (progress bar showed files were deleted at constant speed while files didn't disappear in equal periods).
It looks like DOpus didn't refresh lister very frequently but rather did it each 0.5 - 1 second, regardless of when files are deleted. Say, lister is refreshed at (time) 09:44:00, 09:44:01, 09:44:02 etc. so if it's 09:44:00 and DOpus made it to delete only one file in that very second, only one file disappears from file display at 09:44:01.
FTP is handled quite differently to local folders. Looking at both at once will probably just confuse things.
Also, what happens while the progress dialog is still on screen isn't what Jon or I were talking about, at least. The aim is to make everything update quickly once the operation is complete; i.e. once all the files have been deleted, the file display will then update quickly to show the end result. While the files are still being deleted, it will only update about once a second, batching up events in-between to process as a batch, since updating for every single file would slow things down massively in some situations (e.g. deleting thousands of files in the folder you are viewing). (It also means the file display is more usable while operations are ongoing, since the file list isn't jumping around many times a second.)
The change added a year and a half ago was to make the file display process all pending change events as soon as the operation completes, rather than waiting an extra second as it does while the operation is ongoing, or while no operations are active and something else is changing the files.
(From memory, it also only affects the file display that launched the operation.)
I replaced the native delete command with this to circument the slow deletion:
copy move to {filepath|\}XXXrecycle"
It's instant! The only downside with this is that now I have a "recycle bin" on each partition. But I'm gonna make a script that moves files from XXXrecycle to the real recycle bin when I'm idle.
That's odd since the rename events should be processed just the same as the delete (or rename-into-recycle-bin if using it) events.
Maybe my system is slower at deleting for whatever reason... anyhow the difference is noticeable, especially when deleting in thumbnail mode.
@skribb
Your solution doesn't work for me. Files don't disappear immediately after operation is completed. For the purpose of testing, I disabled delayed progress indicator, so I know exactly when delete operation is completed. I tried to use this button to move 10 files. Some of them disappeared from file display right after progress bar window closed. The rest of files disappeared after about one second.
I don't know if that matters but if I delete files or move them and then hit Ctrl+Z to undo the operation, files also don't appear in the lister immediately, but (usually) in two turns. So it's not only disappearing problem. It also takes place when files appear.
I tweaked the scriptlet(?). This is what I'm using:
copy move WHENEXISTS=rename to "{filepath|\}XXXrecycle"
I replaced the original Delete command in Dopus with the above. So when I select "delete", it moves to root\XXXrecycle. But, you have to create the XXXrecycle folder first.
On my system at least, moving files to the same drive is instant, while deleting permanently or to recycle bin takes 1-5 seconds, and in thumbnail mode it can take a really long time if a large number of files is selected.
Also I'm using 10.5.2 x64 if that makes a difference. The only problem I've encountered is that a few times there was an error message, even though the files were moved correctly. I don't know why that is tho.
Additionally, I made a Autohotkey script that moves all contents from all the XXXrecycle folders into the real recycle bin once per hour, so I can survey if I've deleted something I needed before I empty the recycle bin.
Surely doing that is going to cause more problems than it is worth to not have to wait half a second for the file display to update after deleting several files?
Statistically, definitely! haha.
But I'm a real stickler when it comes to UX, everything has to be snappy or I'm annoyed 
So far it works good, apart from that weird error message. I was wondering if you had an idea why it pops up? It only appears, maybe 10% of the files I've test deleted. could it be the way Dopus or the file operation parses the path names?
Totally understand if you don't wanna bother assisting me in my experiments btw 
(it would be nice to have an edit function in the forum)
The error message appears seemingly randomly when i "delete" more than one file at a time.