> On Feb. 25, 2016, 9:18 p.m., Pinak Ahuja wrote:
> > src/externalextractor.cpp, line 104
> > <https://git.reviewboard.kde.org/r/127179/diff/1/?file=445488#file445488line104>
> >
> >     You should use the asynchronous api instead of blocking the event loop 
> > by calling waitForFinished()
> >     
> >     Connect a slot to the QProcess::finished signal and let it handle the 
> > output of the QProcess.
> 
> Varun Joshi wrote:
>     Since native plugins block the event loop, I thought it would be sensible 
> to let the caller handle calling all types of plugins asynchronously. What do 
> you think?
> 
> Boudhayan Gupta wrote:
>     Good point! Remember that the event loop is not ecxlisive to the KFM 
> library but is shared (and owned) by the application that uses this library. 
> Not yeilding to the event loop will freeze the parent application too.

Oh, wait I think you'll have to keep it the way it is. As you said the native 
plugins block the event loop as well and KFileMetadata only provides only a 
synchronous API and the caller is responsible for handling the plugin 
asynchronously, thats what we do in baloo as well, we have a seperate QProcess 
which uses the Extractor plugins.

Anyways closing the isssue, sorry for the noise.


- Pinak


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127179/#review92783
-----------------------------------------------------------


On Feb. 25, 2016, 6:32 p.m., Varun Joshi wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127179/
> -----------------------------------------------------------
> 
> (Updated Feb. 25, 2016, 6:32 p.m.)
> 
> 
> Review request for Baloo, KDE Frameworks, Boudhayan Gupta, and Vishesh Handa.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> -------
> 
> 1. Add the ExternalExtractor class that wrap the external extractor process 
> into the standard Extractor interface
> 2. Modify ExtractorCollection to enable it to support ExternalExtractors
> 3. Added an example PyPDF2 extractor plugin
> 
> 
> Diffs
> -----
> 
>   README.md 19b1a26a241e6a35c636aaf8162afe762018f073 
>   src/CMakeLists.txt a5490856a51aa2f59389ee963f3430c1ce5c60d5 
>   src/config-kfilemetadata.h.in PRE-CREATION 
>   src/externalextractor.h PRE-CREATION 
>   src/externalextractor.cpp PRE-CREATION 
>   src/extractorcollection.h 8542aed576102be2b0c86bbdf3d65d756d468c6e 
>   src/extractorcollection.cpp a1bde65bf57e493918cd3e85ccdb23c4cd623401 
>   src/extractorplugin.h 65abad3b2397628ba42a40d9ef2970e02114e250 
>   src/extractors/CMakeLists.txt 5dd223e1cf6864a943e848664ad5fae0d0603e77 
>   src/extractors/externalextractors/CMakeLists.txt PRE-CREATION 
>   src/extractors/externalextractors/pdfextractor/main.py PRE-CREATION 
>   src/extractors/externalextractors/pdfextractor/manifest.json PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127179/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Varun Joshi
> 
>

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to