If you enter a directory that contains many folders, sometimes (I guess when the folder contents are not in cache and/or the contents have changed) it need some time until all folder symbols show up. This is annoying because it' distracting. Does Dolphin look into every folder if there is an image and so a custom folder icon with preview shall be generated? If so, until that is done, the folder should show up with the default folder icon and not with the empty paper with a questionmark. Reproducible: Sometimes Steps to Reproduce: 1. Enable Folder-Previews 2. Browse through some directories that contain many sub-folders. Actual Results: Somtimes for a few seconds empty paper symbols show up before they get replaced by the folder icons. Expected Results: The folder Icons should show up immediately. Mint 14, 64bit.
Thanks for the report! Funny, I've been thinking about this issue just a few days ago and tried to find out what the cause is. What happens when entering a folder is the following: for 200 milliseconds, Dolphin tries to determine mime types (which is usually a prerequisite for determining the icon) synchronously, i.e., blocking the user interface, before the view is shown. Unfortunately, it does sometimes not know yet which items will be shown in the view (i.e., which items will appear on the first page), so it tries to determine mime types for all files and folders in random order. If that takes more than 200 milliseconds, then some mime types are sill unknown, and there is no icon for the file. The other types and icons are then determined asynchronously one by one, as are the previews. Fixing this will require some restructurings in the code that determines the mime types. I'll work on that and try to get it into KDE 4.11, but I cannot make any promises.
Git commit 52a38ee90c6ecab739748f99c1bd8a39c63e6aa7 by Frank Reininghaus. Committed on 22/04/2013 at 21:21. Pushed by freininghaus into branch 'KDE/4.10'. Always determine icons for the visible items first When entering a folder, KFileItemModelRolesUpdater has not yet been informed about the visible index range by the view when it tries to determine icons synchronously. This resulted in the problem that it tried to determine icons for all items in random order, and some visible icons were somtimes still unknown after the "synchronous icon loading" timeout of 200 ms. This commit tries to improve the situation by loading icons starting with the first item in increasing order. This should make it less likely that some visible items still have unknown icons after 200 ms. FIXED-IN: 4.10.3 REVIEW: 109843 M +1 -0 dolphin/src/kitemviews/kfileitemlistview.cpp M +16 -1 dolphin/src/kitemviews/kfileitemmodelrolesupdater.cpp M +3 -0 dolphin/src/kitemviews/kfileitemmodelrolesupdater.h M +5 -0 dolphin/src/kitemviews/kitemlistview.cpp M +2 -0 dolphin/src/kitemviews/kitemlistview.h http://commits.kde.org/kde-baseapps/52a38ee90c6ecab739748f99c1bd8a39c63e6aa7
Just for the record, even though the situation has improved somewhat with my commit from comment 2, it is still possible that "unknown" icons are shown sometimes. It turns out that this is because kdelibs provides no way to load a folder's icon without looking into that folder and checking if there is a .directory file that contains a custom icon. In some situations, this can be so slow that we fail to load all icons for the visible items in 200 ms (which is the time after which synchronous icon loading is aborted to keep the GUI responsive). We are currently discussing ways to improve this: http://lists.kde.org/?t=137051762500001&r=1&w=2 I'm optimistic that we can resolve the "unkown icons" issue once and for all in KDE 4.11 :-)