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

Reply via email to