>> 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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
