KFileItem, mime types, and icons

[David Faure]

On Thursday 06 June 2013 13:20:06 Frank Reininghaus wrote:
> 1. My observations
> 
> The thing is that Peter's code *always* calls
> KFileItem::determineMimeType() before calling KFileItem::iconName().

Oh.
 
> Now I wondered if that is really necessary, so I tried the following:
> called iconName() and iconOverlays() for all items that were received
> from KDirLister when entering a folder, measured how much time that
> takes, and then called determineMimeType() for all these items, and
> measured again.
> 
> It turns out that icon loading is often *much* faster than determining
> the mime types, especially in my favourite "see how it works with many
> real-world items" test cases /usr/bin/, /usr/include/, and /usr/lib64.
> The icons look OK even though the mime type of many files was
> apparently not known while the icon was loaded.

This surprises me; any shell script in /usr/bin (without any extension) should 
have an unknown icon if you call iconName() with an unknown mimetype.
That's ok of course, if the mimetype is determined later on, as discussed 
below. But I dispute "the icons look OK", especially since you said you didn't 
like seeing "unknown" icons :-) Or maybe you get the generic "executable" for 
such shell scripts (e.g. /usr/bin/znew), because they have the +x flag?

> 2. My conclusions
> 
> I think that we should do the following:
> 
> (a) When we try to determine icons for the visible items synchronously
> for 200 ms (we always do that when entering a folder or new items are
> inserted), we should just call iconName(), maybe iconOverlays(), but
> definitely not determineMimeType() (unless we sort by type).
> 
> (b) Later on, when we look at each item in the visible range (and
> those near the visible range or at the top and bottom of the list)
> asynchronously, we call determineMimeType() and update the icon.
> 
> This would greatly reduce the risk that 200 ms are insufficient for
> loading the visible icons, which results in "unknown" icons being
> shown to the user, which then only get replaced asynchronously and
> slowly.

In the code I wrote (i.e. all iterations of file management before dolphin) it 
was almost always like that. First, creating items without mimetype 
determination (fast), then later on mimetype determination, starting with the 
visible items. The 200ms limit is what dolphin introduced in addition, when 
reimplementing all this.
What you propose sounds good to me (especially since the 200ms limit should be 
hit less often without mimetype determination, so this is quite close to my 
old KMimeTypeResolver algorithm), but at the same time it makes me wonder why 
Peter changed from that to the 200ms algorithm. I seem to remember a 
discussion which said "it's ugly to get wrong icons, very quickly replaced 
with correct icons, it would be better to wait a little bit more (not much, 
just a little bit, hence the 200ms limit) and get correct icons immediately, 
to avoid the effect of seeing one icon replace the other very quick.

So maybe the best fix is rather the following adjustment to the current 
algorithm: after the 200ms timeout, instead of using "unknown" for everything 
other visible items [as you say it does, I'll trust you on that since I don't 
know that code], it should then use iconName() without mimetype determination 
for the other icons.
I.e. after 200ms, switch from the optimistic "we'll get it all done in time" 
approach to the fallback "ok, we'll do the rest in two stages, so that the GUI 
can keep being responsive". But that fallback should still look ok as much as 
possible, so iconName() rather than "unknown".

Or am I missing something?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5