<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Hi,<br>

<br>

There is the opposite problem with KFileMetaInfo in Lokalize.<br>

Lokalize uses it to get translation stats, which means KFileInfo has to

read all data in file, but currently it reads only first 100 Kb and

fails for files larger than that.<br>

<br>

There is the WhatFlags flag in the KFileMetainfo constructor that is

supposed to govern how much data to read, but it is ignored in the

implementation.<br>

Is is possible to implement the WhatFlags parameter handling to always

read the whole file?<br>

<em></em><br>

Viesturs<br>

<br>

Peter Penz wrote:

<blockquote cite="mid:200906101334.07764.peter.penz@gmx.at" type="cite">

  <pre wrap="">Hello,

Until KDE 3.5 using KFileMetaInfo with the "Fastest" flagged assured [1] 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. 

<a class="moz-txt-link-freetext" href="https://bugs.kde.org/show_bug.cgi?id=179523">https://bugs.kde.org/show_bug.cgi?id=179523</a>).

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 (<a class="moz-txt-link-freetext" href="http://lxr.kde.org/ident?i=KFileMetaInfo">http://lxr.kde.org/ident?i=KFileMetaInfo</a>) 

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,

Peter

[1] "Assured" is probably not correct, but practically this was the case.

  </pre>

</blockquote>

</body>

</html>