Making KFileMetaData a framework

Milian Wolff mail at
Wed Aug 6 12:10:19 UTC 2014

On Tuesday 05 August 2014 19:58:03 David Edmundson wrote:
> In general that's some of the tidied code I've seen in a long time.
> Comments below. One major, most not.
> ----
> TypeInfo/PropertyInfo/SimpleExtractionResult need a working &operator=
> otherwise we shallow copy d.
> I can cause a crash in dump.cpp
> ----
> Extracting info from a file can take a long time, right now you spawn
> a separate execuatble for Baloo; but for other uses (i.e dolphin
> getting info on a non-indexed file) you might want to add a helper
> API; either a new thread or a service like baloo-file-extractor and a
> wrapper round calling it.

I don't think its a libraries' task to provide such an API. It cannot know 
whether I want to use ThreadWeaver, QThreadPool or something else. As long as 
it's possible to use the library from different threads (e.g. make the 
extractors stateless and thereby threadsafe), I don't think anything else must 
be done.

> -----
> ExtractionPluginManager possibly shouldn't be a QObject?
> It /might/ be a good idea to make ExtractionPluginManager static so
> you don't load the plugins every time (which can be a bit expensive)

I would not enforce this just because it might accidentally be misused. 
Singletons are an anti-pattern.

Milian Wolff
mail at

More information about the Kde-frameworks-devel mailing list