D12156: implement reading of rating tag

[Alexander Stippich]

astippich added a comment.


  I agree, there are several problems coming from the fact that we basically have two sources for the same property, which can potentially conflict. Btw, we already have the same issue with the comment property.
  
  In D12156#257888 <https://phabricator.kde.org/D12156#257888>, @bruns wrote:
  
  > I see three problems here:
  >
  > - The current "Rating" is handled specially, you can e.g. select Rating: 4 or more in Dolphins "Find ..." dialog. If I have a file with an embeddedrating of 4.5 (normalized), I would expect it to show up. Probably the right thing would be to teach Baloo to treat embeddedrating the same way as a rating stored in an xattr, although I am not sure.
  > - Inconsistent data - the xattr rating may differ from the embedded rating. The one from the xattr should likely be preferred, but what is exposed in the file information widget?
  
  
  I want to leave that decision up to the application, and this patch is actually the first step towards that.
  
  > - Writing/updating the rating - we should remove any xattr rating, to avoid any ambiguities which one is the current one.
  
  I think one should write to both properties, so that existing applications relying on xattr continue to work. Also keep in mind that (at least with this patch) there are only rating tags for audio files, I don't know if such things exist for other documents.
  
  > The XAttr rating is retrieved with the basicindexingjob, and there is currently no possibility to "merge" data from the extractors in a different way than just creating the union. So in the database we have either
  > 
  > - Two, probably different, "rating" tags. Searching would match if any matches, and the widget would show an arbitrary one
  > - Two independent tags. Every search for a rating becomes `if ("rating" == r OR "embeddedrating" == r)`
  
  Hmm, haven't really thought about searching in baloo. But imho we should keep both ratings, since we don't know which is the "right" or more important one.
  
  In D12156#258436 <https://phabricator.kde.org/D12156#258436>, @mgallien wrote:
  
  > I would like to have only one rating in the KFileMetaData API that would transparently use the most appropriate way to store and read the rating.
  
  
  xattr tags have a completely different code path than the extractors. One could wire that up, but this would need to adapt all extractors and to teach the applications using KFileMetaData not to query the xattr separately anymore.
  
  > That would be:
  > 
  > - music audio file with a rating tag = we read the tag and write both tag and xattr attribute to maximize compatibility ;
  > - music audio file with only xattr rating attribute = we read the xattr attribute and write both tag and xattr attribute to maximize compatibility ;
  > - any file with only xattr rating attribute = we read the xattr attribute and write the xattr attribute ;
  > 
  >   Does this sound reasonable and feasible ?
  
  That was the plan anyway, but to let this be handled in the applications. I think this is especially important if we have conflicting ratings, and the user should be able to decide which one to use. I don't think that a library such as KFileMetaData should do that decision, it should present all available information.
  
  Let me know what you think. I prefer to let KFileMetaData just present all information and let the applications handle the difficulties. If you guys think that this is not the way to go, I can also try to implement this inside KFileMetaData.

REPOSITORY
  R286 KFileMetaData

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

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