4 ms·

Hey, I noticed that you reference other implementations. What's the rationale for a new implementation? Cheers

• mappu 2y ago
  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.
  • wiz21c 2y ago
    https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic 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 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 :-)