WTF?
Every step in the chain makes sense and is done with the best intention, but the result is, well.
Been there done that. Didn't get the t-shirt.
Cheers
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.
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 :-)
I really like this too. Qt Widgets offers this too, with the Qt Designer app. It's really easy to use, just like Delphi, Winforms or old VB6.
The Qt Creator IDE has integrated designer and also LSP support for Go, an integration could be really interesting for rapid development.
It does work, but I had hoped for more, it is simply too far behind in many ways and is stuck on GTK2 (so no high DPI support). The LCL itself does support GTK3 and Qt5 (and nothing newer), but recompiling GoVCL to use them broke quite badly.
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.
Secondly, my knowledge about the internal build tools such as qmltc, qmlcachegen, and qmlsc is quite limited, but isn't qmlcachegen also compiles QML documents[2]? And don't forget that the built-in Qt Quick components are either compiled to C++ or written natively in C++.
[2] https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html#summ...
qmlcachegen produces only bytecode, not compiled code.
> qmlcachegen produces only bytecode, not compiled code.
Ho gotta. But I still wonder what's the additional performance boost qmlsc will give. I should test this some day.
Btw, are you on some social site? X? Discord? Would love to say in touch.
The drag and drop looks really nice! Do you have some hints as to how you accomplished that with QML?
> Do you have some hints as to how you accomplished that with QML?
I'll publish a detailed blog post about the entire development journey very soon. You can hit me up on X (@mamistvalove) or Discord (@rubymamis) and I can send you a draft, if you like.
It's really depressing how we all strive to have everything on the web, in the cloud, etc., but have nothing on our own. I still tend to write quick applications in PySide (free Qt for Python) that stay in my tray, behave very well, are very quick, and occupy about 60MB instead.
Until then, a nice feature of CGO is you can write one custom Qt subclass in a .cpp file in the same folder as your .go files. Your C++ will be compiled with `go build`, and you can use your custom class directly from Go/MIQT. So even if some advanced Qt feature is not in the binding, anything is still possible at least. I'll make an example about this.
If you really like Go and you're already willing to adopt a solution based in making IPC calls to separate processes just to put together a GUI...
...why not write your GUI app in something production-ready that makes sense to write a GUI, and have that call your Go process ?
I can see some advantage of the therecipe/qt "qtbox" idea. Even though the same marshalling is present, you get to write everything still in one language, the cross-language part is hidden from you.
In either case, it's great that MIQT now lets you avoid this, and write everything in Go with no IPC marshalling at all.
Anyway, the primary advantages of the separate process you speak of is that it:
1. Deals with the LGPL concerns for you.
2. Deals with the pains of compilation, and especially cross-compilation for you.
That is why you might consider it. Of course, it comes with many disadvantages too. Tradeoffs, as always.
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.
I still do t understand this logic. When you combine MIT and LGPL you don't get MIT, you get MIT+LGPL so now you have to take care of both licenses. Electron's LGPL parts don't magically disappear - when you start an Electron app all the things that happen from main() up to executing the first line of your js app code are LGPL
This library will be easier for developers to create applications which comply with LGPL of the upstream library without adding additional burdons.
They have succeeded in convincing me, for example. I don't want to build anything on a platform where the vendor is trying to drive me away
(There might be side projects like the squish test framework or the MCU port that are proprietary, but Qt itself is fully free software)
But yes, for the love of your users, don't make an app using electron :-).
No, I don't think it is. The scale is so small that even if every electron application was suddenly replaced by an equivalent super lightweight one, I claim it would make no difference for the climate.
Other things can make a difference in aggregate, like eat less meat, using better mode of transportations, ... But I don't think the CPU cycles wasted by electron makes any difference, even in aggregate.
If a commercial company wants to ship a product without reinventing all the wheels, they are going to use code with permissive licenses, and skip projects with GPL license or similar in a heartbeat.
You could even argue quite the contrary -- when you make your project GPL/AGPL etc, and if it is big/impactful enough, people will inevitably create alternative projects with permissive licenses that tried to match the feature set, and it is you that is the cause of all this "waste of time". Not necessarily a good argument, but there is some truth there.
And thank god a lot of goodness actually comes out of it other than just reinventing the wheels. Apple "bought" LLVM due to gcc's copyleft license, and now we have a family new compilers based on LLVM for different languages and targets. Kudos to Apple.
https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html
Furthermore there were real technical problems with gcc, certainly at the time. There were good reasons to start a new compiler project.
The license was always more of a detail, rather than the main thing.
Did you know that there's no rule against commercializing or selling free software? The only reason that companies skip projects with copyleft licenses that's relevant in this discussion is because they intend to incorporate them into proprietary software, and this is because they are, by some deeply corporatistic scruple, incapable of conceiving of the idea of delivering free software (even if 90% of the heavy lifting in their services is done by free programs).
> You could even argue quite the contrary -- when you make your project GPL/AGPL etc, and if it is big/impactful enough, people will inevitably create alternative projects with permissive licenses that tried to match the feature set, and it is you that is the cause of all this "waste of time". Not necessarily a good argument, but there is some truth there.
Yes, it's not a good argument. The truth there is that if I develop a free program or library under (L)GPL or similar then I have made that thing free. If people want to write an alternative for technical reasons, then that's neither here nor there, but if people want to write an alternative because they don't like the license, then that's their own time they are wasting, because they would have no other reason to do it other than wanting to incorporate it into nonfree software.
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.
The switch from GPL/LGPL to MIT/BSD loses a specific set of restrictions that are "encouraging organisations to release their code under a similar license". This is a specific societal good that is being lost. Even if you don't think that it's a big deal, I can't imagine anyone reasonable saying "literally everything would be better GPL/LGPL" - objectively, the public wouldn't be guaranteed to have open-source-free access to so many products. You can argue that there would be more products or whatever you want, but unless you're taking an absolutist stance, some societal good comes from these licenses.
The only way to arrive at a comparison here would be to ignore the context and the chosen wording by the OP.
People have been writing about this in way more detail for a long time. If you're really trying to understand some position you can't possibly fathom and not just argue, then I'd point you to one post from 15 years ago: https://sealedabstract.com/rants/why-the-gpl-sucks/index.htm...
GPL/LGPL has advantage A. MIT/BSD has advantage B. A and B are different. Even if B is greater than A, it still doesn't mean that A is a subset of B. You keep acting like the only thing that matters is |A| and |B|, because you're somehow fixated on this being a comparison.
Try re-reading the original comment without adding in words like "marginal". You'll see that there is no comparison made between societal goods.
How often does this happen, though? I remember at my previous employer, there was a rule to never use GPL code in our projects.
gives me something to think about.
From the FSF perspective, your freedom to make the source code less free stands in direct opposition to the freedom of the source code.
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.
It's also not completely trivial to do this with the Go linker.
Note that the LGPL license says any such download must remain available for 3 years. Before GitHub, I used to host my projects on Google Code. After that service shutdown, I'm not comfortable with such a requirement.
Because of the total increase in size? Maybe one can just share a link from which the object files can be downloaded?