mgallien 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 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. 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 ? REPOSITORY R286 KFileMetaData REVISION DETAIL https://phabricator.kde.org/D12156 To: astippich, mgallien, michaelh Cc: bruns, #frameworks, ashaposhnikov, michaelh, astippich, spoorun, ngraham
