Version: (using KDE 4.3.2) Compiler: gcc 4.4 OS: Linux Installed from: Ubuntu Packages New behavior in dolphin resulted in me permanently losing valuable data that I have no way of recovering. I had data on a USB disk that I copied over to my hard disk. A window popped up saying the transfer had 0 seconds remaining, which see med a little fast, and then disappeared. In every other related application I've seen, this would mean that the transfer is over, but not with KDE 4.3.2! No, the transfer had barely just begun, and I did not pick up on the hints near the system tray that the transfer was still happening. Needless to say I then requested that the files be deleted. As far as i can tell both commands were executed simultaneously, resulting in more than half of the actual data being lost. This has been by far my worst experience with KDE and possibly the worst mismatch I've had between my mental model of an application and what was actually happening, and the consequences ended up being devastating.
It seems like, if going to support asynchronous command processing with files, you should require the user to explicitly click on a button to background the task. For instance, in Eclipse when doing an update the action occurs in the foreground but you can choose to background it with a single mouse click if you want. I have never seen file manipulation tasks backgrounded in a file explorer program and certainly didn't expect it based on the visual cues I was getting from dolphin, especially the since the estimated transfer time was 0 seconds.
That would be a bug in the Plasma notifications (about the file transfer). Sorry about the data loss... So far, I think that the notifications of file operations were modified a bit, hopefully avoiding situations like this. Reassigning
I am very much against the "auto hiding" of the job progress notification in plasma too. It's very confusing and unexpected.
there is an always-visible progress notification now.