Add optional queued file operations for copy/move tasks

Brainstorm
1

Feature Request: Copy Queue for Dolphin File Manager

Description:

I would like to request an optional copy/move queue system for Dolphin, similar to what file managers like Krusader or Nemo provide.

Current behavior:
When starting multiple copy or move operations in Dolphin, they run simultaneously.

Suggested behavior:
If a copy/move operation is already running, Dolphin could offer options like:

  • Start immediately

  • Add to queue

  • Cancel

Queued operations would automatically start after the currently active operation has finished.

Benefits:

  • Reduced disk thrashing and random I/O

  • Better SSD/HDD performance during large transfers

  • Faster completion time for multiple large copy jobs

  • Lower system load

  • More predictable transfer behavior

This is especially useful when:

  • copying large media files

  • working with many SSD/HDD targets

  • handling backup workflows

  • moving video production or event data

Krusader and Nemo already implement similar workflows successfully.

Possible implementation ideas:

  • optional queue toggle in settings

  • queue management panel

  • drag & drop into queue

  • pause/reorder queued tasks

System information:

Operating System: Manjaro Linux
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.26.0
Qt Version: 6.11.0
Kernel Version: 6.18.28-2-MANJARO (64-bit)
Graphics Platform: Wayland
Dolphin Version: 26.04.1

Hardware:

  • Intel Core i7-6820HQ

  • 32 GB RAM

  • Lenovo ThinkPad P50

Thank you for your work on Dolphin and KDE.

1 Like
2

I feel like adding files to the queue should be the default option for any copy actions that would act on a HDD that is currently involved in a copy already, as there’s almost no circumstance where you would want to have a HDD trying to do two at once.

Perhaps there’s some better logic based on hardware, or just allowing a manual pop up, or context menu options to force the use of a queue. It’s incredibly frustrating that there’s no queue for copies, and I’d prefer not to need to use a different app to achieve it when Dolphin is otherwise ideal!

3

This has been reported for a long while https://bugs.kde.org/show_bug.cgi?id=161017

This is a big task given our architectures (we don’t just handle local files) and many edge-cases.

Something that will be done someday™ probably.
Until somehow with the time and deep KIO knowledge comes along.

4

Subject: Proposal: Optional disk-destination-based file operation queuing in KIO Scheduler

Hi @meven

I have been analyzing the feasibility of implementing optional queued file operations for copy/move tasks (a feature frequently requested by users, as discussed in this thread).

While clients like Krusader manage manual queues at the application level, I believe implementing this at the backend level inside KIO would be much more robust, elegant, and beneficial for the entire KDE ecosystem (Dolphin, Plasma desktop, Ark, etc.).

I would love to get your feedback on the following implementation approach before diving deeper into the code:

Core Concept

Instead of a single global queue that could bottleneck independent transfers, the queuing logic would be per destination disk/device. When a user triggers a copy/move operation, they can choose between the current behavior (“Paste / Immediate”) or a new option: “Paste in Queue” (Enqueue).

Proposed Architecture Breakdown

  1. KIO::Job Extension:

    • Add a flag/property to KIO::Job (e.g., setQueued(bool)) via JobPrivate to mark whether the job should be execution-deferred or immediate.

  2. KIO::Scheduler Modifications (scheduler.cpp):

    • Introduce an internal device tracking mechanism using QStorageInfo on the destination URL (job->destUrl().toLocalFile()).

    • Maintain a map of deferred jobs indexed by storage device IDs: QMap<QString, QList<KIO::Job*>> m_perDiskFileQueues.

    • When a job marked as queued is registered, the Scheduler checks if there is already an active job running for that specific diskId. If so, it holds the job in the queue instead of assigning a Worker immediately.

    • Connect to the job’s result() signal. Once the active job finishes (successfully or with an error), the Scheduler pops the next job from that specific disk’s queue and starts it.

  3. UI and Error Handling Integration:

    • Notifications: To avoid cluttering the Plasma Notification area, queued jobs would remain hidden or in a “Pending” state until the Scheduler activates them. Only the currently running job for that disk shows a progress bar.

    • Interactivity / Errors: Since the job lifecycle is preserved, standard KIO error handling and interaction delegates (JobUiDelegate) remain untouched. If a queued job starts and encounters a conflict (e.g., file already exists, source missing, or out of space), the standard prompt will block that specific job until user resolution, naturally pausing that disk’s queue.

