Bug 161017 - enqueue kio transfer operations
Summary: enqueue kio transfer operations
Status: CONFIRMED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: VHI wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 178987 204907 205200 210857 223994 259512 309673 311588 362321 388291 462543 466706 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-19 15:33 UTC by Vedran Furač
Modified: 2024-09-08 20:53 UTC (History)
27 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vedran Furač 2008-04-19 15:33:23 UTC
Version:            (using Devel)
Installed from:    Compiled sources

Currently all new transfers starts parallel and that can't be changed.
It would be great to add option to put them in queue so that there is always only one active operation. You should also add ability to move files up and down in queue or remove them.
Comment 1 David Faure 2008-04-21 18:57:45 UTC
This is what KGet is for -- if you mean from a user's point of view. Or did you mean from a programmer-using-KIO point of view?
Comment 2 Vedran Furač 2008-04-22 01:15:39 UTC
Well... from user's point of view (or both), but this has nothing with kget which is only a simple download manager. Users want to be able to queue all KIO operations, like local file copying for example. Currently every new operation start immediately and there should be option to queue it so that it starts only after previously started operation is finished.

This is also the most wanted feature of krusader (http://krusader.org/todo.php), but krusader is not the only kde app that would benefit from this feature.
Comment 3 FiNeX 2009-08-23 21:12:03 UTC
*** Bug 178987 has been marked as a duplicate of this bug. ***
Comment 4 FiNeX 2009-08-23 21:12:07 UTC
*** Bug 204907 has been marked as a duplicate of this bug. ***
Comment 5 FiNeX 2009-08-23 21:16:57 UTC
It is not a bad idea. It could be very useful when you've to copy a lot of files to an external drive. You start the copy of a set of files, after, while it is still copying, you start the copy of another set and maybe you could start a third set. Queueing the transfers could be better.

Two objections could be:
1) Why I should start the second transfer before the first has been completed? For example when I've to start the copy and go away. 

2) Why not select all the files before and after start the copy of the whole set? I could have to select only some files from different sub directories.

IMHO this feature could be very useful.
Comment 6 FiNeX 2009-08-23 21:18:23 UTC
Implementing this feature will automatically fix this bug #124454 (wish).
Comment 7 Dominic Battre 2010-04-11 23:16:06 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Frank Reininghaus 2012-11-23 15:23:23 UTC
*** Bug 210857 has been marked as a duplicate of this bug. ***
Comment 9 Frank Reininghaus 2012-11-23 15:24:29 UTC
*** Bug 309673 has been marked as a duplicate of this bug. ***
Comment 10 omeringen 2012-11-28 21:11:17 UTC
Any news about this feature request ?
Comment 11 Christoph Feck 2013-01-12 15:54:56 UTC
*** Bug 311588 has been marked as a duplicate of this bug. ***
Comment 12 m.wege 2013-01-23 12:32:45 UTC
I filled a similar wish:
https://bugs.kde.org/show_bug.cgi?id=233902

 First posted at KDE-Brainstorm: http://forum.kde.org/brainstorm.php#idea86138_page1 I want to suggest a better way how to improve the possibilities for the user to handle file operations. Problems are not only the display in notifications, but mainly the way they are handled, problems are handled with or the user can interfere with the ongoing operations. The solution I would call "File operations queue" which would be similar to a printer queue (not the one of KDE4, which is still not very mature). With the file operations queue there would be - only one notifications item showing details only by device or operation type - the user then could open the file operations window which allows a detailed view and manipulation - Similar to a printer queue, the file operations queue collects all file operations (copy, move, delete, downloads) - All operations have (automatically) assigned priorities to prevents too many operations on the same device and/or at the same time - It is possible to manually change of priorities, delete tasks or part of a task (like deletion or copying of a file from the queue - There is a kind of record keeping so that there is limited undo functionality - The user can predefine priorities by file-type, device, operation type (e.g. delete) - The file operations queue saved through session management. Tasks can be continued after reboot. - When the user shuts down the system, he is offered to shut down after the tasks are finished or to shut down immediately. - The user can define a total amount of system resources for file operations, so that he can still work during large file copy operations if he has a slow system. - File operations which failed (e.g. copying or downloads which could not be finished because there was not enough disc space) can be resumed, the system offers the user also a a solution (start of disc sweeper) - There could be plug-ins for operations should be repeated on a certain date/time (backup, up/download, synchronizing) or on a defined event (plug-in of a external harddrive) finish other tasks while interaction is required when possible:) I want to suggest a better way how to improve the possibilities for the user to handle file operations. Problems are not only the display in notifications, but mainly the way they are handled, problems are handled with or the user can interfere with the ongoing operations. The solution I would call "File operations queue" which would be similar to a printer queue (not the one of KDE4, which is still not very mature). With the file operations queue there would be - only one notifications item showing details only by device or operation type - the user then could open the file operations window which allows a detailed view and manipulation - Similar to a printer queue, the file operations queue collects all file operations (copy, move, delete, downloads) - All operations have (automatically) assigned priorities to prevents too many operations on the same device and/or at the same time - It is possible to manually change of priorities, delete tasks or part of a task (like deletion or copying of a file from the queue - There is a kind of record keeping so that there is limited undo functionality - The user can predefine priorities by file-type, device, operation type (e.g. delete) - The file operations queue saved through session management. Tasks can be continued after reboot. - When the user shuts down the system, he is offered to shut down after the tasks are finished or to shut down immediately. - The user can define a total amount of system resources for file operations, so that he can still work during large file copy operations if he has a slow system. - File operations which failed (e.g. copying or downloads which could not be finished because there was not enough disc space) can be resumed, the system offers the user also a a solution (start of disc sweeper) - There could be plug-ins for operations should be repeated on a certain date/time (backup, up/download, synchronizing) or on a defined event (plug-in of a external harddrive) finish other tasks while interaction is required when possible:) I want to suggest a better way how to improve the possibilities for the user to handle file operations. Problems are not only the display in notifications, but mainly the way they are handled, problems are handled with or the user can interfere with the ongoing operations. The solution I would call "File operations queue" which would be similar to a printer queue (not the one of KDE4, which is still not very mature). With the file operations queue there would be - only one notifications item showing details only by device or operation type - the user then could open the file operations window which allows a detailed view and manipulation - Similar to a printer queue, the file operations queue collects all file operations (copy, move, delete, downloads) - All operations have (automatically) assigned priorities to prevents too many operations on the same device and/or at the same time - It is possible to manually change of priorities, delete tasks or part of a task (like deletion or copying of a file from the queue - There is a kind of record keeping so that there is limited undo functionality - The user can predefine priorities by file-type, device, operation type (e.g. delete) - The file operations queue saved through session management. Tasks can be continued after reboot. - When the user shuts down the system, he is offered to shut down after the tasks are finished or to shut down immediately. - The user can define a total amount of system resources for file operations, so that he can still work during large file copy operations if he has a slow system. - File operations which failed (e.g. copying or downloads which could not be finished because there was not enough disc space) can be resumed, the system offers the user also a a solution (start of disc sweeper) - There could be plug-ins for operations should be repeated on a certain date/time (backup, up/download, synchronizing) or on a defined event (plug-in of a external harddrive) finish other tasks while interaction is required when possible:)
