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

Darío Andrés andresbajotierra at gmail.com
Thu Apr 1 22:26:59 BST 2010


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


I don't know if this change in the header breaks some compatibility... also... if the apidox is ok (or if I should add some "@since" tag)

- 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
> 
>





More information about the kde-core-devel mailing list