KFileItem, mime types, and icons

[David Faure]

> Thanks for the hint! The "Poor Man's Profiling" technique was unknown
> to me so far, but it is indeed very simple and effective :-)

Hehe, it's rather intuitive though: "what is that program doing right now?" :)
 
> Program received signal SIGTSTP, Stopped (user).
> 0x00007ffff14e1a17 in access () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00007ffff14e1a17 in access () from /lib64/libc.so.6
> #1  0x00007ffff2bd4d9a in KStandardDirs::exists (fullPath=...) at
> /home/kde-devel/kde/src/KDE/kdelibs/kdecore/kernel/kstandarddirs.cpp:593
> #2  0x00007ffff2be9b22 in KFolderMimeTypePrivate::iconName
> (this=0xeaaf40, _url=...) at
> /home/kde-devel/kde/src/KDE/kdelibs/kdecore/services/kfoldermimetype.cpp:92
> #3  0x00007ffff2bf0b4b in KMimeType::iconName (this=0xd85fa0, url=...)
> at /home/kde-devel/kde/src/KDE/kdelibs/kdecore/services/kmimetype.cpp:605
> #4  0x00007ffff5ef77e6 in KFileItem::iconName (this=0x7fffffffb990) at
> /home/kde-devel/kde/src/KDE/kdelibs/kio/kio/kfileitem.cpp:921
> 
> It seems that it tries to access the directory on disk to see if there
> might be a .desktop file to read an icon name from. 

A .directory file, more precisely.

> This is not quite
> what I would have expected - after all, the point of calling
> KFileItem::iconName() without a previous determineMimeType() was to do
> it fast, without disk access (and that's apparently also what happens
> when calling iconName() for *files*).

Yep.
This is very very close to my recent fix for slow mounts, except that we want 
the same in all cases. So just removing checks for "is it slow" would do.
Can you test this patch?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kfileitem_delay_slow_icons.cpp.diff
Type: text/x-patch
Size: 1301 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130612/9b6fc3d7/attachment.bin>