[Interest] [QQuickView] deadlock on exit

[Tim Blechmann]

>> i will see what i can do ... what do i need to do in order to run exec()
>> from a thread other than the main thread? afaict it wants to be called
>> from the main thread, so simply creating a std::thread to run
>> qApp->exec() does not work.
> 
> Start your thread using non-Qt means and make sure the *first* QObject created 
> is in that thread. QApplication is a QObject, so you may use that.

just to make sure that i'm understanding this correctly: the thread that
creates the first QObject becomes qt's main thread?
this also implies that *all* other qt objects are created from this
thread, instead of the main thread right?


>> and for the case of a plugin, i think it is simply impossible, because
>> afaict the plugin's gui has to run in the same thread as the host's gui.
> 
> If the plugin is already using Qt, then the problem is solved.
> 
> If the plugin is not using Qt, there's no threading issue. Qt requires its GUI 
> to be run from one thread only, but it does not make any requirements on GUIs 
> written without Qt.

forgive my ignorance, maybe i'm missing something very stupid here: in
the case of a plugin, the host provides a native handle (HWND or
NSView*). i'm wrapping this native handle inside a QMacNativeWidget or
qwinwidget and place a QQuickView inside.
i'm not an expert with gui systems nor with qt, but from my
understanding this implies that the plugin's gui has to run in the same
thread as the host's gui. and therefore the QApplication must be created
in the gui thread and not in a separate thread.
and creating the QApplication in the gui thread, i cannot run exec()
without blocking the host's gui.

thanks,
tim