astippich added a comment.
In D10694#221734 <https://phabricator.kde.org/D10694#221734>, @mgallien wrote: > In D10694#221719 <https://phabricator.kde.org/D10694#221719>, @michaelh wrote: > > > This is bad! I have learned baloo itself doesn't handle stringlists. Which in my view would be the natural way to handle token-like items like tags, keywords and subject(s). Until this is changed in baloo I'm putting this diff on hold and fro the time being work around these long subject-strings within baloo-widgets. > > > I believe this is quite the opposite. I am already getting strings list for some audio metadata. I would like to get your patch in given you make it works like already existing code and apart from the baloo-widgets code everybody should be fine with your modifications. > > > @mgallien: Did I understand you correctly, the refactoring helped you to understand it better? That would be an incentive for me to do more refactoring. > > This is this patch that made me read the code in baloo that store the properties returned by the extractors. This code is handling strings list quite fine and automatically when a property is added several times. Could you please point me to the code location? I would like to investigate how the code is used for D10803 <https://phabricator.kde.org/D10803>. Also, since this discussion also applies for the taglibextractor: Is a string list preferred for new properties in KFileMetadata when multiple entries are possible? I think right now most of the properties are using a single concatenated string. REPOSITORY R286 KFileMetaData REVISION DETAIL https://phabricator.kde.org/D10694 To: michaelh, mgallien, dfaure Cc: astippich, #frameworks, ashaposhnikov, michaelh, spoorun, navarromorales, isidorov, nicolasfella, firef, andrebarros, alexeymin, emmanuelp
