So, let's add traffic to the list.
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.
In the Widget's world I found a very comfortable way to make this.
Basically, the plugin class (the one that has the `Q_PLUGIN_METADATA`
macro) has a member like `QObject* getAnObject();` so that an "instance"
of that plugin is created, And that object has a member like `QWidget*
getMyWidget();`. Thus it's very easy to instanciate the "backend" of the
plugin, and request its "frontend". Amongst other things, since the
object creates its widget, it can connect signals between them as
needed, and/or store mutual pointers to call functions. It's easy to
just that add that widget from `getMyWidget()` somewhere to the layout
of the main application and that's basically it.
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?
Thanks!
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
