mgallien added a comment.
In D10803#214655 <https://phabricator.kde.org/D10803#214655>, @astippich wrote: > In D10803#213783 <https://phabricator.kde.org/D10803#213783>, @michaelh wrote: > > > In D10803#213767 <https://phabricator.kde.org/D10803#213767>, @astippich wrote: > > > > > I don't know dolphin works, but given how KFileMetadata is designed, the new tags should be ignored until explicit support is added in dolphin. > > > > > > Please try that. For unknown types baloo-widgets (responsible for infopanel/tooltips) falls back to `value.toString()`, no idea what will happen when you feed it with binary data. The cover properties return binary data, right? > > > The cover is binary data, right. And I think I was wrong. While I don't fully understand yet how baloo-widgets work, from what I've read all available properties are automatically queried. The binary data would then be converted to a string as you said. So adding the cover this way may not be a good solution. A different interface should be created for image/binary data. > I think I will split this into two diffs and do the cover images separately. This is not necessary. You could use a QImage or a QPixmap. You can put them in a QVariant and they should be converted to an empty QString. As far as I understand, in Elisa, we would need to access them with QQuickImageProvider. All in all, well done job. I am not sure for the rating given that there is also a rating (the one used in Elisa) that is stored as an extended file system attribute independent from the file mime type. One limit of this rating is that it is specific to the KFileMetaData API users. Do you have an idea ? REPOSITORY R286 KFileMetaData REVISION DETAIL https://phabricator.kde.org/D10803 To: astippich, mgallien Cc: dfaure, michaelh, ngraham, #frameworks