Comment 13 BRULE Herman 2013-02-12 18:29:13 UTC
Ultracopier do it, but need integration into KDE.
Comment 14 omeringen 2013-05-31 19:13:13 UTC
Is someone working on implementing this feature ? Any new ideas or todo list ?
Comment 15 BRULE Herman 2013-06-02 23:19:03 UTC
Me, I'm looking implement it into Ultracopier/Supercopier.
Comment 16 Christoph Feck 2013-12-15 01:19:39 UTC
*** Bug 259512 has been marked as a duplicate of this bug. ***
Comment 17 Christoph Feck 2013-12-15 01:20:16 UTC
*** Bug 205200 has been marked as a duplicate of this bug. ***
Comment 18 omeringen 2014-01-11 15:26:12 UTC
I e-mailed to the Cyril Oblikov because i couldn't find any info about enqueueing kio transfer operations at his blog but there is no answer.
Is somebody working on this bug ?
Comment 19 Patrick 2014-01-11 17:47:40 UTC
Please note that it has been implemented in Krusader. The starting point might be to have a look at how it's done there.
Comment 20 omeringen 2014-01-12 16:49:04 UTC
@ Patrick,
Yes but i asked David about the progress of this bug and he said that Cyril is working on it so i e-mailed him. As i said, no response from Cyril . . . :(
Comment 21 BRULE Herman 2014-01-12 23:58:09 UTC
But we need more possible usage of external tools to prevent multiple same features into multiple software.
Comment 22 Christoph Feck 2016-04-27 10:42:24 UTC
*** Bug 362321 has been marked as a duplicate of this bug. ***
Comment 23 Christoph Feck 2018-01-10 02:43:36 UTC
*** Bug 388291 has been marked as a duplicate of this bug. ***
Comment 24 Nate Graham 2018-05-08 17:38:54 UTC
*** Bug 223994 has been marked as a duplicate of this bug. ***
Comment 25 Patrick Silva 2023-03-03 23:07:44 UTC
*** Bug 466706 has been marked as a duplicate of this bug. ***
Comment 26 Ahmed 2023-03-04 04:31:45 UTC
This request is so old.
Comment 27 lencho 2024-04-23 20:15:06 UTC
*** Bug 462543 has been marked as a duplicate of this bug. ***