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 m...@milianw.de http://milianw.de _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
