Add Qt6 QStateMachine

[krya-kryak]

Closes #599 (supposedly)

Not tested yet

[krya-kryak]

Just to be clear: bindings were generated within a debian bookworm docker container, ran with the image built from docker/genbindings.Dockerfile. Naturally, they were generated against Qt6.4

[mappu]

This looks fantastic, thank you @krya-kryak !

The CI pipeline verifies that the bindings can be identically generated from source, so everything looks good there.

• We should test that it works - can you add a mini test app into the examples/libraries/... directory? It doesn't have to do anything useful, just instantiate a class and see if it compiles OK.
• There's a minor merge conflict because another library was also added to config-libraries.go, it should be easy to resolve

[mappu]

One more thing - right now genbindings.Dockerfile is unable to compile the new Go package subdirectory because it doesn't know what CFLAGS to use - you need to manually add a cflags.go file to each of the new directories, that has the pkg-config statement in it for the new libraries.

Check out any other subdirectory for an example, they all have one,

[krya-kryak]

There's a minor merge conflict because another library was also added to config-libraries.go, it should be easy to resolve

rebased initial commit onto current master, re-built everything

you need to manually add a cflags.go file to each of the new directories

done

We should test that it works - can you add a mini test app into the examples/libraries/... directory? It doesn't have to do anything useful, just instantiate a class and see if it compiles OK.

Added a basic example (program runs without issues), and this where things got complicated: QStateMachine seems to be more or less useless without the ability to use QSignalTransition, and as far as I can tell currently signal names for QWidgets are not exposed to go code. Am I missing something? Do you see a way to invoke https://doc.qt.io/qt-6/qstate.html#addTransition-2 ?

[rcalixte]

Do you see a way to invoke https://doc.qt.io/qt-6/qstate.html#addTransition-2 ?

Have you tried using Qt's C++ syntax for the signal parameter? For a QPushButton, that would be either clicked() or clicked(bool) or textChanged(QString). For this module, I want to try porting one of the existing Qt examples and this is my thought process for this. As bindings, I don't think we can trivially expose passing a pointer to member functions so deciphering this override syntax is particularly vital.

EDIT: I was able to get a test working with QObject::connect (variant Connect2). I used a pair of QDoubleSpinBox objects and "&valueChanged(double)" as both the signal and member parameter values worked correctly. The callbacks for each object needed to be configured for each signal. For some reason, I can't seem to get this working with Go despite the signals being accepted as valid. (When invalid, warning messages are emitted.)

EDIT 2: I also wasn't able to get it working by invoking Connect2 with unsafe pointers.

[rcalixte]

Do you see a way to invoke https://doc.qt.io/qt-6/qstate.html#addTransition-2 ?

Looking at this again, why not use https://doc.qt.io/qt-6/qstate.html#addTransition-1? Can you create a QSignalTransition, invoke setSenderObject, setSignal, and setTargetState, and then try addTransition? I'm curious to see if the same signal issues persist or to determine if this is a viable workaround.

I was able to port this example with some tweaks that I thought were improvements but it translates very well as is.

[rcalixte]

Hi @krya-kryak, I hope you don't mind but I went ahead and ported the upstream example since I'd already written it. If you merge the pull request I opened against your repository, it will update this pull request and we should be good to go. The module works well and the example makes use of the functionality you were concerned about. Thanks for working on this!

EDIT: There's also a fix for the scxml cflags.go just updating the package name. Now we should be good to go!

[krya-kryak]

First of all, I have to apologize for being quite late to reply here, didn't get to spend the time required to follow up.

Secondly, Rick, your idea is amazing. I never would have come up with it myself, having near zero Qt experience myself. I took a look at your changes and merged them into my fork, so everything could be reviewed in a single PR. Thank you!

I guess it's time for @mappu to press the big green button :)

[rcalixte]

It looks like I spoke too soon. The generation for SCXML is failing due to the generation of Loader::load. The pointer to the QStringList and in a virtual function no less in particular is troublesome. Our options in the short-term are to try to implement it, block just the method, or remove the entire SCXML module (since I don't know if it can work without the Loader class). If you only need State Machine, the latter two are the quickest options to at least get the PR into good shape. I know SCXML is related and the installation package is the same but given that it is not part of the Qt 5 binding, maybe it is okay to remove for now?

[rcalixte]

@krya-kryak The reason looks like because Qt SCXML was not packaged with Qt 5 on Debian even though it was part of Qt Core before being separated, just like Qt State Machine. Are you comfortable removing the SCXML configuration from config-libraries.go and then regenerating and pushing that here? We'll need to get this sorted one way or another before the CI will pass and so that this can be merged.

EDIT: It looks like the rest of the class will work fine. Blocking the method will be enough.

[rcalixte]

@krya-kryak One more and I think we're actually in the clear this time: krya-kryak#2. :)

EDIT: The CI failed... so let's try something different.

[rcalixte]

@krya-kryak Sorry, I was checking the module deeper and it is problematic in many areas. It is going to require a series of patches beyond those. It's best to remove that module for now. Sorry for the overhead. If you want to revisit this in the future, make an example that calls into the SCXML module and each of the issues will recursively become apparent.

[rcalixte]

We can remove SCXML for now and revisit it another time. It can be an opportunity for someone who wants to have a little fun. :)

krya-kryak#3

[krya-kryak]

We can remove SCXML for now and revisit it another time. It can be an opportunity for someone who wants to have a little fun. :)

@rcalixte Once again, thank you for the amazing work you've done here. Please excuse me for including scxml in the first place, throwing it in seemed like a simple thing to do. God, was I wrong :)

@mappu
Rick has done all the work here. Qtscxml is surgically removed for now, and CI should turn green, I believe.

[rcalixte]

@krya-kryak We all started somewhere! Thanks for your work on this!