3 ms·
There is go-ui here: https://github.com/visualfc/go-ui https://github.com/visualfc/go-ui It is unmaintained and has some very serious issues with 64-bit clean
by georgemcbay 13y ago
There is go-ui here:
https://github.com/visualfc/go-ui https://github.com/visualfc/go-ui
It is unmaintained and has some very serious issues with 64-bit cleanliness (it assumes C int being the same size as Go int, but C int is virtually always 32-bit whereas Go int is either 32-bit or 64-bit depending upon GOARCH).
The same author has another project here which was meant to be a second pass at this (from what I can tell):
https://github.com/visualfc/goqt https://github.com/visualfc/goqt
But as far as I know nothing was ever released on that project.
The approach used here of exposing QML is the most practical one, IMO. The Qt API is huge (not to mention C++ as opposed to C based) and creating a monster wrapper around it in Go is no easy task (especially if you wanted it to feel like Go) and would be a bear to maintain. Sticking with QML gives you a much smaller surface area to worry about while still giving you most of the benefit of using Qt as a GUI toolkit (at least with Qt 5.1+).
- niemeyer 13y agoThe main reason why the Go support was done in this fashion is that developing applications in such a declarative manner seems to be a better experience despite any difficulties in creating the tooling.