Hey,
Maybe I missed something, but this seems more like a solution to manage
QML resources and modules that you know about at compile time.
I'm talking about a runtime problem. Lemme try to explain with some
simplified code. Allow me to leave a link to some markdown and syntax
highlighted stuff:
https://gist.github.com/ruilvo/43365e67f6d3ea472531738fd5a52793
best regards,
Rui
Às 07:26 de 14/09/2021, Ulf Hermann escreveu:
Hi,
The problem to discuss:
* An application that wants to be extendable via plugins.
* These are found and loaded at runtime.
* Not all of them are used at the time.
* The plugins require non-trivial UI, that they ought to "bring
themselves".
* During the runtime of the application one plugin can be disabled and
another one enabled, and their respective UI should be replaced in
the application window.
o Ultimately, think that they can be chosen on a combo-box.
[...]
Now, the question: How would you approach the same problem in QML?
I've read around that creating objects for the Quick engine is an
anti-pattern. So, do you have examples, or suggestions, how to
achieve this kind of design?
You're talking about QML modules. There is a new blog post about those
[1], and I'm just writing another, more in depth one, about the same
topic.
[1] https://www.qt.io/blog/introduction-to-the-qml-cmake-api
best regards,
Ulf
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
