> > On Sunday, 28 October 2018 08:58:57 PDT Jeffrey Brendecke wrote: >> Is it possible to have a 100% native UI (Cocoa or UIKit) with backend QtCore >> components (nonGUI) on a functioning event loop for signals and slots on >> macOS and iOS? > > Sure. But you need to integrate the event loops, so one of these three things: > > 1) use the Core Foundation event dispatcher (and make sure it works) > > 2) tell your native UI event dispatcher to use QSocketNotifier and QTimer > > 3) write an event dispatcher deriving from QAbstractEventDispatcher that > integrates QSocketNotifier and QTimer with your native UI's dispatcher > > The event dispatcher you really want is called QCocoaEventDispatcher, but > it's > in the Cocoa QPA plugin, which requires QtGui. > >> For example, I would like use the Qt network components to interact with a >> network while using only native windows and native views for the >> presentation. > > Option 4: only use Qt components outside the main thread. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest
----- Thanks, Thiago, Regarding: 1-3, I was afraid something like that would be the case after looking at the Qt-Mac integration code. Option 4 looks like a possibility for me. It looks like it means that as long as I run QCoreApplication::exec() on its own thread, that I can do all the Qt event handling/signal slot connections I want on that thread and not worry about what's going on on the main thread/Apple event loop until I need to synchronize data with the main thread. Then, it would be nothing more than what is normally involved with synchronizing data between threads. Is this correct? Thanks in advance, Jeffrey _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
