
QML support for Golang - jcastro
https://plus.google.com/107994348420168435683/posts/54Q8NwbRwng
======
actf
Very cool, QML is a very promising GUI development language. I'm a huge fan of
declarative UIs, and QML is great for this. For those that have experience in
WPF, QML is actually very similar.

My main complaint about QML is that it really needs to ship with some desktop
widgets. Without common desktop widgets, developers are forced to basically
reinvent the wheel, and redefining common controls using primitives like
rectangles, text, etc. Once this problem is solved though I really hope QML
will take off in a big way.

~~~
georgemcbay
Have you used QtQuick (particularly the QtQuick.Controls package) in Qt 5.1+?
Because based on what you wrote I believe it covers a lot of what you're
asking for here.

~~~
actf
Thanks, I haven't seen that yet. It does look promising. I was vaguely aware
that work was happening on these features, but I wasn't aware of their current
state.

Unfortunately it doesn't look like these are available yet in Python, as
Python doesn't seem to have bindings for QtQuick 2.1, at least based on my
googling. Hopefully that will come soon though!

~~~
bbernoulli
From Phil's annoucement on the mail list, it seems PyQt5 does have full Qt 5.1
support (except for QtSerialPort and QtSensors)

(and the latest installer tagged Qt5.1.0 contains a QtQuick.pyd)

------
asb
LGPLv3 is going to make some people unhappy (Qt5 itself is LGPLv2.1+).

~~~
georgemcbay
It does include a special exception not requiring source code release of
combined worked, but still I agree that having it be LGPLv3 even with the
exception will hurt its adoption with the wider Go community. The vast
majority of widely used 3rd party Go libraries just use the standard Go
license here:

[http://golang.org/LICENSE](http://golang.org/LICENSE)

Using that license just leaves things totally clear and unambiguous, if you're
using the language you must already be okay with the license. I've worked with
a number of companies that just don't want to touch anything *GPL with a 10
foot pole in Go where static linking is non-optional other than over a CGO
bridge (which makes Qt's own LGPL usage palatable). This may be a sticking
point for them even with the exception (just because of the extra work
required in getting legal clearance, not because the license as written
actually harms them).

License aside, this is a pretty great library and this is what I think is the
most practical solution to providing a cross-platform GUI solution for Go in
that it puts all the heavy lifting of platform independence on Qt without
having to expose the entire large Qt API to Go via wrappers.

I was actually working on something like this a few months ago (mentioned in
HN comment:
[https://news.ycombinator.com/item?id=6055043](https://news.ycombinator.com/item?id=6055043))
but got side-tracked due to serving jury duty on a 6 week trial (ugh). This
solution is a lot further along and benefits greatly from Go 1.2 support of
compiling cpp files in CGO (mine was being written against Go 1.1 and required
an extra intermediate static library build step). I may possibly continue
working on mine anyway just to side-step the licensing issue altogether
(which, again, I think is more of a perception problem than an actual
practical problem, but still a problem).

~~~
niemeyer
Although I respect whatever decision you make, please note that there's
absolutely nothing I could use as an argument for a license change there,
other than "George will work on something else if we don't change it.", which
is pretty hard to sell. If you do have valid arguments, please mail me with
them so we can have a more focused conversation on actual issues.

And by the way, Qt is also LGPL, so not wanting to link with LGPL software
when working on linking with LGPL software is also a curious choice.

~~~
joelwilliamson
Qt is dual licensed so a company that isn't willing to GPL their software can
pay for a license that allows distribution without releasing source.

~~~
niemeyer
You don't have to GPL your software to use LGPL.

------
gregschlom
That's awesome. QML is a really incredible piece of technology. I had a lot of
fun building a cross-platform desktop app all in QML back in 2010
(www.betterinbox.com)

I wish some ideas from QML made their way to the web. The anchor system, for
example, is really powerful for layout.

~~~
zanny
There are attempts in the kde scene to (since they are transitioning to using
blink in qt, and rekonq already uses v8 as its js engine) enable the running
of qml apps via url in the browser. In effect, it is a side by side engine
right next to blink to run qml apps and both share v8 on the backend.

------
djhworld
Will this mean I can create GUI applications with native look and feel (i.e.
native looking widgets) across all platforms?

~~~
zanny
Assuming this is just golang bindings for qml, yes. If they reimplemented
qmlscene or any of the moc, possibly not. Also consider qt does not have
finalized ios support yet, and the qml components aren't done yet. For pretty
much every other qt platform they are, though.

It also requires a Go compiler that works with your preffered platform. I'm
not sure on the availability of Go compilers for ios or Android.

~~~
zachlatta
From talking to a friend at Google, I know that there is a way to get Go
running on an iPhone. I don't know the specifics though.

------
dvirsky
I'm hoping this will make one thing easy enough to be worth the effort: a
proper UI for GDB debugging Go code.

------
devx
What about Go support for Qt native?

~~~
georgemcbay
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
The 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.

