Bug 257845 - Copy-To/Move-To menus block on directory reads
Summary: Copy-To/Move-To menus block on directory reads
Status: CONFIRMED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-25 08:00 UTC by Adam Porter
Modified: 2020-05-23 21:51 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
The setting (49.09 KB, image/png)
2012-02-28 05:58 UTC, Adam Porter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Porter 2010-11-25 08:00:19 UTC
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.
Comment 1 Peter Penz 2010-11-25 09:00:04 UTC
@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...
Comment 2 David Faure 2010-11-25 13:29:43 UTC
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.
Comment 3 Adam Porter 2010-11-26 04:59:42 UTC
"This sounds like a job for me indeed."

You sound like a superhero.  How inspiring.  :)
Comment 4 Lilian A. Moraru 2012-02-27 17:23:56 UTC
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 5 Adam Porter 2012-02-28 05:57:35 UTC
> --- 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!
Comment 6 Adam Porter 2012-02-28 05:58:40 UTC
Created attachment 69157 [details]
The setting
Comment 7 Lilian A. Moraru 2012-02-28 07:15:19 UTC
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?
Comment 8 Adam Porter 2012-02-29 15:07:15 UTC
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.
Comment 9 Lilian A. Moraru 2012-02-29 17:54:40 UTC
Dolphin 2 has some core changes. I was hoping it solved your problem. I don't see anything bad in that...
Comment 10 Adam Porter 2012-02-29 21:17:11 UTC
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.  :)
Comment 11 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:19:41 UTC
Resetting assignee to default as per bug #305719