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

Reply via email to