Version: unspecified (using KDE 4.5.3) OS: Linux When you right-click a file in Dolphin (or Konqueror, etc.), you can use the Copy-To/Move-To menus to copy or move a file to a directory. When you go through a directory structure in those menus, the whole app blocks on each directory access. This might not often be a problem, but if you mouse over a directory in the menu that has many files in it (or is over a slow or broken network link, or is an encrypted filesystem that loads directories slowly, like eCryptfs), you can't do anything in the app until the directory finishes reading. This is especially frustrating if you accidentally mouse over a directory that is VERY SLOW to load, because you have to wait until the directory finishes loading before you can do ANYTHING, like go to the directory you meant to go to, or just choose one of the recent directories at the bottom. One time this happened to me--the cursor passed over a SLOWLY-loading directory as I was navigating the menu--and I had to wait several MINUTES before I could do what I originally intended to do. Reproducible: Always Expected Results: I'm not an expert programmer, but I suppose each directory-loading should be done in a separate thread, and if the user moves to another menu item, the thread should be terminated. However it's done, the UI should always be responsive, and the user shouldn't have to wait for the app to do something the user doesn't even want it to do.
@Adam: Thanks for the report. I fully agree that the directory loading should not block. BTW: The loading is done in a custom process already, however it seems that the UI is unnecessarily blocked. @David: Should I take care on this or do you want to check? I've not looked at the code yet, probably it is only a minor thing...
Actually the directory listing in KonqCopyToDirectoryMenu is not done in a separate process at the moment, it uses QDir, with a comment (from me) saying that it's faster that way, since KIO::listDir fetches much more information :-) One thing that worries me is that if the loading is made asynchronous, then the popup menu will populate by random bursts and items will move around (since the listing is not guaranteed to be done in alphabetical order), which can lead to confusion and clicking on the wrong item... OK I guess this means the right solution is to show the menu with "Loading...." until all items are available, and then to show them all in one go (or to kill the listing if closing the menu before). This sounds like a job for me indeed.
"This sounds like a job for me indeed." You sound like a superhero. How inspiring. :)
Using Kubuntu 11.10, KDE 4.8, Dolphin 2.0. I can't reproduce the bug, there is no such option as Copy-To/Move-To, there is a simple Copy/Move. I think that this bug is invalid. And I suppose that Adam was navigating through a "Details View" mode which in Dolphin 2.0 doesn't show the content if you don't press manually to show it.
> --- Comment #4 from Lilian A. Moraru <moraru69 yahoo com> 2012-02-27 17:23:56 --- > Using Kubuntu 11.10, KDE 4.8, Dolphin 2.0. I can't reproduce the bug, there is > no such option as Copy-To/Move-To, there is a simple Copy/Move. I think that > this bug is invalid. And I suppose that Adam was navigating through a "Details > View" mode which in Dolphin 2.0 doesn't show the content if you don't press > manually to show it. This bug is not invalid. Turn on the setting!
Created attachment 69157 [details] The setting
In my case it loads instantly but I have an i7 and an Ok HDD. Is the bug valid with 2.0, can you reproduce it?
Try this: Make an eCryptfs filesystem, mount it, touch a few thousand files into existence, and then navigate to it in the Copy-To menu--it won't load instantly on any system, or very rarely, because eCryptfs has to re-stat all the file metadata, which is I/O-bound (and head-seek bound), and therefore very slow. Look, the KDE developers, as they indicated earlier, have acknowledged the bug. The problem is the lack of threading in the code. The situation has not changed. The code has not changed. Therefore the bug still exists. Please just leave well enough alone until the code is actually rewritten. This is one of the problems in the FOSS community: 1) people take the time to file bugs 2) it takes a while to get fixed, which is understandable 3) some more releases happen before the bug is fixed 4) people without knowledge of the bug or the code in question, while trying to help, waste the reporters' time by pestering them, "Is the bug still there?" 5) If the reporter has better things to do than say, "Yes, of course the bug is still there--the bug is there until it's been fixed," someone takes it upon himself to close the bug report for lack of activity or re-confirmation 6) the bug never gets fixed. You've heard of Ubuntu's Papercuts project? Well this is like papercuts for bug reporters: After having heard enough of "is it still there? Is it still there?", they will stop taking the time to report bugs. Hey, the bug reporter isn't pestering the developers, so please don't pester the bug reporter.
Dolphin 2 has some core changes. I was hoping it solved your problem. I don't see anything bad in that...
The changes to the main view widget aren't relevant to the Copy-To/Move-To menu--that's not core functionality. (Besides, the new code has actually introduced several regressions, both in lack of feature parity and in actual brokenness.) I know you're trying to help. The "bad" part is when a reporter, like me, has to keep saying, "Yes, the bug is still there. No, really, it is. Did anyone work on it yet? No? Then it's still there. Honest!" Basically, I think that unless one has some evidence to suggest that a bug was addressed in an update, like specific knowledge of code that's been committed, one shouldn't ask reporters to verify that the bug is still there. Although it's not intended to be, it is almost rude. It's almost like saying, "Hey, I know you took the time to report this bug--and I know no one's specifically fixed it--but would you report it all over again? Just to make sure?" And the worst part is that, if the reporter doesn't notice or doesn't take the time to re-confirm the bug, there's a substantial risk the bug will be assumed to have been fixed, and go unnoticed and unfixed. I always look up to the way Debian handles bugs: even though a bug may go unfixed for years, no one is pestered to confirm that it's still there--it's assumed that unless it's been fixed, it still exists. Patience is what's expected, both on developers' and reporters' parts. I know your intentions are good, and the bugzilla needs people to help keep it tidy. But I do think that "discretion is the better part of valor"--better to do no harm first, than to potentially waste people's already-scarce free time and cause real bugs to be dismissed. I hope you understand what I mean. :)
Resetting assignee to default as per bug #305719