QML support for Golang | Hacker News Reader

QML support for Golang

plus.google.com

150 pointsjcastro35 comments

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.

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.

Here is an example of this: http://www.ics.com/blog/combining-qt-widgets-and-qml-qwidget...

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!

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)

The limiting factor on pyqt5 is the internal binding to the v8 switch of qml. So when that happens, you will get native look.

While I see the benefit of using python for brevity in areas Ecmascript doesn't cover (file access, pipes, io, etc) I'd personally just write whatever scripts I was going to use inline with qml as js, because I already can assume v8 is running underneath the platform, and js is pretty fast, so think about it as an interim solution. You can actually write whole qml apps that never compile and just run on the qmlscene binary (which is just a shim frontend to the qtquickengine internals of qt to run qml files).

Qt5 (the one the Go support is linked against) is already much better at that, and there's further work happening both upstream and in Ubuntu.

Hmm, your installation requirements mention the Ubuntu SDK.

Is it possible to just manually install relevant QT 5 development packages, and not use the ubuntu-sdk package?

It is. The ubuntu-sdk package is just an easy way to get all the dependencies in at once, but it should work even in other operating systems.

Does QML have Mac/iOS style constraints?

> For those that have experience in WPF, QML is actually very similar.

From a perusal of its Wikipedia page, I'd say it looks more like JavaFX Script.

WPF always resembled JavaFX Script also (both retained with data binding and animation support baked in), so its not very surprising.

Actually WPF is older than JavaFX Script.

I only said they resembled each other, nothing about who pee'd first.

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

If you know about someone that is actively trying to use it and cannot because it is LGPLv3, please ask them to mail me with more details. I'll be happy to go over the perceived issues with the legal team.

Cheers, it doesn't affect me personally - I just know from experience that some companies are vehemently anti-(L)GPLv3. It doesn't help that FUD is spread about it from both in and outside the FOSS community.

On this topic, Gustavo does note in comments that there's an exception for static linking

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

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) 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).

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.

To be honest, I probably don't have a better argument than what was already presented because I don't think LGPLv3 with the exception already given is a real practical problem, it is just a problem of companies not wanting to deal with uncertainty. I've run into this quite a bit in the real world, particularly with companies burned by using LGPL on iOS.

Go presents a similar issue to the iOS one in that dynamic linking of Go code to Go code is not an option (at least not without using gccgo), but it is easy to explain this away when using CGO linked code like Qt itself which lives in its own .so/.DLLs because they already understand that the dynamic link barrier shields them from the LGPL issues. But getting them to use Go code with LGPLv3 with exception that will statically link with their own Go code requires some direct involvement from legal/IP to "okay" it. Which could range from being a minor annoyance to a showstopper depending upon the company, in my experience.

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.

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

It's ok, there's an exception for static linking to create a Go binary.

https://github.com/niemeyer/qml/blob/master/LICENSE

> "As a special exception to the GNU Lesser General Public License version 3 ("LGPL3"), the copyright holders of this Library give you permission to convey to a third party a Combined Work that links statically or dynamically to this Library without providing any Minimal Corresponding Source or Minimal Application Code"

I'm not sure if there are any other issues with using LGPLv3?

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.

The anchor system predates QML by some time. Delphi 4 introduced anchors and constraints in 1998, for example.

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.

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

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.

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.

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

What about Go support for Qt native?

There is go-ui here:

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

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+).

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.

Just opinion, but if I were writing a new program on top of qt I'd always go for qml. The qt 5.x releases are rapidly fleshing it out, and you get guaranteed opengl, good scripting, declarative layout, and super easy accelerated animations and transitions. That and it has much less code overhead than raw c++, even when using it is also painfully easy with signals and slots.

The 5.1 controls module is 95% of the way there to fully native looking QML. At that point, qt widgets are just a fallback.

Reply on news.ycombinator.com