Add QML module

[TobiasFella]

This is required for some tooling - qmlls, qmllint, etc. - to work correctly. It also improves qml compilation in the clients

[vkrause]

Thanks, that would avoid doing this in the client code in Itinerary as well :) One additional type we have exported there is KeyVerificationSession (uncreatable, just for its enum values).

[TobiasFella]

This adds a dependency on QtQml and makes the dependency on extra-cmake-modules non-optional.

We could make the module optional to build (in this case, i would prefer building it by default and having an opt-out option, to make it harder for distros to build without qml by mistake).

We could also keep extra-cmake-modules entirely optional by bundling the necessary files, but i wouldn't like that.

@KitsuneRal what do you think?

[KitsuneRal]

QtQmlIntegration rather than QtQml? Or is QtQml a dependency of the ECM module?

[KitsuneRal]

I actually started doing something similar without ECM but the finicky QML module machinery have always put me off. If ECM can help with it (as I can see), great - but I don't quite get why it would need entire QtQml for that.

[TobiasFella]

right, it's QtQmlIntegration, not QtQml

[KitsuneRal]

QtQmlIntegration is tiny, literally just a few macros in a header file. And I already endorsed ECM previously, so let's make it.

[TobiasFella]

Cool. In that case, I think this is ready. It doesn't register all the types that we use anywhere in QML, but that doesn't block us from using it

[KitsuneRal]

Add ECM to CI as well, please :)

[KitsuneRal]

1. Can't we just install ECM from the package repo?
2. The way it's used atm, it does try to get a hold of QtQml. I'm fine if that's only necessary as a build dependency; not sure if it's only a build dependency though.

[KitsuneRal]

Petty things.

[TobiasFella]

Can't we just install ECM from the package repo?

On linux yes, but not on win / mac

[TobiasFella]

And of course ECMQmlModule needs qt6_policy, which is only available from qt6.5

[KitsuneRal]

We could probably look into bumping the Qt version requirement to 6.6 or even 6.8 - Ubuntu 24.04 was the primary reason I sat on Qt 6.4. By now it's relatively old and I think we should move on anyway.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[KitsuneRal]

This is unfortunate:

❯ ldd libQuotientQt6.so.0.10.0 | rg Qt6Qml
        libQt6Qml.so.6 => /lib64/libQt6Qml.so.6 (0x00007f2cb9600000)

I know that the library is de-facto used with QML-based applications but I still hope we can keep the library rely on as little on-screen API as possible. And as I understand it, the reason is merely the fact that the ECM macro pulls in Qml and not QmlIntegration. Can we somehow go without that? Qt's own QML integration macros don't require Qml.

[TobiasFella]

Can we somehow go without that?

Yes; done now.

[KitsuneRal]

Okay, my packager's self is happy - I can understand having a separate library linking to Qt::Qml. We have that separate types.h file with all the QML-enabled types though, and maybe it's even a good thing, to have all QML integration-related things put in a common place.

But I was still under impression that it's possible to have a QML integration plugin only linking to Qt::QmlIntegration?

[TobiasFella]

I was under that impression as well, but I don't know what I'd need to do to achieve that

[KitsuneRal]

Heh. Guess we'll have to go with this for now.

Stale

[KitsuneRal]

Can we also have some basic test that the installed QML integration files are there and have something reasonable inside? Like grep a line in qmldir and *qmltypes... Just to make sure it doesn't silently fall apart, because right now QML integration is not checked at all.

[vkrause]

But I was still under impression that it's possible to have a QML integration plugin only linking to Qt::QmlIntegration?

The QML integration plugin needs the full QML library. What Qt::QmlIntegration enables is to have the annotations you now have as foreign types in types.h inline in the actual types, without linking the main library against Qt::Qml.

[KitsuneRal]

That's also my understanding. And I hoped to have it this way (i.e. with macros inline - it's actually more practical this way, harder to forget exporting a newly added class); but it seems that ECMQmlModule causes the library to link against entire Qt::Qml. Can you help with the right CMake incantations?

[vkrause]

The CMake code should stay pretty much as it is right now, apart from linking the main library to Qt::QmlIntegration. The ECM macros don't touch the dependency of the plugin, only the plugin itself.

[KitsuneRal]

@TobiasFella sorry but can we get back to using QML_ELEMENT and the company then, and try to make it work?