D10694: epubextractor: Handle multiple subjects better

[Michael Heidelbach]

michaelh added a comment.


  In D10694#213712 <https://phabricator.kde.org/D10694#213712>, @mgallien wrote:
  
  > To me, it is necessary to have a test that ensures that possible existing clients are not affected by your change. Could you add it ?
  
  
  The new behaviour will break clients. No test needed for this. E.g. baloo-widgets will show the label 'Subject' but no content.
  To make it clear: I do not want break this for clients apart from baloo-widgets. The question is: Who are the clients? and How to find them except for searching https://lxr.kde.org/? Please help me with this.
  
  The current behaviour is already breaking: I have some epub files with a lot of `dc:subject` tags. The semicolon-concatenated string is longer than my monitor is wide. As a result in dolphin the tooltip does not display at all. My rationale was to tackle the problem at the root rather than to work around it by splitting the string within baloo-widgets. With regard to T8079 <https://phabricator.kde.org/T8079> it will be the same. If data is taken from baloo's database that old long string will be displayed
  
  According to the standard an epub can have multiple `dc:subject` entries. So it is reasonable to expect a string list from KFileMetaData. Plus the possibilities are grand with an KFileMetaData writer for epubs one could use the tag widget to change them. One could unify xattr tags and epub subjects in tags:// protocol and mayby more.

REPOSITORY
  R286 KFileMetaData

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

To: michaelh, mgallien, dfaure
Cc: #frameworks, ashaposhnikov, michaelh, spoorun, navarromorales, isidorov, nicolasfella, firef, andrebarros, alexeymin, emmanuelp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180227/58b120ce/attachment.html>