[Development] Multiple QML engines with different import paths, file selectors, etc

[Mike Trahearn]

“When we get qmltc and qmlcachegen into a shape where the code generated
by qmltc can directly call the functions and expressions compiled by
qmlcachegen we won't need much of an engine anymore if you exclusively
run pre-compiled code. “ - Ulf

I very much can’t wait for this as I have run into QML Type -> qmltc -> c++ -> QML_ELEMENT != QML Type…
See Support Case 00495291<https://account.qt.io/s/open-requests> > QTBUG-96040<https://bugreports.qt.io/browse/QTBUG-96040>

Mike

From: Development <development-bounces at qt-project.org> on behalf of Ulf Hermann via Development <development at qt-project.org>
Date: Wednesday, 10 January 2024 at 3:36 am
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Multiple QML engines with different import paths, file selectors, etc
> Hi, have you considered how you can keep compatibility, by making this
> change either opt-in or opt-out? Since it seems the refactoring is
> already done, it feels like you are making a bet that only has a
> negative outcome for those porting/trying to keep up. 😊 Good for
> maintenance, bad for users?

OK, I'm convinced. My experiments have unearthed lots of "interesting"
behavior, but the basic example of having two engines with different
import paths both load some document works. That is, the resulting QML
types are indeed different. So I've dropped
https://urldefense.com/v3/__https://codereview.qt-project.org/c/qt/qtdeclarative/*/527526__;Kw!!Nbma_1s!oGtA0J1smu9_rufRextfa8apKb1kLi9UWAq9F34jkRfgV-h2iKwY17lrIqUEvpCoksS55aqNx-I-HjPF7oUhsFC9sA$<https://urldefense.com/v3/__https:/codereview.qt-project.org/c/qt/qtdeclarative/*/527526__;Kw!!Nbma_1s!oGtA0J1smu9_rufRextfa8apKb1kLi9UWAq9F34jkRfgV-h2iKwY17lrIqUEvpCoksS55aqNx-I-HjPF7oUhsFC9sA$>  - the
change that makes compilation units visible across engines. The
refactoring for splitting the compilation units in a way that eliminates
engine pointers from the global type registry is still a good idea, but
it can be done without any functional changes.

The minimal fix for QTBUG-120189 is to double check the engine-specific
type loader for any property type added to the property caches. This
isn't pretty but it does the trick. See
https://urldefense.com/v3/__https://codereview.qt-project.org/c/qt/qtdeclarative/*/529215__;Kw!!Nbma_1s!oGtA0J1smu9_rufRextfa8apKb1kLi9UWAq9F34jkRfgV-h2iKwY17lrIqUEvpCoksS55aqNx-I-HjPF7oXOXU2Lyg$<https://urldefense.com/v3/__https:/codereview.qt-project.org/c/qt/qtdeclarative/*/529215__;Kw!!Nbma_1s!oGtA0J1smu9_rufRextfa8apKb1kLi9UWAq9F34jkRfgV-h2iKwY17lrIqUEvpCoksS55aqNx-I-HjPF7oXOXU2Lyg$>

In the long run, we have to untangle this somehow. You can't have
different types for the same document in different engines and _also_
store all of this in a global type registry that assumes you have a
unique type for each URL. Currently this assumption is enforced in some
places but deliberately avoided in others.

When we get qmltc and qmlcachegen into a shape where the code generated
by qmltc can directly call the functions and expressions compiled by
qmlcachegen we won't need much of an engine anymore if you exclusively
run pre-compiled code. When running the QML code through the interpreter
or JIT we might then duplicate the type registry for each engine and
isolate the type registries against each other. Those could then be
safely used with custom import paths, URL interceptors etc. That's still
quite a way to go, though.

best,
Ulf
--
Development mailing list
Development at qt-project.org
https://urldefense.com/v3/__https://lists.qt-project.org/listinfo/development__;!!Nbma_1s!oGtA0J1smu9_rufRextfa8apKb1kLi9UWAq9F34jkRfgV-h2iKwY17lrIqUEvpCoksS55aqNx-I-HjPF7oVYNqVo1w$<https://urldefense.com/v3/__https:/lists.qt-project.org/listinfo/development__;!!Nbma_1s!oGtA0J1smu9_rufRextfa8apKb1kLi9UWAq9F34jkRfgV-h2iKwY17lrIqUEvpCoksS55aqNx-I-HjPF7oVYNqVo1w$>
Confidentiality Notice: This message (including attachments) is a private communication solely for use of the intended recipient(s). If you are not the intended recipient(s) or believe you received this message in error, notify the sender immediately and then delete this message. Any other use, retention, dissemination or copying is prohibited and may be a violation of law, including the Electronic Communication Privacy Act of 1986.   ­­
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240109/af1dd0b6/attachment-0001.htm>