D12156: implement reading of rating tag

[Matthieu Gallien]

mgallien requested changes to this revision.
mgallien added a comment.
This revision now requires changes to proceed.


  In D12156#249994 <https://phabricator.kde.org/D12156#249994>, @astippich wrote:
  
  > In D12156#249977 <https://phabricator.kde.org/D12156#249977>, @michaelh wrote:
  >
  > > In D12156#249971 <https://phabricator.kde.org/D12156#249971>, @astippich wrote:
  > >
  > > > In D12156#249951 <https://phabricator.kde.org/D12156#249951>, @michaelh wrote:
  > > >
  > > > > It's for elisa I guess, could you please elaborate how POPM/RATING is going to be used and why xattr are not applicable?
  > > >
  > > >
  > > > It will be used as a fallback when there is no xattr rating set or available (e.g. on Windows) so that users who have rated their music with other players can still see their previous ratings. 
  > > >  It will also useful for managing ratings on other platforms when writing support is added.
  > >
  > >
  > > I that case I would suggest to use xattr only on systems that support it, and use POPM/RATING on those that don't. I afraid users will find it confusing to have two ways of rating a file. Or is rating via dolphin/baloo-widgets not planned?
  > >  Because extractors are called in sequence it would also be possible to create a dedicate taglibRatingExtractor (much easier to apply build conditionals).
  >
  >
  > We still need the ability to read the tag, since users expect to see the rating in music players.
  >  For baloo-widgets I created D12157 <https://phabricator.kde.org/D12157>
  
  
  If I have correctly understood the ideas behind the conception of Baloo, we should probably prefer to store the rating with a "native" solution instead of the xattr one that is not portable outside of software using KFileMetaData.
  
  We have to stay compatible with older versions of KFileMetaData. So we should push the same rating to both properties and try to read it from both properties in the cases where only one exists.
  
  Could you try to modify your patch to do that ?

REPOSITORY
  R286 KFileMetaData

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

To: astippich, mgallien, michaelh
Cc: bruns, #frameworks, ashaposhnikov, michaelh, astippich, spoorun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180423/47fdde3f/attachment-0001.html>