bruns added a comment.
In D12320#252547 <https://phabricator.kde.org/D12320#252547>, @mgallien wrote: > In D12320#249998 <https://phabricator.kde.org/D12320#249998>, @astippich wrote: > > > In D12320#249982 <https://phabricator.kde.org/D12320#249982>, @michaelh wrote: > > > > > -2 > > > https://cgit.kde.org/ffmpegthumbs.git/ should be useable, not sure though. > > > > > > It is also disqualified by the fact that it is not in frameworks. I think a nice solution is to implement a separate "extractor" that is not an extractor plugin like taglib, epub, etc. but implemented like the xattr tags (usermetadata) as a separate, exported class. This way, baloo doesn't have to be changed in any way and still applications using kfilemetadata can query the cover files specifically. > > > How does behave Baloo if you add properties of type EmbeddedPicture ? > Is it not a good idea to fix Baloo to not index everything but only searchable properties (like text and numeric properties and ignore binary data) ? > > The current way to manage user rating mush have had a good rationale for its current design but I have failed to understand it. > It would also look quite odd to have a particular way to fetch properties of type EmbeddedPicture. It may be useful to store some "EmbeddedPicture exists" flag inside Baloo. It should store strings, numeric values, dates, but as it has to handle each basic type individually (for storing data, parsing queries and executing queries) bytearrays should be ignored. REPOSITORY R286 KFileMetaData REVISION DETAIL https://phabricator.kde.org/D12320 To: astippich, mgallien, michaelh Cc: bruns, #frameworks, ashaposhnikov, michaelh, astippich, spoorun
