What happened to the `QmlExtensionPlugin` example

[OlivierLDff]

I remember an example about it, but it disappeared after 0.5.
This is confusing to me what is the right way to write a "plugin" nowadays?

It seems cxx-qt is almost dealing with everything, all the symbols are generated, the QmlExtensionPlugin class, the qmltypes, etc... It just I don't understand how to make it a loadable plugin.

I'm happy with a cargo only build or a cmake based one.

Some use case

I want to introduce a new module to test cxx-qt for a cpp based project, but I want to make the changes as minimal as possible. So I thought the plugin approach sound nice.

What I've done so far

Everything I've tried is based of the qml_minimal example

• cargo only: build a dynlib, move the dynlib file in the same folder as where qmldir is located. I get rust/target/debug/build/qml_minimal-b6d7b9673e0f279f/out/qt-build-utils/qml_modules/com/kdab/cxx_qt/demo/libcom_kdab_cxx_qt_demo.dylib' is not a Qt plugin.
• Many variant from CMake
• Write my own plugin:

qt_add_plugin(example_qml_minimal
    cpp/plugin.cpp
)
target_link_libraries(example_qml_minimal PRIVATE qml_minimal_qml_module)

And in plugin.cpp:

#include <QtQml/QQmlExtensionPlugin>
#include <QtQml/QQmlEngine>

#include <qml_minimal/src/cxxqt_object.cxxqt.h>

class CoreQmlpluginPlugin : public QQmlExtensionPlugin
{
    Q_OBJECT
    Q_PLUGIN_METADATA(IID QQmlExtensionInterface_iid)

public:
    void registerTypes(const char* uri) override
    {
        qmlRegisterType<my_object::MyObject>(uri, 1, 0, "MyObject");
    }
};

#include "plugin.moc"

The latter works, but then I'm loosing the benefit of what cxx-qt is doing: automation (qml_element) and tooling files (qmltypes)

Conclusion

I feel I'm missing an obvious step somewhere. Using the keyword plugin doesn't yield any interesting issue here, or relevant doc in the book.

[ahayzen-kdab]

Hey, so there have been quite a few changes as you've spotted.

The main change has been that with Qt 6 in C++/CMake you now can use QML modules for declarative registering of QML types.

For example instead of qmlRegisterType<T>(uri, 1, 0, "MyObject"); you can now define this in the class itself with

class MyObject : public QObject {
   Q_OBJECT
   QML_ELEMENT  // <- this is the same as the qmlRegisterType
   ...
}

Then in CMake you can then define which files are part of a QML module and this is built to it's own .so and qmldir file by using qt_add_qml_module. This all has the advantage that then things like qmllint and qmlls can understand the QML types are they are all defined at compile time declaratively etc.

So considering this we changed the build system in CXX-Qt so that when you do the following it actually create a QML module with the uri com.kdab.cxx_qt.demo and uses the #[qml_element] attribute on the types in the Rust files to allow for a similar workflow to the C++/CMake route.

        .qml_module(QmlModule {
            uri: "com.kdab.cxx_qt.demo",
            rust_files: &["src/cxxqt_object.rs"],
            qml_files: &["qml/main.qml"],
            ..Default::default()
        })

Now what we currently do is we build the qml module and add it to the Qt resources, as modern Qt QML by default has an import path of qrc:/qt/qml so we can put the generated files in eg qrc:/qt/qml/com/kdab/cxx_qt/demo/qmldir and QML is able to find this. This is all then currently statically linked in so you don't actually see that a QML module is being created.

However this now limits us to static linked plugins effectively, as we are refactoring the build system ( #1125 ) we are trying to consider how you could also decide to build a crate to a shared library rather than static library and have a more typical looking QML module output. cc @LeonMatthesKDAB

But ultimately if you do need to create some kind of plugin and need custom code in the plugin it should in theory be possible to this right now

• create your own Cmake shared library/plugin
• have a Rust crate that provides the basic types linked to it
• write the C++ code for QQmlExtensionPlugin that uses the types exported from Rust to register them
  Then you should be able to have a normal shared library plugin.

[ahayzen-kdab]

So i think to summarise the usecase, as we rework the build system we want to make generating a shared library / plugin easier again so then you can keep using the #[qml_element] and have a .so and qmldir. Currently we build QML modules to a static lib and embed into the qrc files, so as you've found you'd currently have to write your own wrapper.

[OlivierLDff]

Thanks for the quick answer. I guess I should leave the issue opened? Or adding the plugin capabilities is already tracked somewhere else?

[ahayzen-kdab]

Lets leave it open for now, so we don't forget, we can merge it with another if we find one that is the same :-)