Version: 1.2.1 (using 4.2.4 (KDE 4.2.4), 4.2.4-2.fc11 Fedora) Compiler: gcc OS: Linux (x86_64) release 2.6.29.5-191.fc11.x86_64 When deleting a lot of files dolphin blocks (interface reacts to no mouse clicks) until all files are removed. I think deleting files should be handled in another process/thread (even very old versions of crappy windows explore does this).
Thanks for the report. The delete operation is done by another process, so the blocking has a different root cause: a) Did you delete the files by "Move to Trash" or by "Delete"? b) Did you enable the Information Panel of Dolphin? c) Did you select one folder and deleted it, or did you open the folder, selected all files and deleted them? d) Do you have enabled Nepomuk/Strigi on your system?
a) Delete b) The information side panel is open. c) A whole folder (dolphin is in detailed tree view, if this matters). d) Usually Nepomuk is enabled. However, I accidentally closed nepomuk (browsed dbus services and double clicked wrong method: nepomuks quit method). Strigi is not running, I think.
Thanks for the update! This seems to be related to an issue in the Information Panel...
I see this using KDE 4.3 RC2, even if only deleting a small single file. Nepomuk's cpu usage goes up right after the user acknowledged the delete. It does not happen, if nepomuk is disabled or the information panel hidden.
SVN commit 995015 by ppenz: Fixed performance issues related to selections and deleting of files: - Don't connect to KDirLister::itemDeleted(const KFileItem&), but KDirLister::itemsDeleted(const KFileItemList&). Otherwise Dolphin is informed about each single file deletion instead of getting the deleted items as a list. Thanks to David Faure for the hint! - DolphinViewContainer::updateStatusBar() can be expensive when a lot of files are selected, as the file size must get retrieved. Assure that fast calls for updateStatusBar() don't trigger a synchronous update, do the update after 300 ms where no further update has been triggered. - Dolphin provides a list of file items when emitting the selectionChanged() signal. Collecting the file items is a quite expensive operation, so use the same approach as when updating the statusbar: only emit the selection changed signal when no change has been done within 300 ms. This improves the performance when doing huge selections a lot. - Make updateStatusBar() a private method, the main window should not need to take care about updating the statusbar (this is done internally now by DolphinViewContainer). BUG: 199090 BUG: 195787 CCBUG: 199352 CCBUG: 188218 M +0 -2 dolphinmainwindow.cpp M +17 -2 dolphinview.cpp M +15 -0 dolphinview.h M +44 -28 dolphinviewcontainer.cpp M +16 -6 dolphinviewcontainer.h WebSVN link: http://websvn.kde.org/?view=rev&revision=995015
SVN commit 995018 by ppenz: Backport of SVN commit 995015: Fixed performance issues related to selections and deleting of files: - Don't connect to KDirLister::itemDeleted(const KFileItem&), but KDirLister::itemsDeleted(const KFileItemList&). Otherwise Dolphin is informed about each single file deletion instead of getting the deleted items as a list. Thanks to David Faure for the hint! - DolphinViewContainer::updateStatusBar() can be expensive when a lot of files are selected, as the file size must get retrieved. Assure that fast calls for updateStatusBar() don't trigger a synchronous update, do the update after 300 ms where no further update has been triggered. - Dolphin provides a list of file items when emitting the selectionChanged() signal. Collecting the file items is a quite expensive operation, so use the same approach as when updating the statusbar: only emit the selection changed signal when no change has been done within 300 ms. This improves the performance when doing huge selections a lot. - Make updateStatusBar() a private method, the main window should not need to take care about updating the statusbar (this is done internally now by DolphinViewContainer). CCBUG: 199090 CCBUG: 195787 CCBUG: 199352 CCBUG: 188218 M +0 -2 dolphinmainwindow.cpp M +17 -2 dolphinview.cpp M +15 -0 dolphinview.h M +44 -28 dolphinviewcontainer.cpp M +16 -6 dolphinviewcontainer.h WebSVN link: http://websvn.kde.org/?view=rev&revision=995018
Unfortunately this is still the case in KDE 4.3.1