Making KFileMetaData a framework

[Milian Wolff]

On Wednesday 06 August 2014 17:29:40 Vishesh Handa wrote:
> On Wednesday, August 06, 2014 04:09:19 PM Milian Wolff wrote:
> > > Hmm, how would we do async? I thought people could just run it in
> > > another
> > > thread / process if they want. The only thing I can think of changing is
> > > that the plugins return the result later via a signal instead of doing
> > > all
> > > the work in one function.
> > 
> > This would be good since it makes it trivial to use it then in a
> > background
> > Thread - essentially you'd put a worker object into some thread/task which
> > then emits a signal with the data when its ready. This could be the
> > Manager
> > (which then automatically finds the correct extractor for the given
> > mimetype), or a certain Extractor, if you know which one should be used.
> 
> It might just be easier to make the manager return a QRunnable with all the
> extractors for that mimetype ready to run. And then you run them in a thread
> loop.

No please don't. QtConcurrent just plain sucks.

> > Though note that the above does not mean that a call to extract would be
> > async. It would still be sync. But you could use QFile and its readyRead
> > signals internally to process stuff asynchronously and then emit the data
> > once  the end of the file is reached. If the signals are there (see above)
> > this could be done without changing the API and thus could be done later.
> 
> With Qt we have QFile and readReady signals so this can be done. But a lot
> of the extractors use third party libraries which are quite often
> synchronous.

Right, then imo just leave it as-is but still add some signals which make it 
simpler to use the code as a worker object in a thread. At least, that's my 
opinion. Not sure what Kevin has to say in that regard.

Bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de