Hi,
I'm currently refactoring our QML compilation units to avoid storing
engine-specific data in the global type registry since that is dangerous
and bug-prone. See e.g. QTBUG-120189.
This effectively means that you will be able to re-use compilation units
between different QML engines. On the surface that is great because your
QML engines won't re-compile the same code over and over. However, there
are certain attributes to QML engines that can make them produce
different QML components from the same code:
1. Import paths. You might store different modules with the same URI in
different import paths and make them available selectively to only
select engines in your process.
2. File selectors (or more generally URL interceptors). You can re-write
URLs any way you like and you can assign different interceptors to
different engines.
3. Network access managers. You can implement the same URL scheme in
different ways between different engines.
Different import paths can be useful in reality for versioning of QML
modules, but you should certainly not use different versions of the same
module within the same process. Using different file selectors or
different network access managers between QML engines running in the
same process sounds rather obscure to me.
Now when I'm done with the refactoring, if you do such things, one of
your engines may dig up components compiled by one of the other engines
with the other engine's settings. That's bad. However:
1. I believe the use cases for this are rather few and far between.
Please correct me if I'm wrong.
2. Since we already have a type registry that currently stores fully
engine-specific compilation units, I'm sure there are plenty of bugs in
this area that already do turn up the wrong compilation units if used in
such a way.
3. Different components will also produce different property caches and
ultimately different metaobjects. Those are fundamentally global already
and should give you plenty of problems if you're doing this.
In conclusion, I will go ahead with the changes. In addition, I will
probably add static versions of those settings (import paths, URL
interceptors, network access managers) and deprecate the engine-specific
settings, so that you can't accidentally mess this up either.
best,
Ulf
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
