D12156: implement reading of rating tag

[Stefan Brüns]

bruns added a comment.


  In D12156#254055 <https://phabricator.kde.org/D12156#254055>, @astippich wrote:
  
  > In D12156#252575 <https://phabricator.kde.org/D12156#252575>, @mgallien wrote:
  >
  > > 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 ?
  >
  >
  > I don't understand. Which patch to you want me to modify? This one here only adds the ability to read the rating embedded in the tags in addition to the xattr rating. It's up to the application to decide what to do with the information. 
  >  The patch for baloo-widgets just hides this new rating tag to avoid duplicate entries in e.g. dolphin, and actually preserves the current behavior this way. Baloo caches the embedded rating anyways. 
  >  When KFileMetaData gains the ability to write the tags, one should write to both properties, but that is currently not possible.
  
  
  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?
  - Writing/updating the rating - we should remove any xattr rating, to avoid any ambiguities which one is the current one.
  
  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)`

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/20180503/16b1c31a/attachment.html>