D19087: Add standalone conversion functions for PropertyMap to Json and vice versa

Stefan BrĂ¼ns noreply at phabricator.kde.org
Sat Feb 23 20:27:32 GMT 2019


bruns added inline comments.

INLINE COMMENTS

> astippich wrote in propertydata.cpp:80
> Please incorporate support for stringlists.
> All clients currently rely on having string lists (or variantlists) as output for multiple entries. It is also what is advertised in KFileMetaData.
> None of the clients query for multiple entries in the PropertyMap, Dolphin and Baloo-widgets will break without this for multi-value properties. All of them add and format the output on a per property basis, so querying for multiple keys requires significant changes.
> IMHO all extractors should only add one property for each key to the map. If there are duplicate entries, this means that multiple extractors added results (with possible duplication).
> Having it as string lists also makes the handling of them so much easier. It can be handled with one call to QVariant::toStringList().join().

> All clients currently rely on having string lists (**or variantlists**)

Actually, string lists make the code more complicated, as the code already has to handle variant lists. There are no `QDoublelists`, `QIntlists` ... baloo-widgets treats a `QVariantList` with string entries exactly like a `QStringlist`, and dolphin uses baloo-widgets.

> It is also what is advertised in KFileMetaData.

KFileMetaData does not specify in any way how values for repeated properties are retuned. It explicitly allows calling ExtractionResult::add() with the same property multiple times, but that's it. PropertyMap is just a QMap<> typedef, and does not specify any behavior. For me, it seems much more natural to expect multiple individual entries for the same key, which should be retrieved with QMap::values().

Currently, baloo-widgets (https://cgit.kde.org/baloo-widgets.git/tree/src/filemetadatawidget.cpp#n152)  only uses `data[key]`, i.e. it only retrieves the first value, but fixing this is a single line change (i.e. replace `data[key]` by `QVariant(data.values(key))`).

> Having it as string lists also makes the handling of them so much easier. It can be handled with one call to QVariant::toStringList().join().

`QVariant::toStringList()` also works on `QVariantLists` - https://doc.qt.io/qt-5/qvariant.html#toStringList

> astippich wrote in propertydata.cpp:83
> True, and I said the same quite often in other reviews. But you did not let this count for me either :)
> Anyway, not a blocker for me.

Only if it can be fixed it a straight-forward and trivial way, or when it is a regression. This is IMHO not the case here. 
Also, PropertyInfo::valueType specifies `QString` for several properties where multiple values are completely reasonable.

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, #frameworks, ngraham, poboiko, astippich
Cc: kde-frameworks-devel, 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/20190223/193e00ed/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list