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

[Andreas Aardal Hanssen]

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?

Andreas - in favor of Qt keeping its compatibility promises

Man 8 jan 2024 kl. 15:01 skrev Ulf Hermann via Development:
> 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240108/ca7c102a/attachment.htm>