Review Request 123229: Ensure we don't crash when using KIO from non-QApplication process

[David Faure]

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


I don't understand why the move to Q_COREAPP_STARTUP_FUNCTION. That startup function is only about creating some singleton, not about registering a KJob (which is where the qApp type check happens).

If the startup function needs to see a fully constructed app (why?) - then Q_COREAPP_STARTUP_FUNCTION is too early, it's called by the QCoreApplication constructor.
But I don't understand what was the problem with the function being called even earlier. Do we have a case where a kio job is created before the app is constructed? (that sounds wrong).

- David Faure


On Dec. 7, 2015, 1:29 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123229/
> -----------------------------------------------------------
> 
> (Updated Dec. 7, 2015, 1:29 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> -------
> 
> Prevents the UiDelegate and UiTracker to get initialized, because they'll try to create windows and dialogs when some things happen and these will immediately end in a crash.
> 
> 
> Diffs
> -----
> 
>   src/widgets/kdynamicjobtracker.cpp 14924d5 
> 
> Diff: https://git.reviewboard.kde.org/r/123229/diff/
> 
> 
> Testing
> -------
> 
> Ran the tests, my unit test doesn't crash anymore.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151208/63f716b2/attachment-0001.html>