Le mar. 5 nov. 2019 à 16:03, Thiago Macieira <thiago.macie...@intel.com> a écrit :
> Ah, that's a good point. If the clipboard requires two-way communication > beyond just an initiation event, it'll never work to use it from the same > process, so long as the event dispatching is in the same thread. > > And the next issue is that it is not possible to have CEF running its own thread either using the `multithreaded_message_loop` or manually by calling CefDoMessageLoopWork() from another QThread. In both cases UI events gets called from Qt main thread and CEF thread. And I end up with calls to Qt internals from the CEF thread of calls to chrome internals from Qt thread. And bad things happen. Still I am curious of why a QWaitCondition was used, and not another solution that would have kept event processing enables during the wait.
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
