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

Ulf Hermann ulf.hermann at qt.io
Mon Jan 8 15:01:31 CET 2024


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


More information about the Development mailing list