trueg at kde.org
Wed Jun 10 17:26:53 BST 2009
There are two solutions when using Strigi:
1. Hack Strigi to support a fastest flag -> a lot of work I think. Probably
not worth it, seeing that there are still analyzers to be ported.
2. Do it in KFileMetaData by restricting the number of bytes that Strigi can
read. I did not test this and have no idea if it will actually work.
The only problem I see with using Nepomuk is that Nepomuk is still optional in
KDE and that this will only get us metadata for actually indexed files.
I personally have no problem with this (obviously) but there might be other
In any case the Nepomuk workshop will be a good opportunity to work on these
On Wednesday 10 June 2009 13:34:07 Peter Penz wrote:
> 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
> 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 internally... :-(
> 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 using Strigi.
> Best regards,
>  "Assured" is probably not correct, but practically this was the case.
More information about the kde-core-devel