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@qt-project.org > https://lists.qt-project.org/listinfo/development >
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
