After I navigate to folder with many files with sorting by type enabled icons start to change their positions randomly.
With 'show groups' options enabled, there appears file type with empty name for little time.
If folder contains a lot of files, dolphin lags until icons finish jumping.
After navigating to this folder again everything behaves normally.
Steps to Reproduce:
1. setup sorting by type view mode for all folders
2. navigate to folder with many files
files change their positions in dolphin several times
positions of files must be set instantly
Thanks for the report. I haven't seen such problems recently. Many things have changed in this area for KDE 4.11, so I'd appreciate it if you could try it again in KDE 4.11 when it's out and tell us if you still see any problems (however, we'll need more information then to find out what the problem is and if anything can be done about it).
(In reply to comment #0)
> Expected Results:
> positions of files must be set instantly
This is, unfortunately, impossible.
Determining the mime type of a file is in general a very expensive operation because the file contents must be read if the type cannot be determined unambigously from the extension (the results are cached though and can be reused if the folder is visited again). In order to prevent that the application freezes for however long it takes to determine the type for all files, we show the files immediately (well, actually, we do try to determine all mime types synchronously for 200 ms, but this might fail if there are many files) and move them to the right position when their type is known. Actually, it should not move files around multiple times though - after the initial folder loading, one final resorting should be done once all types are known. But again, lots of things have changed in this part of the code for KDE 4.11, so please report back if you still see problems when you upgrade. Thanks.
Frank, are all commits that should address this issue in master? I am seeing the same behavior on the following situation, and I think this did not happen in earlier versions:
- set sort mode to "sort by type"
- visit a directory containing only 32 folders (no other files) for the first time
Because of the cold disk caches, icons do not appear instantly. If they do appear after a delay of about 100 ms, they appear unsorted, then a moment later get sorted.
@Christoph: I could not reproduce the problem that you describe, but I think it might depend on how long it actually takes to finish the KFileItem::determineMimeType() calls for the folders.
KFIleItemModel tries to determine mime types synchronously for 200 ms before sorting the items. If that does not succeed, then it can indeed be that they are first shown partially unsorted. In your use case, I would assume that there are two sub-groups which are both sorted by name (the folders with known mime type, and the others). However, this has been like that since KDE 4.8, and I don't see how anything committed to master recently could have made this worse.
(BTW, if you use current KDE/4.11 with my latest commit a few minutes ago, then there should never be unknown icons, but this will not affect the sorting).
In any case, this looks different from the bug reported here (which is about resorting the items multiple times).
One might ask why it takes so long to determine the mime types of folders at all. This is because KFileItem::determineMimeType() also checks if there is a .directory file inside the folder that contains a custom icon. In principle, we could optimize this slightly in Dolphin by not calling determineMimeType() at all for folders in KFileItemModel::determineMimeTypes(), but rather just setting the correct folder mime type if KFileItem::isDir() returns true. This should make problems like the one you describe in comment 2 impossible.
ok, it seems like the icons stop jumping with kde 4.11. i can't reproduce this bug on 2 machines, where it was reproducible with kde 4.10.
however, in some cases (big folders?) empty type group still appears on the top of view for a small time. should dolphin hide empty group with icons it owns? or maybe there is a better behavior strategy? how is it implemented in other filemanagers?
(In reply to comment #4)
> however, in some cases (big folders?) empty type group still appears on the
> top of view for a small time.
Does this happen only in folders which contain many subfolders? If yes, then this could be fixed with the following patch:
I had originally planned to only commit this to master (which will become KDE 4.12), but in principle, the patch is not very intrusive, and we could also use it for 4.11.1.
(In reply to comment #5)
> (In reply to comment #4)
> > however, in some cases (big folders?) empty type group still appears on the
> > top of view for a small time.
> Does this happen only in folders which contain many subfolders? If yes, then
> this could be fixed with the following patch:
> I had originally planned to only commit this to master (which will become
> KDE 4.12), but in principle, the patch is not very intrusive, and we could
> also use it for 4.11.1.
i've tried to create separate folder with 10000 empty folders and separate folder with 10000 empty files. empty group appears in both cases.
Thanks for the update. The thing is that we try to determine mime types only for 200 ms before we show the items in the view (possibly with an "unknown" type). This is to prevent that the user interface is blocked for very long.
For folders, it currently takes surprisingly long to determine the mime type because KFileItem::determineMimeType() not only determines the type, but also the icon, which requires a disk access because there might be a .directory file in the folder which specifies a custom icon. This limitation is worked around by the patch I linked to.
For files, it depends on the extension. If the type can be determined unambiguously from the extension (like with .txt), determining the mime type is quite fast. But for really many files, it could still take longer than 200 ms, and then we end up with some "unknown" types before we show the items in the view.
I see no good way to change that without risking that we block the GUI for many seconds when entering folders with lots of files whose type can only be determined with a disk access (like /usr/bin/).
Git commit ab8ee1a6a902ae682aa6ed098712ffae43326a2f by Frank Reininghaus.
Committed on 24/08/2013 at 18:22.
Pushed by freininghaus into branch 'KDE/4.11'.
Make determining the mime type faster for folders
KFileItem::determineMimeType() not only determines the mime type, but
also the icon. For folders, it looks for a .directory file inside the
folder, where a custom icon might be stored. This can take quite a bit
of time and cause the problem that some folder's type still appears to
be "unknown" when the view is shown.
We can work around this problem by caching the folder mime type in a
static QString and applying to to all folders, which can be identified
easily with KFileItem::isDir(),
M +12 -1 dolphin/src/kitemviews/kfileitemmodel.cpp