Review Request: Update KFileItem and KFileMetaPropsPlugin to only request limited metaData (avoid reading all the file and blocking the UI)

[Darío Andrés]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3325/#review4693
-----------------------------------------------------------


Another simple alternative would be examinate why a 64kb limit was imposed when reading the metaInfo (Jos?) and try to remove that limit, (in a way that doesn't cause KFileMetaInfo to read *all* the file *all the times*)
So, Nick could use KFileMetaInfo() and that would not affect the file managers

- Darío


On 2010-03-27 13:17:13, Darío Andrés wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3325/
> -----------------------------------------------------------
> 
> (Updated 2010-03-27 13:17:13)
> 
> 
> Review request for kdelibs, Peter Penz, Nick Shaforostoff, David Faure, and vandenoever.
> 
> 
> Summary
> -------
> 
> Backstory:
> - KFileMetaInfo::What modes are not honored because they are unimplemented with Strigi (not really important in this case)
> - KFileMetaInfo default What value is "Everything"
> - Nick Shaforostoff (Lokalize maintainer) changed the default behavior of KFileMetaInfo to read the whole file when What is "Everything" (previously, it only read the first 64kb). This 64kb limit needs to be broken for metainformation to be fetched from .po files.
> 
> So, currently the file properties dialog (and every other impl using KFileItem::metaInfo()) will read the whole content of the file , blocking the UI with big files
> 
> My patch sets both implementations to use "KFileMetaInfo::TechnicalInfo | KFileMetaInfo::ContentInfo" instead of the default Everything (in any case, as those flags are not implemented, anything different to Everything would work)
> 
> Peter already plains to solve this in the File Properties dialog with his own threading method, but this patch covers the other situations (they are complementary fixes)
> 
> Things to discuss:
> - If we choose my implementation we should probably state it on KFileInfo apidox ("metaInfo defaults to X, Z. Query your own KFileMetaInfo if you need more")
> - Should we preserve the KFileMetaInfo::What flag (and implement it on a future using Strigi); or should the flag be removed and another flag added (something like ScanAllTheFile, ScanTheFirstKBs) ?
> - Should we default to reading only the first 64kb of every file (as the previous approach) and introduce a new value of the flag "EverythingAllTheFile" (seems redundant) for Nick to use on Lokalize ?
> 
> References:
> Nick original patch: http://reviewboard.kde.org/r/2215/
> Peter threaded implementation: http://reviewboard.kde.org/r/3277/
> 
> 
> This addresses bug 216932.
>     https://bugs.kde.org/show_bug.cgi?id=216932
> 
> 
> Diffs
> -----
> 
>   svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/kio/kfile/kmetaprops.cpp 1107102 
>   svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/kio/kio/kfileitem.h 1107102 
>   svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/kio/kio/kfileitem.cpp 1107102 
> 
> Diff: http://reviewboard.kde.org/r/3325/diff
> 
> 
> Testing
> -------
> 
> Dolphin doesn't block when accessing the file properties dialog of a big (~400mb) file
> 
> 
> Thanks,
> 
> Darío
> 
>