Miqt: MIT-licensed Qt bindings for Go
github.com
Miqt: MIT-licensed Qt bindings for Go
1–10 of 92 posts
Re: Miqt: MIT-licensed Qt bindings for Go
#2> Yes. You must also meet your Qt license obligations: either use Qt dynamically-linked dll/so/dylib files under the LGPL, or, purchase a Qt commercial license for static linking.
There is this misconception that you can't statically link under the LGPL. From my reading (non legal advice), LGPL supports static linking - you just have to release your object files alongside the binary to allow people to link them with different versions of Qt.
Re: Miqt: MIT-licensed Qt bindings for Go
#3Hi, author here, ask me anything. (Qt 6 branch is nearly ready.)
Re: Miqt: MIT-licensed Qt bindings for Go
#4Does this support Qt Quick and QML?
Re: Miqt: MIT-licensed Qt bindings for Go
#5> Yes. You must also meet your Qt license obligations: either use Qt dynamically-linked dll/so/dylib files under the LGPL, or, purchase a Qt commercial license for static linking. There is this misconception that you can't statically link under the LGPL. From my reading (non legal advice), LGPL supports static linking - you just have to release your object files alongside the binary to allow people to link them with…
[deleted]
Re: Miqt: MIT-licensed Qt bindings for Go
#6Hi, author here, ask me anything. (Qt 6 branch is nearly ready.)
Hey,
I noticed that you reference other implementations. What's the rationale for a new implementation?
Cheers
Re: Miqt: MIT-licensed Qt bindings for Go
#7> Yes. You must also meet your Qt license obligations: either use Qt dynamically-linked dll/so/dylib files under the LGPL, or, purchase a Qt commercial license for static linking. There is this misconception that you can't statically link under the LGPL. From my reading (non legal advice), LGPL supports static linking - you just have to release your object files alongside the binary to allow people to link them with…
I also think that is legal. But if you are required to distribute additional object files, that does somewhat reduce the benefits of static linking - you might as well use dynamic linking in that case.
It's also not completely trivial to do this with the Go linker.
Re: Miqt: MIT-licensed Qt bindings for Go
#8Does this support Qt Quick and QML?
No(t yet), i've focused on the traditional desktop Widgets toolkit. There are other existing QML/Go bindings you might be interested in.
Qt Widgets has a lot of benefits over QML. It is native compiled code whereas QML is interpreted; the native compiler (qmlsc) is proprietary and only available for commercial licensees. If you are happy with a large runtime for an interpreted UI then I'd suggest looking at web technology (e.g. Wails) to enjoy the broader ecosystem effects.
Re: Miqt: MIT-licensed Qt bindings for Go
#9Hi, author here, ask me anything. (Qt 6 branch is nearly ready.)
Hey, I noticed that you reference other implementations. What's the rationale for a new implementation? Cheers
The main rationale is definitely the license. The existing bindings for Qt Widgets (therecipe/qt and kitech/qt.go) are LGPL. That's just really difficult to use in Go where static linking is the default behaviour.
The other bindings have some strange behaviours when I checked them closely.
- therecipe/qt: The design of the "qtbox" runtime for therecipe/qt, introduced before the maintainer went MIA. Now that we know the Jia Tan xz story, it's my hope that MIQT can be a "nothing up my sleeve" binding with a clear source code supply chain, with no prebuilt binaries.
- kitech/qt.go: The rationale for their version was to focus on compilation speed, but with GOCACHE this is no longer really a problem. It also seems to be unmaintained.
Re: Miqt: MIT-licensed Qt bindings for Go
#10Nice, thanks. All the other Qt bindings seem abandoned. https://github.com/kitech/qt.go is interesting though, it uses a huge wrapper, and then FFI calls. Now we can use libffi with purego (there is already a library) so in theory such a method can be used for CGo-free Qt bindings.