Hi, I don’t necessarily want to walk into the specifics of that feature of this change - more that I think compatibility is something that should be considered very valuable - to the point that prior to starting work on refactorings that break compatibility (in behavior in this case), there should be an option on the table to opt in or out of the new behavior. Otherwise, you are pushing the problem onto the users. The bigger the user’s codebase, the higher the chance that the changes will have unwanted impact. I feel qtdeclarative is particularly exposed to compatibility breakage-as-a-default… I wish it was the exception rather than the rule.
For this particular issue, I do think unittests that use QQmlEngine with different import paths are very common and useful. And you can’t make any assumptions about static networkaccessmanager or URL interceptors IMO. The number of replies to threads in this mailing list also suggests that the quality of empiric data is kind of low, so I’m not sure how to conclude if, fex, nobody can share use cases… 😊 Andreas Tir 9 jan 2024 kl. 10:49 skrev Ulf Hermann via Development: > So, to clarify this some more ... If: > > 1. you use _multiple_ QML engines in the same process at the same time, > 2. you have _different_ import paths, plugin paths, URL interceptors or > network access managers for those engines, > 3. you rely on those engines to produce _different results_ for the > _same QML documents_ as a consequence, > 4. this actually _works_, > > please let me know more about your use case! > > Using multiple engines A, B, ... sequentially where you only start > accessing the type registry from engine B after engine A has been > destructed does not count since engine A will clean up after itself. > > From my point of view, looking at the source code, such a scenario is > rather unlikely since the global type registry should get in your way. > However, if it exists, I will consider it in my refactoring. > > 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
