7

I am actually not sure if that is a good idea...

Don't get me wrong, I understand your point about queuing transfer jobs and I agree that often it is wise to do so.

However we should also consider that Dolphin is a file manager.
Sure, it works network transparent because it is based on the KDE framework. But it's main focus is local work, that has highest priority and should receive primary attention.
The issue with implementing additional hassles and whistles for each and every thing one can actually do with such a tool is: it gets more and more complex. Higher complexity means reduced robustness, higher maintenance effort, thus fewer changes getting implemented, higher loading times dues to increasing sizes and and and .
I am not sure if this is a good idea for these reasons.

I do like the idea of being able to use dolphin for networking stuff, but for "heavy duty jobs" I prefer a specialized utility. Which in turn allows the general tool to stay lean.

Just my 2 cents...

Well, the queue feature is already there. This is just an enhancement to that feature to use a single queue for a given network device rather than creating a new queue for each operation being performed. This would probably lead to a more robust feature as depending on the network protocol running multiple operations simultaneously would lead to increased contention and possibly instability.

Maybe don't make it automatically - user may choose.
For example, when dragging file, it have another option add to queue or copy/move after/before. When clicking copy/move after/before, dialog will appear. User can use this dialog to manage order of transfer, add new queue, remove it, move transfer between queue, etc.
Another thing to do in this dialog is error handling - shouldn't transfer of other files stop, when an error occurs?

I too would welcome a way to queue transfers.

Rather than having to make a manual choice each time, I'd like a global dolphin setting "queue multiple move/copy operations to the same destination disk" so that the first transfer job starts immediately, and all following ones start when the previous one is done.

Even better: a file-based queue, not a transfer job based one. So if I copy 10 large files, there is now a queue window with 10 entries. The first one is running, the next nine are paused. If I immediately copy another 10, the transfer queue now has 20 entries. When each entry finishes, the next one begins. The queue window allows re-ordering of file transfers via drag and drop and control over individual files.

Basically, it would work like a download manager, with the usual functionality for queuing, starting, pausing, resuming and prioritizing downloads.

Bonus: a checkbox to give the option to verify that files were transferred correctly, with md5 or sha-1 checksums.

This function has already been available in Krusader. However, I prefer managing files with Dolphin, and use Krusader whenever I need to transfer files with queue such that hard disk copying does not slow down do to multiple transfers at a time.

I'd like to add to this topic that Nemo has a transfer queue with autostarts.

I'd still love to have this feature in Dolphin. It happens frequently that I start coping some large files, and after the transfer started, I realize that there are a few more large files to transfer. With the current Dolphin, I have to pause subsequent transfers, and then manually start them when previous ones have finished. That means I have to stay at my machine or come back at just the right time; unattended copying isn't possible.

Agree we need to be able to queue transfers.