Making KFileMetaData a framework
Milian Wolff
mail at milianw.de
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.
Bye
--
Milian Wolff
mail at milianw.de
http://milianw.de
More information about the Kde-frameworks-devel
mailing list