peter.penz at gmx.at
Wed Jun 10 12:34:07 BST 2009
Until KDE 3.5 using KFileMetaInfo with the "Fastest" flagged assured  that
invoking the constructor does not block the caller for several seconds. In
this case the caller of KFileMetaInfo accepted getting only the meta
information that can be received without the need to parse the whole file.
Since KDE 4.0 KFileMetaInfo uses Strigi to get the meta data and the "Fastest"
flag is ignored. Now getting the meta information of a huge MP4, PDF or ZIP
file can take several seconds (see e. g.
My basic question is how KFileMetaInfo is intended to be used when specifying
the "Fastest" flag:
(A) If the callers may use it synchronously (e. like done in
KFileItem::getToolTipText()) IMO opinion it must be assured that the response
time is "small" (< 1 second?).
(B) If the callers may not rely on a small response time, then this should at
least be mentioned in the API.
KFileMetaInfo is used very often (http://lxr.kde.org/ident?i=KFileMetaInfo)
and as far as I could see only synchronously...
Dolphin for KDE 4.3 uses Nepomuk for the Information Panel to bypass this
issue. Still the issue pops up again when turning on tooltips, as the tooltip
text is received by KFileItem::getToolTipText() which uses KFileMetaInfo
Any ideas how to proceed here? One thing that comes into my mind is that
KFileMetaInfo might use Nepomuk to get the meta data instead of synchronously
 "Assured" is probably not correct, but practically this was the case.
More information about the kde-core-devel