Bug 125610 - Would like better management of long file transfers in konqueror
Summary: Would like better management of long file transfers in konqueror
Status: RESOLVED INTENTIONAL
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-15 00:47 UTC by Luke
Modified: 2009-08-27 13:33 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2006-04-15 00:47:06 UTC
Version:           3.5.2 (using KDE 3.5.2, Kubuntu Package 4:3.5.2-0ubuntu1 dapper)
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.15-20-686

I frequently spend time sending long lists of files to other machines via fish or to relatively slow usb storage devices. I typically want to send many files from many different places, but each drag-drop I do will start a new copy window with all running in parallel. I would rather be able to just keep queuing transfers into the same window as well as be able to see which files have been sent and which have been queued, as well as rearrange the queue to give certain files priority. (This may not be konqueror's job at all, but I'm not sure, so I'm posting here)

Basically any time I start a copy, rather than opening a new copy window, konq should check to see whether there is already a session open to the machine or device in question and refrain from running parallel transfers.
Comment 1 Thiago Macieira 2006-04-17 12:50:49 UTC
You want KGet. And if it doesn't implement that feature you want, you can request it.

But this is not suitable for Konqueror.
Comment 2 bonne 2006-12-03 07:44:43 UTC
I disagree. 

This could be a bumper feature for konqueror. 

If you want to copy a bunch of files of a CD to your desktop, but you can't select them all in one go, then you currently have two options:
1. Wait for the copy to finish to copy the next lot
2. Copy both simultaneously at 1/10th the speed because the laser zips back and forth.

If you could have a copy queue you could tell the second group of files to begin copying after the first lot was finished. 

This simple feature could actually be used for many different things. 
Comment 3 Thorsten 2008-04-21 16:16:53 UTC
In my opinion it should be implimented in konqueror. I had the same problem while I copied many large files from one external hdd to another. I don't want to fragment the files to much, so I had to wait before I can start new filetransfers... The Bug sould be reopened.
Comment 4 Dotan Cohen 2008-06-29 23:38:44 UTC
I also agree that this bug should be reopened. Konqueror is handling the transfers in a bad way. So what if another program handles them in a good way, that does not mean that Konqueror does not have to. KGet advertises itself as a way to transfer files over the internet, or more specifically, to download them from remote machines to local. I would never think to use KGet to copy files from a CD. Thiago, do you object to reopening this bug, possibly against Dolphin instead of Konqueror?
Comment 5 Dotan Cohen 2009-08-27 13:33:54 UTC
See also related bug #205200.