D10803: handle more tags in taglibextractor

Fri Mar 2 20:24:03 UTC 2018

astippich added a comment.

  In D10803#216677 <https://phabricator.kde.org/D10803#216677>, @michaelh wrote:

  > 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.

  Well, if we would go to plurals, it would be wrong the other way if there are only single entries . Also, I think the properties don't have to plural, they are internal. The labels of them should adjust for the singular or plural case. That said, I don't think we can achieve that without breaking the programming interface, so we're stuck with that.

  >> 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>

  Okay, so here is a screenshot. Looks not so nice with lots of entries. Imho there should be a maximum number of properties, and a scrollbar should be used if that threshold is exceeded.

  F5736836: Screenshot_20180302_205701.png <https://phabricator.kde.org/F5736836>

  >> 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).

  The infopanel looks perfectly fine:

  F5736838: Screenshot_20180302_204919.png <https://phabricator.kde.org/F5736838>

  >>> 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.

  I agree that we should think that through. Once committed, we're stuck with that for the time being. In this specific case, I would actually argue that the conductor and director are different. Imho there is only limited potential to find tags that work for everything. Video, Music, text etc. are different after all.

  > 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.

  We pretty much have to cope with whats available out there in the wild as de facto standard. We're only consumers here.

INLINE COMMENTS

> michaelh wrote in taglibextractortest.cpp:82
> Just a hint: The code would be easier to read if the title of the sample file was
> 'I love you so much' or 'Desaster will come' just not the same as the propery name. (Same for most of the props below)

Hmm, I disagree since they are simple and they don't leave room for ambiguity

> michaelh wrote in taglibextractor.cpp:132
> Lyrics are not metadata. Unless a song is about itself ;-)

But they are commonly stored as metadata tags in the audio file.

> michaelh wrote in properties.h:302
> Could you give an example for what 'opus' is describing?

https://en.wikipedia.org/wiki/Opus_number

> michaelh wrote in properties.h:307
> Could you give an example for what 'label' is describing?

https://en.wikipedia.org/wiki/Record_label

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/2998da5b/attachment-0001.html>