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

Reply via email to