[Interest] Qmldir singleton with different QmlEngine and thread
Jérôme Godbout
jerome at bodycad.com
Fri May 8 15:56:50 CEST 2015
Hi,
I'm looking for some information on the behavior of the qmldir singleton
used by different QmlEngine and thread.
Here's my current usage:
- QmlEngine #1
- Main Qml script
- Many component
- usage Singleton A from custom Qml module AA with pragma
SIngleton and singleton usage inside qmldir
- usage Singleton B from C++ expose module
- Instantiate a object with QmlEngine #2 and ask him to run script
- QmlEngine #2 with it's thread
- Qml Script requested
- Many Qml Component here too
- usage of Singleton B from C++ is ok (C++ return a different
instance based on the QmlEngine).
- usage of Singleton A (make the application crash and tell me the
object inside the singleton does not belong to the proper QmlEngine).
My question is the following, is the QmlEngine #2 suppose to be aware of
the singleton instantiate from QmlEngine #1 under the hood (the engine #2
does not have any parent set and is move to a specific thread, where the
engine_ is QQmlEngine and thread_ is a QThread):
engine_->moveToThread(&thread_);
It clearly is aware but is he suppose to?
The sub script is running fine and allow me to do complex script running in
parallel until I I used a singleton made inside Qml script from (from C++
ok, since they have QmlEngine* ref to give a new instance).
Can someone shed some light on why does qmldir singleton does not get a new
instance per QmlEngine just like C++ is doing by receiving the QQmlEngine *
qml_engine, QJSEngine *js_engine as parameters to be given a unique
singleton back per engine.
Is the fact that I create the engine 2 inside an object that belong to
engine 1 that make this singleton cross exist between both engine even if
no parenting and thread affinity have been changed?
Is there a way to modify this behavior?
Thanks,
P.S.: before someone ask, WorkerScript ain't cutting it in many case (basic
type only are allowed to be transfer between thread) this is why we came up
with this solution and it's working wonderfully as long as the object can
be clone and no qmldir singleton are used. Would like to get ride of the
last limitation, the first one is conceivable and awaited.
Jerome
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150508/635d5a22/attachment.html>
More information about the Interest
mailing list