On 9 January 2014 02:13, Thiago Macieira <thiago.macie...@intel.com> wrote: > On quarta-feira, 8 de janeiro de 2014 18:29:06, Tim Blechmann wrote: >> > 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. > > Qt makes no such requirement. All it requires is that its GUI be run from one > thread only, which we call the GUI thread. That thread must be the thread in > which the first QObject is created. Since usually the first QObject created is > QApplication or QCoreApplication in the main function, it's usually the main > thread. > > However, the underlying system API may make other requirements. I have no clue > about the thread-safety of Win32 or Cocoa.
AFAIK, the Cocoa framework mandates that all GUI-related operations must be performed in the first thread of a process [1], i.e. the the thread that calls main(). QApplication can be created in a separate std::thread in Windows, but not on Mac OS X. Regards, Sze-Howe [1] http://lists.qt-project.org/pipermail/development/2013-December/014702.html _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
