Just in case if anyone care, creation QQmlEngine in UI thread and then moving to background thread resolved the issue. Moreover QML debugger works with both threads!
2017-12-08 14:43 GMT+03:00 Alexander Ivash <elder...@gmail.com>: > Well, as I said it seems to be working, at least in very simple > scenarios, like reading file & doing JSON.parse from separate thread. > So, if this is artificial limitation of QML Debugger, then would be > great to get it fixed. Can I at least silence that assert by somehow > excluding QQmlEngine in thread from debugging? > > P.S. Yes, I understand that what I'm doing is against QML ideology > (make everything in C++, make UI-only in QML, bind C++ with QML etc. > etc. etc.) But sometimes you are just too lazy to write JSON.parse :). > Also, I would be more than happy to use existing WorkerScript but with > its current limitations it is a bit useless for all the scenarios > besides model update) > > 2017-12-08 14:32 GMT+03:00 Ulf Hermann <ulf.herm...@qt.io>: >>> What needs to be done to get rid of this assertion (is it possible at >>> all or QmlDebugger is always expect single QQmlEngine? ) >> >> >> You can have multiple QML engines attached to the debugger, but the current >> assumption is indeed that they all live in the GUI thread. This can probably >> be fixed, but are you sure that you don't hit any other limitations with >> this? For example, the type loader also does interesting things with threads >> and locking. >> >> br, >> Ulf >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
