This commit replaces the default (cgo) binding with a cgo-less one, which was generated by setting "QT_GEN_GO=true" prior running qtsetup.
The cgo-less version is still experimental and also lacking integration with most of the advanced features provided by qtmoc and qtrcc, but it should already be sufficiently stable and cover a great part of the basic features.
The intention for these changes are to simplify and speedup onboarding of new users, speedup development circles of existing users, simplify the usage of this package in a go module context and also to have the portable therecipe/qt runtime (http://github.com/therecipe/box) tested more broadly.
Also since this version removes all dependencies on cgo, one is now able to "go get" an project that makes use of therecipe/qt like this: ("go get -ldflags="-w" github.com/therecipe/examples/basic/widgets && $(go env GOPATH)/bin/widgets") without any additional requirements.
this commit introduces the new experimental `interop` module, which is used to allow the use of `therecipe/qt` from languages other than go or javascript.
as a start, there was support for the dart language added (currently only in combination with a custom flutter embedder engine, but plain dart support should follow soon).
the interop module makes great use of the qml/js interop functions and logic that were written to make `https://github.com/therecipe/entry` possible.
additional languages that are planned to be supported in the near future are: swift, kotlin and haxe (maybe with support for the c#, python and java targets, but if this isn't possible in some clean way then these languages will receive standalone bindings as well).
people using `therecipe/qt` from these new languages should then be able to use flutter (and dart) in combination with qt (and go/js) through this binding and also be able to easily communicate across the language barriers with the help of the interop functions.
the interop engine theoretically also makes a cgo-less `therecipe/qt` usage possible, which could be used to workaround the ever growing annoyances that are experienced when using cgo projects in combination with go modules.
the code for the custom flutter embedder that was created to make the flutter/dart binding work can be found in the `flutter` module. it currently only supports debug builds for the desktop targets, but if there is enough interest, then it shouldn't be too difficult to make release builds there, and on the mobile targets work as well (or even on "embedded" systems such as an raspberry pi for that matter).
an example repo how to use the new flutter/dart binding, will be published in the next few days.
These changes introduce two new functions called (*qml.QJSEngine).NewGoType and (*qml.QJSEngine).ToGoType, that can be used (similiar to how core.NewQVariant1 and (*core.QVariant).ToGoType can be used) to convert Go objects and functions to *qml.QJSValues and vice versa.
This allows for a more natural communication between Go and Qml/JS and makes it possible to simply pass a Go structs to Qml/JS and then call Go methods on that object.
For this to work, the object passed to Qml/JS needs to implement the `Pointer() unsafe.Pointer` and `SetPointer(unsafe.Pointer)` functions atm.
Which means, since all Qt classes already implement these functions, that you can now use the whole binding from Qml/JS as well and theoretically create a full Qt application inside an QJSEngine as well. A few example applications almost entirely written in JS can be found here: https://github.com/therecipe/examples/tree/master/js/
Furthermore, the `widgets_playground` example (https://github.com/therecipe/widgets_playground) now fully works on desktop and mobile targets as well.
other changes:
* core.NewQVariant1 and (*core.QVariant).ToGoType now recognize json tags
* workaround for qtmoc issue related to named imports
* speed-up go module android docker deployments
* fix webengine related qtdeploy bug on macOS
* fix int overflow issue for arm docker images
* fix js docker images
The cgo files are now generated by parsing the Makefiles generated by
qmake.
This greatly simplifies the support for additional targets, and also
removes the need to maintain extra backward and forward compatibility
code.
But these (backend) changes needed to come along with some breaking
changes to the (fontend) tooling.
So there is now the need to always specify the target when you use
qtmoc, qtrcc or qtminimal.
Some other minor breaking changes were:
The moc and rcc files are not automatically removed anymore by qtdeploy.
Because qtdeploy now has a -fast flag to make used of these cached
files.
The use of docker is now specified by using the -docker flag.
And the docker images were renamed to make their use case more clear.
