Show HN: Qt binding for Go with support for all major operating systems | Hacker News Reader

Show HN: Qt binding for Go with support for all major operating systems

therecipe.github.io

222 pointstherecipe74 comments

This was heavily discussed 5 months ago:

https://news.ycombinator.com/item?id=12928526

I'm a bit confused by the docker part and emphasis on deployment. Is that just for contributors/early adopters because theres no release yet, or is that just part of the flow of using this?

It depends on how much you want to embrace docker. In general you can use this binding without touching docker at all. But if you want, you can use docker in every step of the process. It starts with the minimal setup that just depends on Go + Docker. Then continues during development, so if you would want for example test your application on android really quick, then you would just need to pull the android image instead of setting up the android SDK, NDK and JDK by yourself. And then in the end you can use docker for your CI and CD processes as well. For example by creating your own docker images on top of provided ones.

I've been using c++/Qt for quite some time now, but i really prefer to work in go. Feels like i'm a lot more productive while writing, and i don't have to spend doubledigit minutes waiting for stuff to compile.

I recently stumbled over this project and have been using it quite a lot since. It works really well and coming from Qt-land it was really easy to use the provided bindings and generate the 'classes' for signals/slots. AND the docker images are great for cross compilation. They just work :). Thank you so much for working on this.

I recently tried out gold linker in a c++/qt project, and it nearly halved my compile time. I don't quite have incremental linking working yet, but I expect it to be even better.

thank you :)

I'm curious how this affects file sizes? I like my static binaries and portability, but I fear this would make things balloon quite a bit to get the same broad distribution.

I've been planning on using an embedded webkit + html app in an upcoming desktop project. Are there any resources for how difficult it would be to learn Qt and create a reasonable portable, easily downloadable app?

I'd take a look at QT Quick.

The file size depends on the target and what modules you use, for dynamically linked projects I would guess it's around 50mb for an average project. Maybe 20mb more on windows because of the icu libs, but those can be replaced with your own (much smaller) versions. Static projects may weight half of what the dynamic ones do, so maybe around 25mb. But depending on how much you care about file size, you could also compile your own static Qt version and then strip everything that you don't need.

Here [1] are some infos about QML development and here [2] you can try out QML in the browser.

[1] https://github.com/Esri/arcgis-appstudio-samples/wiki/Unders... [2] https://qmlweb.github.io

Have used it and hang out in the Gophers slack channel. You provide great support and when I followed instructions it worked perfect!

thank you :)

I am confused by QT licensing model. What are limitation of free QT plan used by commercial (downloadable) application?

Qt is LGPL. So there are no limitations unless you make changes to the Qt library (which you probably won't do). If you do make changes, though, then you would have to release them under LGPL license.

So, I think there are absolutely no limitations to using Qt LGPL in a commercial application. All you get from the commercial license is support.

Note: I'm not a lawyer, don't hang me if you get sued or something. But I do think I'm right about this.

> there are no limitations unless you make changes to the Qt library

I thought you were required to allow linking to a newer or modified version of a LGPL library? So one limitation is you have to either dynamically link or provide a mechanism to relink.

IANAL, but this requirement is the reason I stopped using Qt for my own projects. Those terms would seem to mean anything you write using Qt can't be deployed on a closed platform. Tons of people use LGPLd code on iOS and Android (stores like Play and Amazon) though and I think most users and developers are ignorant of the relinking requirement. I didn't want to risk it.

Here's an old example of how it can (apparently; presumably according to Google's lawyers) be done for iOS: https://news.ycombinator.com/item?id=4302517

Google has now killed off Sparrow entirely, but they used to make it available for download so that an end-user could in principle re-link it, to comply with the LGPL.

So if I were to statically link my application but release the object files and let user's re-compile it with another version of the library then that would satisfy the LGPL license? If so I think I might be headed back to Qt.

Or just dynamically link.

I'm asking for iOS which won't allow it.

Seems so: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

It would appear that once again the FUD is unjustified, and in reality GNU/SFLC licenses well made

The Apache Software Foundation does not allow its projects to have mandatory LGPL dependencies for this reason: it would become impossible to bundle the Apache product plus its dependencies into a package that forbids modification, either through technical or licensing restrictions.

This linking restriction is not a part of other product-scoped copyleft licenses like the MPL and the EPL.