Future-Proofing (Phase 2):

Eventually, KIO::Scheduler could expose the state of these queues via DBus or an abstract model, allowing Dolphin or Plasma to implement a “Queue Manager” UI (similar to a print spooler) where users can view, reorder, or cancel pending jobs.

Do you think this architectural approach aligns with KIO’s design principles? Would a Merge Request implementing this intelligent, per-disk scheduling be welcomed, or do you foresee any blockers regarding DBus synchronization or thread safety within the Scheduler?

Thanks for your time and guidance!

Also as my main language is java, would it be a no go to try AI assistance in coding this? if I try to make little changes y may not result in bad code.

5

Do you think this architectural approach aligns with KIO’s design principles? Would a Merge Request implementing this intelligent, per-disk scheduling be welcomed, or do you foresee any blockers regarding DBus synchronization or thread safety within the Scheduler?

KIO::Job Extension not really necessary, all operations are in effect queued, they can be paused or stopped or killed already.

KIO::Scheduler Modifications, we’d probably wouldn’t use QStorageInfo as it is simplistic. We have KMountPoint with mount_id are probably more suitable (per-subvolume…), stay non-blocking (a USB stick is very slow, a network mount can be unresponsive…). And KIO does not just write to filesystems, but also KIO protocols smb:// nfs://, we want to support those per-host.

Maintain a map of deferred jobs indexed by storage device IDs that part is obvious.

I don’t think we need to surface the queue by default, any file operation that lasts than 5 seconds is also cheap to undo, so pre-pausing jobs is not necessary or it should be explicit upon copying or because the drive the file-operation is already busy with another job.
This is only relevant for long copy operations (or deletion) really.

This could even hurt performance on SSD when copying small files, since those are better at random writes than sequential, so we might need more logic in the scheduler to actually take into account the drive kind and its activity and even the job work load.

Eventually, KIO::Scheduler could expose the state of these queues via DBus or an abstract model, allowing Dolphin or Plasma to implement a “Queue Manager” UI (similar to a print spooler) where users can view, reorder, or cancel pending jobs.

We already have a way to expose file operations on DBus. Mainly in kjobwidgets.
You can see an example how I did it in applets/notifications: show a speed graph for file operations (!4851) · Merge requests · Plasma / Plasma Workspace · GitLab and its dependencies.

Also as my main language is java, would it be a no go to try AI assistance in coding this? if I try to make little changes y may not result in bad code.

It would be ok-ish, Cpp is mainly a OO like Java, it just add pointers and heap and a different API, but you should be able to code in it with an LLM. I think it would be valuable to you to learn a little cpp along the way, it can make you better at Java because even though Java abstracts those notions they will appear in Java too when aiming at performance. Abstractions leak. the LLM will likely do all the heavy lifting.
What matters is that you can logically follow it, and be able to review its logic and add validations, testing.

synchronization is a none-issue, it is already handled, file:/ operations are in separate threads already smb:// are in separate processes.

6

I’m aware no one asked me, but I’d like to add my 2 cents anyway, concerning the UX part:

When a user triggers a copy/move operation, they can choose between the current behavior (“Paste / Immediate”) or a new option: “Paste in Queue” (Enqueue).

I would not add this as an option for every operation, this would mostly introduce new dialogs and slow down current workflows. If there’s an option for this, it should be somewhere in the global settings, but I’m not actually sure if a setting is needed at all, since I feel the new queued processes would be a general upgrade in every case.

Or, one idea that just popped up while writing: when you get the notification that will tell you “your copy operation has been queued” the notification could offer an option to “start immediately in parallel”

1 Like
7

Are you working on it?

I’d provide a second pair of eyes, as I want this feature as well.

8

Not right now, I plan to but my work is a bit too demanding these days. If you want to start working on it go ahead, otherwise I’ll try once I have some more free time available.

1 Like
9

I have been working on low-level kio plumbing and more is coming.
No need to rush or start of my work if possible. file: add a batch-copy command to the file worker (!2282) · Merge requests · Frameworks / KIO · GitLab