D18601: Rewrite taglib writer to use property interface

[Stefan Brüns]

bruns added inline comments.

INLINE COMMENTS

> astippich wrote in taglibwriter.cpp:70
> Not sure I understand. I would like to avoid doing `file->properties();` and `file->setProperties();` twice for those formats for which only the PropertyMap is sufficient, e.g. Ape and Ogg, to avoid doing any unnecessary work.  The beauty of Ape and Ogg in the TagLib implementation is that they solely work with the PropertyMap and do not require any special handling. See D18826 <https://phabricator.kde.org/D18826>, Ape and Ogg do not have any extra codepath at all. For writing tags, we have to be a little bit more careful, though. If writing Rating information is added to writeGenericProperties, for example Id3v2's "TXXX" tags will be polluted with these values.

I think for **reading** it as generic as possible is fine, but for writing being a little bit more explicit does not hurt.

My proposal for Ape and Ogg is to split the writing for these to two different functions. Yes, it **is** possible to use the propertymap for both, as both use the same scale and the same tag name, but the implementations on the taglib side are completely different.

Writing the "rating" for XiphComment (Ogg) and  Ape in distinct functions (see my comment in D18604 <https://phabricator.kde.org/D18604>) hardly adds any code, but gets the Ape and Ogg code paths in line with the other file formats. You don't write the ASF/MP4 rating using the property interface although it would be possible, and IMHO thats the right thing to do,  also for Ape and Ogg.

As soon Ape and Ogg are split, you no longer rely on the PropertyMap for the rating, and you won't have to use `properties()`/`setProperties()` twice.

REPOSITORY
  R286 KFileMetaData

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

To: astippich, bruns, mgallien, broulik, cfeck
Cc: kde-frameworks-devel, #baloo, 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/20190301/674e7e8d/attachment-0001.html>