> Those terms would seem to mean anything you write using Qt can't be deployed on a closed platform.

This sentence is missing a "closed source". If you license your application under GPL, you will have none of these problems.

Yes, if you link dynamically, you are generally okay with just sending your executables.

If you link statically, you also have to make your object code available for relinking if needed. But that generally comes down to doing something like "ar q libMyApp.a *.o" and then the user would make the app with "gcc -o MyApp libMyApp.a -lQtWhatever".

If you distribute as some package (like .apk for android), you'd have to make it possible for user to change the library. Simply allowing users to download .apk files would make it work, since they can unzip them, change the library and rezip them back.

So, I wouldn't really call those "limitations". Just pesky things you have to do if making a commercial app with lgpl lib.

Oh, and there is no requirement to link with a newer version of the library, to the best of my knowledge. That's generally impossible since newer versions might (and do) deprecate features that were available in the older versions.

It's also in the meantime LGPLv3 - at least for certain QT components, but the system is not easy to understand. The v3 requirements add that if you distribute an application (or device) with it, you have to provide the user with a way to update the linked QT library with a different version that he provides himself.

The open source version of Qt is LGPL, which basically means you may use it in a proprietary application if you use dynamic linking. If you link statically or copy any of its code, then your program must be free software (GPL).

If you pay for a commercial license, you can link statically without restriction. The commercial version is also necessary for locked-down platforms like iOS where the dynamic linking can't be changed by the end user of the software.

IANAL, and there are a few details I glossed over, but that's the simple version.

Either dynamic linking or provide object files that can be linked with the library.

In essence, you can use it in proprietary application as long as you don't modify the library and you provide means to switch to different version of the library.

If I statically link is my code inherintly LGPL or could I still license MIT?

