D25517: Add an option to extract image data and add front cover property

[Stefan Brüns]

bruns added a comment.


  The problem is the extractor serves two different use cases:
  
  - retrieval for searching/caching properties
  - on-demand extraction
  
  Baloo falls into the first category. It is only interested in properties which can be queried/compared in a
  meaningful way. Even storing the properties as a cache for e.g. Dolphin is a little bit of a stretch.
  
  Elisa falls into the second category. It does not store the extracted data persistently, but is fine
  extracting e.g. the front cover on demand.
  
  Currently the only large/blob property is the front cover. But what about BackCover, Leaflet pages,
  ..., Video Thumbnails? Returning all of these even when not required is wasteful. If you want a
  front cover, say so.
  
  For KF6, ExtractEverything should just be removed. It is not especially useful, not even for unit tests.
  Request the data you want and are able to handle, and do so explicitly.

INLINE COMMENTS

> extractionresult.h:62
> +        ExtractImageData = 4,
> +        ExtractEverythingIncludingImageData = (ExtractEverything | ExtractImageData),
>      };

Does not belong in the API. It is not really clear what it does.

If you want a convenience flag in your application, please define it locally.

> propertyinfo.cpp:585
> +            d->valueType = QVariant::ByteArray;
> +            d->shouldBeIndexed = false;
> +            break;

shouldBeIndexed is irrelevant for ByteArray, omit it.

REPOSITORY
  R286 KFileMetaData

REVISION DETAIL
  https://phabricator.kde.org/D25517

To: astippich, #baloo, bruns, mgallien, ngraham
Cc: kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, fbampaloukas, GB_2, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200105/e3789df9/attachment-0001.html>