I slightly lament the rise of MIT or BSD licensed middleware like this. It's undoubtedly great for the developers and organisations in question, but there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license. This already exists for Go and Qt, and the competing library is "soon" to release a commercial license that would be available for those who do not wish to use the LGPL. Nevertheless, huge props to the author(s) for what undoubtedly is a vast amount of work.
Miqt: MIT-licensed Qt bindings for Go
11–20 of 92 posts
Re: Miqt: MIT-licensed Qt bindings for Go
#12Nice, 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.
A lot of kitech's work was in making the large C ABI wrapper. There's another C ABI wrapper already in Debian (libqt5pas) that might be possible to use directly.
Re: Miqt: MIT-licensed Qt bindings for Go
#13Does 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 techn…
Also, QML exposes only a fraction of the functionality of the Qt Widgets API.
Re: Miqt: MIT-licensed Qt bindings for Go
#14I slightly lament the rise of MIT or BSD licensed middleware like this. It's undoubtedly great for the developers and organisations in question, but there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license. This already exists for Go and Qt, and the competing library is "soon" to release a commercial license that would be…
There's a whole handful of permissively-licensed, feature-matched alternatives to GNU Readline that I suspect only exist due to political aversions to its license. It saddens me that these people would rather waste time treading over the same paths others have just to increase the potential for nonfree software, rather than using that time to write free and useful things.
Re: Miqt: MIT-licensed Qt bindings for Go
#15I slightly lament the rise of MIT or BSD licensed middleware like this. It's undoubtedly great for the developers and organisations in question, but there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license. This already exists for Go and Qt, and the competing library is "soon" to release a commercial license that would be…
Well yeah, that's the old "open source" vs "free software" schism: Go itself being permissively licensed, there's a lot of interest in having libraries that also come with "no strings attached".
Re: Miqt: MIT-licensed Qt bindings for Go
#16Earlier quoted context omitted.
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 t…
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
You can have the LGPL'ed code but the price to pay is that your users give your objects files (i.e. pre-link stuff; but not the source code) so that your users can modify the LGPL code and rebuild your project with the modifications.
Moreover: https://pkg.go.dev/cmd/link
So it seems that you can have access to the object files.
Overall, it is possible to make your bindings LGPL. I understand this is a bit trickier and not very user friendly.
Or you could dual license.
But well, it's a political choice, so I won't try to convince you :-)
Re: Miqt: MIT-licensed Qt bindings for Go
#17Nice, 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.
A lot of kitech's work was in making the large C ABI wrapper. There's another C ABI wrapper already in Debian (libqt5pas) that might be possible to use directly.
Ah, that's a part of Lazarus (the "pas" at the end is a giveaway). Actually I've had this idea for some time that integrating Go into Lazarus might be worthwhile - I was a Delphi developer before I "jumped ship" to web development, but I still like the effortless way of building GUI applications with a proper GUI design tool, and Go's speed of compilation and some syntax elements make it appealing for Pascal developers (at least that's the way I felt when I first tried it). But not sure how the two communities would feel about this idea...
Re: Miqt: MIT-licensed Qt bindings for Go
#18I slightly lament the rise of MIT or BSD licensed middleware like this. It's undoubtedly great for the developers and organisations in question, but there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license. This already exists for Go and Qt, and the competing library is "soon" to release a commercial license that would be…
Well yeah, that's the old "open source" vs "free software" schism: Go itself being permissively licensed, there's a lot of interest in having libraries that also come with "no strings attached".
This is not about "open source" vs "free software".
This is about "permissive" vs "copyleft"
Re: Miqt: MIT-licensed Qt bindings for Go
#19I slightly lament the rise of MIT or BSD licensed middleware like this. It's undoubtedly great for the developers and organisations in question, but there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license. This already exists for Go and Qt, and the competing library is "soon" to release a commercial license that would be…
> the competing library is "soon" to release a commercial license
No, after many years this never became available, and the maintainer went missing, taking the copyright with them. If it was really possible to buy a commercial license it's possible I might not have bothered to make the binding.
My hope is that by choosing the MIT license for my bindings, one commercial app in the world will choose to use Qt Widgets instead of Electron, that does in small part something for the climate.
Re: Miqt: MIT-licensed Qt bindings for Go
#20I slightly lament the rise of MIT or BSD licensed middleware like this. It's undoubtedly great for the developers and organisations in question, but there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license. This already exists for Go and Qt, and the competing library is "soon" to release a commercial license that would be…
> there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license.
Undoubtedly is probably not the right words, since reasonable people disagree about this. Not everyone agrees with you that the GPL is an unalloyed good.