If LGPL was "viral" even when linking dynamically, there would be no point in it (it'd be like GPL).

So, yes. You can use MIT.

Of course, the dynamic dependency still remains LGPL.

Yes and no. LGPL only is non-viral if the end user can trivially replace the linked library with their own version.

"If you link statically or copy any of its code, then your program must be free software (GPL)." I don't the first part is true (the second one is though).

https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...

The second part isn't technically true either. You can copy code without requiring a license if you meet the requirements for fair use. For example, copying function signatures for interoperability.

I was trying to be conservative and paint a simplified picture of the license that you can't go wrong by following, but I definitely erred in leaving out some possibilities and presenting it as if they don't exist.

It seems the obscure qt.io Downloads page really isn't helping in this regard

dumb question: will qtdeploy produce a single static binary for the whole app or is about some other sort of shared libraries deployment ?

it depends on the target [1] and which Qt version you use, the default "official" Qt version usually dynamically links against Qt's libs. for windows for example you can use the msys2 version (on windows), which can also be statically linked or you could use the docker images with mxe to statically link your windows application. but you could also build a static version of Qt yourself and use that version as well.

https://github.com/therecipe/qt#targets

I may be remembering wrong. But I believe back when I used Qt a few years ago, the most common interpretation of the GPL license the free version used prevented you from deploying with a single static binary.

Oh right, almost forgot that..

Surely, that's "prevent you from deploying with a single static binary unless under the GPL/binding offer of source code"?

You can technically deploy with a static linked Qt as long as you provide your compiled object files for download somewhere along with instructions for how to swap out the linked Qt with any other version of Qt. This keeps your code proprietary and honors the license.

For example, you must deploy as a static linked Qt on the Apple App Store, but since Xcode is free and no Apple dev account is needed to install an app on your iOS device, you can provide instructions for how any user could install your binaries with any version of Qt. Unlikely any user would ever do this, but by making the process publicly known, you honor the license (and you don't need to share your own source code).

Xcode might be without any cost, but the Apple hardware needed to legally run a copy of OS X (which also isn't free) - I don't really see how "Xcode being free" enters into it, as long as the software is distributed for iOS devices?

For the Mac app store, it might be different, as you need a Mac to access that anyway.

FWIW I think the issue here is that artificial limits on what code can be run on what hardware (legally) is in conflict with the (L)GPL -- and there's really nothing anyone other than Apple can do about it. Which is also why, as far as I know there's no actual legal way to distribute (L)GPL software on these locked app stores - there's no way for the distributor to actually honor the license, and so no way for them to be able to (re)use/distribute the code legally?

Qt is LGPL'd, meaning static linkage is possible as long as others are able to relink using other Qt versions. Providing your applications as object files is enough for this, no need to share sources.

Why is the -fast flag not the default for qtdeploy?

Edit: er, why the downvotes for a harmless question? I was curious why a flag named fast is not the default. This question is also very much related to the project page linked.

qtdeploy is intended to be used for deploying and therefore will run qtrcc, qtmoc, qtminimal and do the actual bundling of your binary. the -fast flag re-uses the cached rcc_* moc_* minimal-* files and will also not re-run the actual bundling process. this works for the desktop targets but not for the mobile targets, therefore I made it optional.

In what world would "fast" mean "do things faster with no downsides"? ;)

It's a trade-off between deployment speed and quality, like compiler optimizations.

Does this require CGo?

Yes. For example, the dbus package: https://github.com/therecipe/qt/blob/053d54a2eb0658bae6e3259...

https://github.com/therecipe/qt/blob/053d54a2eb0658bae6e3259...

All of the code is cgo wrappers around messes of c/c++

Can gc load a cgo plugin [1]? If so, could you build therecipe/qt into a plugin and load it at runtime to avoid being forced to use cgo?

E.g. your project has `type Qt interface {`, and the plugin exports a global symbol that can be asserted to that interface to use the library.

[1]: https://golang.org/pkg/plugin/

It could probably work, but plugins currently only work on linux.

I also prefer golang over c++ for simplicity. But does it have IDE support? I mean Qt Creator. In the meantime, my first choice for cross-platform GUI development is Lazarus - clean language, broad OS support, and full IDE support (drag-and-drop layout designing and integrated debugging).

Sorry for the newbie question, I've never written a desktop application. But do you write the UI in a different language than you write its business logic? For instance, you would write the UI in Delphi with the Lazarus IDE and then the "back-end" of your app would be written in C++, Go or something alike?

tl;dr: sometimes the UI can be written in a different language.

Qt used to have an XML markup language that auto generated C++ UI code.

Later, QML was introduced - which is a JavaScript based UI runtime.

There are Qt bindings for other languages, for example Python. So you could write business logic in Python and UI in QML.

Thanks! So is Qt used to write both the logic and the UI?

So you write Object Pascal code? You don't have some freelance work avail?

Does this work on embedded devices without desktop environment?

If Qt supports it, then you can probably get it working with this binding as well.

IS a beaglebone black sufficiently close to a raspberry pi3 that I can use the RPI3 environment for beaglebone black dev? If not, what's required to implement on a new platform?

I think you can't simply reuse the rpi3 env, but you can use it as a template to how to get this working for the beaglebone black. So you would need to get a cross compiler and then extract the sysroot to compile Qt on your own. After you got Qt compiled, you will also need to make some changes similar to these [1] But I think the hardest part might be to get Qt compiled for the beaglebone black, because the info I found online seems to be a bit outdated.

https://github.com/therecipe/qt/pull/226/files

https://doc.qt.io/qt-5/embedded-linux.html

Is the wrapper C++ code generated or hand-written?

it's automatically generated against the Qt version you use when you run the setup. the generator is also used to power qtmoc and qtminimal.

I couldn't find the source code of that generator. It is not here, right? -> https://github.com/therecipe/qt/

it's in the internal package: https://github.com/therecipe/qt/tree/master/internal/binding

It looks impressive. Thanks.

To clarify myself, I wondered if the wrapper code is generated (like here https://github.com/therecipe/qt/blob/master/websockets/webso...), not the moc-generated code.

yes, the .cpp .h and *.go files are all generated

what are the differences with go-qml? https://github.com/go-qml/qml/blob/v1/README.md

go-qml, like the name suggests allows you to use QML together with Go. This binding allows you to also use Qt's C++ API. And it contains some tools to simplify deployment and development processes.

Just wanted to say, thanks for working on this! :-)

Nice to see this happening.

FYI, the 'examples' link on that page is broken

it works from the README on github and goes to https://github.com/therecipe/qt/tree/master/internal/example...

Is this an official package?

I would be nice if Google put resources behind a project like this. Same with gopherjs.

Reply on news.ycombinator.com