Bug 150547 - Progress Dialog + delay for cut/paste ops
Summary: Progress Dialog + delay for cut/paste ops
Status: RESOLVED WORKSFORME
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2007-10-06 22:38 UTC by dillonco
Modified: 2008-10-15 22:34 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 dillonco 2007-10-06 22:38:59 UTC
Version:            (using KDE KDE 3.5.7)
Installed from:    Gentoo Packages
Compiler:          gcc 4.1.2 
OS:                Linux

When cutting and pasting files within the same filesystem, Konqueror brings up the progress dialog.  This(?) leads to a delay of about 8 seconds, which makes sorting files extremely tedious.

I believe this is a bug because dragging and dropping (with move) and copy and paste do not have this problem.  Using Undo to revert the move is also ok.

The test files are are small (<50k), and the folders are on the same volume (local hd, ext3), and nothing is being accessed through kio.
Comment 1 Frank Reininghaus 2008-09-29 20:34:17 UTC
Can this still be reproduced in a more recent version of KDE? And if yes, how many files do you cut and paste in one step? I moved 7 small files in 3.5.10 and 4.1.1 (Kubuntu) and could not notice any delay.
Comment 2 dillonco 2008-10-06 21:02:38 UTC
The version I'm currently using is 2.5.9 and it still has the problem.  The bug doesn't show up all the time and seems to be linked to a specific "session" (folder view) in Konqueror.  For example, I just moved a file and did not get the box (repeatably), but after I changed the directory the box appeared consistently.

The bug also seems progressive.  While I was running my tests, the when box popped up it only took a short time.  Now, it's freezing for almost 10 seconds.  Then I opened a new tab and it dropped back down to under a second.

Finally, it would seem that changing the view type (detailed -> icon) eliminates the problem for a little while.
Comment 3 Jaime Torres 2008-10-12 11:11:23 UTC
While in dolphin 4.1.68 the Ctrl-X,Ctrl-C and Ctrl-V works, in konqueror 4.1.68 they do not. Therefore I've not tested the reported bug (about delays caused by the dialogs).
Comment 4 Frank Reininghaus 2008-10-12 21:31:52 UTC
comment 2: Thanks, but I'm still unable to reproduce...

comment 3: Jaime, Ctrl-C/X/V work fine for me in Konqueror from trunk. Depending on how old your SVN checkout is, you might be experiencing bug 172014.
Comment 5 Jaime Torres 2008-10-13 12:03:54 UTC
With an updated konqueror, in a very slow machine (PII) I always get the progress dialog (copy and paste -work again- or drag and drop), but I not notice a big delay induced by it. It only takes 2 seconds to copy 6 files with a total 200k in this slow machine.
Comment 6 dillonco 2008-10-15 05:38:28 UTC
Please note that this bug is not about copying, but moving within the same partition.  Since the only things that need to change are directory entries, there is no need for the progress box for a small number of files.  KDE behaves properly in the drag and drop case, but for me the cut and paste stalls for 1-10 seconds before anything happens.

If I open up a directory and drag a file into a subdirectory (using "move"), it happens instantly.  If I instead cut the file and paste it into the subdirectory, the progress box appears, delays a couple seconds (at while point all instances of konqueror are frozen), then disappears.  During the 

It seems to be somehow related to my configuration, because another user account doesn't have the same problem.  One thought is that it's an encoding thing... I switched from 'C' to UTF-8 without changing my config dir.
Comment 7 Jaime Torres 2008-10-15 22:34:09 UTC
I've tried again to move files, and the dialog with the progress bar is also shown.
As far as I know, the dialog is shown when kdelibs think the operation will last more than x seconds. In my slow machine, allways.