Add Qt 6 Qml

[VelorumS]

I'm not sure about the use of QNetworkAccessManager* by Qml. Looks like just a pointer, not a full dependency on Networking. Maybe there is an easy way to fix it?

And more generally:

How defining QML types from Go would look like?

How to build QML modules for those types? (the CMake qt_add_qml_module())

Other things in this PR:

• helloqml6 example
• gitignore vscode
• Manjaro install commands

[mappu]

This looks fantastic. Thank you for contributing!

Fixes: #60

I think blocking the networking types within Qml is the right move for now. I expect the way to make it work is to parse the qml package after the networking package, so it can detect types and set up the imports, but that does mean importing qt6/qml will always cause importing qt6/network. The current package structure isn't really set up for partial/optional dependencies: this has also been an issue for e.g. QWebEngine, which has some minor dependencies on QML types, creating a package dependency that you otherwise don't want.

The next move is probably splitting the headers into two with build tags (#185) or moving some into a qml_and_network/ directory, ...

How defining QML types from Go would look like?

@arnetheduck explained it to me once, it involves defining a custom qMetaObject and doing the equivalent of a runtime moc for it, but I think this will require a lot more work to expose the type out to the Qml side. Anyways, this is a good start.

How to build QML modules for those types?

qt_add_qml_module in cmake packs the .qml source code into a .qrc resource bundle. You can do the same thing and use qrc/rcc resources with miqt (see miqt-rcc), but it's probably easier to go:embed the qml file and use QQmlApplicationEngine::loadData to load it.

[mappu]

Works on my machine. 👍

The qt6-declarative-dev is sufficient at compile-time, but in order to run this example Debian packages all the runtime qml modules separately, so i'm just going to push an extra commit for the README.

[arnetheduck]

seaqt indeed already exposes QML - there's a few more things to add to the block list to ensure everything compiles:

https://github.com/seaqt/seaqt-gen/blob/542f61c57a7a35f7e964e28f1d120b9a0ff6174c/cmd/genbindings/config-allowlist.go#L618

A useful test is to compile all generated c++ files, to catch any such stragglers (if this was part of the Makefile, it could easily be added to CI as well).

Some of these are from the opengl parts that you ultimately also must wrap / support to get coverage for the QML api:

pkg-config --libs Qt6Quick
-lQt6Quick -lQt6QmlMeta -lQt6QmlWorkerScript -lQt6QmlModels -lQt6OpenGL -lQt6Gui -lQt6Qml -lQt6Network -lQt6Core

Binding the Qml library allows you to more or less open existing qml files and inject trivial values. That's not much, because most qml apps eventually need to create QObjects that QML consumes - for that, you indeed need to be able to expose meta-object description - not sure about go, but in languages with sufficient compile-time capabilities (ie c++11+, nim, rust etc) such things are done with templates/macros but can also be done with a codegen. There's also the option to do this dynamically (a bit like qt-dbus does it), but you lose out on some features. seaqt/seaqt-gen@f279db8 exposes some of the plumbing needed for this (metacall and staticMetaObject above all).

You also need access to some private data when generating these - seaqt/seaqt-gen@755c203 is a trick to get access - in fact, this void* trick is broadly useful in wrappers for any private type because often you just need to pass an existing pointer around (happens both in qml and qmetaobject) without understanding it.

The other thing you'll find yourself needing soon is the ability to connect signals for the objects you've exposed - here, you need access to some private qt headers (the same that Qml uses, incidentally): https://github.com/seaqt/seaqt-gen/blob/542f61c57a7a35f7e964e28f1d120b9a0ff6174c/libseaqt/libseaqt.cpp#L17

I'd love to see the above things backported to miqt, but they all require someone to look at the corresponding go code as well.

[VelorumS]

A useful test is to compile all generated c++ files, to catch any such stragglers

Ok, I'll need to do at least that for this PR.

Exposing Go objects to Qml is a separate story. The oldest Go qml.v1 library looks the best from the user's point of view. By looking at that and seaqt-gen, it's probably possible to develop those bindings.