Where are we with this? @bruns are you accepting the proposed solution or do you reject it completely?
I think it is at least way better than the current solution and maintains current API.
A larger refactoring could be done for KF6

• udpate since tag

friendly ping for the series

good to go from my side

here you go:

• remove color

In D25517#588029, @bruns wrote:

The problem is the extractor serves two different use cases:

• retrieval for searching/caching properties
• on-demand extraction
  
  Baloo falls into the first category. It is only interested in properties which can be queried/compared in a meaningful way. Even storing the properties as a cache for e.g. Dolphin is a little bit of a stretch.
  
  Elisa falls into the second category. It does not store the extracted data persistently, but is fine extracting e.g. the front cover on demand.
  
  Currently the only large/blob property is the front cover. But what about BackCover, Leaflet pages, ..., Video Thumbnails? Returning all of these even when not required is wasteful. If you want a front cover, say so.

Thanks, looking good! Just one question inline

• adapt to changes

• adapt to changes

• adress review comments

In D25517#587776, @bruns wrote:

I have thought about this and have come to the conclusion this is not really future proof.

The Property::FrontCover is IMHO fine, i.e. the changes to propertyinfo.cpp and properties.h could go in as is.

The request of additional properties should be done differently. How about the following:

1. divide properties into (currently) two sets, "Simple Metadata" (all the current ones but frontcover) and "Complex Metadata" (currently frontcover).
2. allow to specify extra properties for SimpleExtractionResult

friendly ping! I would like to continue work on this. Is the new name better? If so, I will rebase follow-up patches

• rename flag to ImageData

I would honestly prefer just to check within the QML side of things and display the default image in case of an error. This way, this would actually also catch issues with local tracks (in case an image was deleted or similar).
But @mgallien would like to check it before, so let's wait for his response.
Actually, I think the way the url checking is implemented is synchronous, e.g. blocking in case of no reply, if I am not mistaken. This should definitely be changed.

ping!

taglibwriter should get the same treatment

• rebase

• fix label comment
• tweaks

For baloo-widgets, the display of the lyrics tag is disabled anyways. Displaying a large chunk of text does not really look good in the information panel...

• put all helper functions into anonymous namespace

• fix label comment

This is probably how it should have been implemented from the beginning, and not how I did it in the embeddedimagedata class, which duplicates a lot of code and requires additional file operations.
Baloo can continue to work as is due to the new flags.
Taglib writer will follow if this is accepted. Afterwards, I will deprecate embeddedimagedata

For the concept a big +1 from me. I did not even know that we had that in the infocenter...

• tweak icon and shadows
• remove baloo symlink

the scalable test fails with this one. Is the right solution to just delete the 32px symlink under .../preferences?

nice

any more comments?

Thanks! I pushed a fix which disables the test if taglib is not installed