D10803: handle more tags in taglibextractor

[Michael Heidelbach]

michaelh added a comment.


  In D10803#216419 <https://phabricator.kde.org/D10803#216419>, @astippich wrote:
  
  > While I think you have a point here, KFileMetaData sticked to singular names before, e.g. author, where also multiple persons are possible. So I think we should keep that behavior.
  
  
  We're stuck with that. Nevertheless, it's wrong IMO. All I'm saying is: Before simply repeat this error, let's give it some thought.
  
  > To be honest, I don't know which tooltip you mean. Can you post a picture? Is this an option I have to switch on?
  
  Configure Dolphin > General > Show Tooltips
  Currently tooltips are a little broken. see D9973 <https://phabricator.kde.org/D9973>
  
  > I think it behaves quite well and reasonable with many tags as it shows a scrollbar. I don't think that there is a better solution.
  
  I haven't tested this. So I don't really know. And you're probably right. I forgot that the choice of properties depends on the file type. A screenshot of the dialog would be nice (large enough to display everthing).
  
  >> 1. The property names should be choosen to be as generic as possible to make them reusable by other file types.
  > 
  > I went through the properties again and only found that we might want to use the "generator" property instead of a new "encodedby" property. Do you have any other suggestion?
  
  Not yet. To illustrate what I'm thinking of:
  Conductor and Director (of a Movie) are analogous. It would be nice to have a term covering both. . Ditto Lyricist and Screenwriter, and maybe more.
  I don't know if that is possible - at least I have no idea yet. We should just give it some (more) thought.
  Or the other way around: 
  I find the distinction between 'Release Year' for media and 'Creation Date' (which should correctly be 'Publication Date') in for EBooks annoying and confusing. We should not repeat that, if possible.
  
  The property names are important for searching with baloo. Everything comes together here. (I'll elaborate this on demand)
  The code you are working on exemplifies pretty well, that everybody is brewing his own soup when is comes to metadata and tags. And this is only audio! 
  I'm not saying you're doing this. But instead of just throwing in what is there we should agree on a concept how KDE is handling metadata. This is not the place to discuss that, though. I haven't this much thought yet it's  just a feeling we might get into trouble in the future.

INLINE COMMENTS

> taglibextractor.cpp:132
> +    TagLib::String label;
> +    TagLib::String lyrics;
> +    TagLib::String author;

Lyrics are not metadata. Unless a song is about itself ;-)

> properties.h:168
>       */
> +    //KF6 TODO: fix typo Langauge->Language
>      Langauge,

This may become a plural in KF6, should we decide on it.

> properties.h:302
> +     */
> +    Opus,
> +

Could you give an example for what 'opus' is describing?

> properties.h:307
> +     */
> +    Label,
> +

Could you give an example for what 'label' is describing?

REPOSITORY
  R286 KFileMetaData

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

To: astippich, mgallien, ngraham
Cc: vhanda, dfaure, michaelh, ngraham, #frameworks, ashaposhnikov, spoorun, nicolasfella, alexeymin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180302/b88f47f4/attachment-0001.html>