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.
* speedup js binding generation + minor js related fixes
* support for private quickcontrols2 classes with `QT_GEN_QUICK_EXTRAS=true`
* fix for static linux deployment issue
* minor example updates
* fix for minor qtmoc docker related issue
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
* fixes for Go 1.13 + retain go module 1.12 GOPATH behavior for internal/examples
* update docker images to 5.13.0
* new docker images (windows_64_shared_512, linux_512, darwin_512)
* update examples to match the Qt 5.13 api
* bump android minSdkVersion to 21 (5.0 / lollipop)
* bump OpenSSL version for android docker deployments to 1.1.1a
* let the binding use the 513 env by default
you can use QT_VERSION=5.12.0 and/or QT_API=5.12.0 to keep the binding backward compatible with your code
just setting QT_API=5.12.0 alone should also be sufficient to keep docker deployments working
if you did install an official Qt version then just set the correct QT_VERSION and procede as usual
* various minor fixes and cleanups
* support interface{} returns for js/wasm
* fix android builds on darwin
* support for the virtualkeyboard module
* fixes for docker image builds
* cleanup callback handling
* fix possible moc memory leaks
* new virtualkeyboard examples
* js/wasm GOCACHE fix for Go 1.12+
* make use of the official Go 1.12 wasm build and replace js.NewCallback with js.FuncOf
* update docker images to Go 1.12.4
* revive raspberry images
* fix raspberry related bundling issue
* add the multimedia module to the raspberry images
* fix raspberry related QT_API issue
* remove unecessary *char to []byte copy overhead in some unlikely cases
* fix Qt install script
* initial partially support for Felgo (former V-Play) on darwin
* fix charts/audio example and darwin
* fix common/widgets_demo example on iOS (issue #451)
* fix widgets/renderer memory leak
* fix possible QT_PKG_CONFIG + QT_VERSION race condition
* fix static linux docker image
this is the start of series of a few incrementally breaking changes, mainly started to remove the uneccessary conversion of []byte to string or vice versa on your side
the few functions accepting *string will also be affected the future
functions generated by qtmoc are not affected
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.
1. the qt api changed in various places
2. dropped the "_minimal" suffix for the deployment folders
3. to keep using older versions of Qt (5.7.1 for example), one would
now need to explicit export "QT_VERSION=5.7.1" and also
"QT_DIR=/path/to/Qt5.7.1"
