hckrnws
> therecipe/qt is the most mature Qt binding for Go. It works by making IPC calls to a separate C++ binary downloaded at runtime from a site under the maintainer's control.
WTF?
This sounds like something that was a good idea to begin with - we should ensure the libraries can be MIT licensed by using a separate binary, then hitting the "most likely go developers don't want to setup a complex C++ compile chain" to "I known we will just precompile it" to "oh but where can I download it from" to "oh I have that server".
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.
Reminds me of PS/Tk, a cross-platform, cross-implementation GUI library for Scheme that worked by opening a pipe to a Tcl/Tk process and communicating with that. It actually worked fairly well, though it's sadly abandoned now. I contributed somewhat by getting it working for Gambit.
Do you mean that it was abandoned for Gambit? It's available for Chicken [1] and via Akku [2] for Chibi, Gauche, and Sagittarius.
Jia Tan, is that you?!
Yea.. that sounds like a non-starter for use.
> Yea.. that sounds like a non-starter for use.
I'd also wager that a FLOSS binding to a non-FLOSS framework with steep licensing fees would also kill this option for most.
What non-FLOSS framework do you mean? Qt Widgets is LGPL,
Hi, 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.
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 :-)
Nice, 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...
> I still like the effortless way of building GUI applications with a proper GUI design tool
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.
You might like this : https://github.com/ying32/govcl
I spent some time using the GoVCL bindings of Lazarus LCL, and made some small app with it: https://code.ivysaur.me/yvbolt
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.
Comment was deleted :(
Does 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.
First of all, I wrote a block editor in QML[1] (the model in C++) that far outperform QTextEdit (part of Qt Widgets) at loading, scrolling and word-wrap resizing of very large documents (think, War and Peace) *with* the additional cost of being a block editor that can include a Kanban board, images, etc. So saying QML isn't performant is incorrect.
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...
Your app looks really nice, I like the smooth animations in the web demo. A benefit of QML is that more of the rendering is done on the GPU, so the performance may differ depending on hardware.
qmlcachegen produces only bytecode, not compiled code.
Thanks!
> 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.
Do you mind me asking if you work full-time on your app, or is it passive income?
The drag and drop looks really nice! Do you have some hints as to how you accomplished that with QML?
I used to earn passive income from its previous version, which is open source and is now a different project[1] by having ads on the website. It wasn't much but around $2000 a month semi-consistently across 5 years (sometimes more, sometimes less). A lot of traffic is coming from Google searches 20k-60k monthly (it varies). With Daino Notes I was hoping to focus on subscription more but since paid subscription isn't quite growing as much as I anticipated (although usage is quite high), I reenabled ads again. It doesn't quite cover the bills these days so I'm thinking about getting a job (if you know someone, HMU).
> 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.
I'm really happy to see people _Make Qt Great Again_. This was my first framework I've ever worked as a professional, and it was really good. Moreover I'm a really big fan of natively written windows/linux/mac apps (as opposed to something that will launch a fully fledged browser and consume ~500MB at start).
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.
Qt Quick doesn't launch a browser.
Also, QML exposes only a fraction of the functionality of the Qt Widgets API.
And vice versa.
Is it possible to extend/subclass an existing QWidget and customise it?
For e.g. PaintEvent() from pure Go code? Not yet, but I have some idea on how to make it possible.
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.
I contribute to NodeGui, Qt on Nodejs. It doesn't try to emulate the C++ API by allowing subclassing. Instead it exposes most methods on QWidget classes/subclasses which process QEvent objects (and their subclasses) in the form of events which you can subscribe to as an application. You can listen to signals and also QEvent related traffic in much the same way. So, if you want to subclass a QWidget to do your own custom rendering/painting, you would create an instance of QWidget and then listen to/hook into, the incoming requests to repaint. Qt sees a normal QWidget instance, but you can customise it do act like the subclass you desire. This avoids any attempt to do a real C++ subclass at runtime. Internally, NodeGui subclasses almost every QWidget (and more) to hook into them to allow this. This works far better than you might expect and saves a ton of complexity.
I have a question to the crowd.
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 currently do this at $DAYJOB with a C++/Qt GUI talking to a Go daemon. It's fine but eventually the busywork in marshalling is a headache, and it doesn't scale well for large amounts of data.
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.
> Even though the same marshalling is present, you get to write everything still in one language, the cross-language part is hidden from you.
The hard part of writing a desktop application is the GUI code, and how to implement user flows and how to manage the application state.
Adopting a highly non-standard technology to handle the hard part and on top of that adopt an ad-hoc IPC solution to get it to work sounds like putting all the project risks in all the wrong places.
How are you going to run on X11 systems if you have ruled out making IPC calls to a separate process in order to put together a GUI?
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.
> How are you going to run on X11 systems if (...)
I'm not sure you understood the question I asked.
Perhaps it is actually you who misunderstood my question?
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.
> 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.
> 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
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
Because this library supports dynamic linking, but can itself be statically linked, which is a default behavior for go. Trying to dynamically link a go library that dynamically links, or even statically links to Qt is just an extra level of effort for application developers.
This library will be easier for developers to create applications which comply with LGPL of the upstream library without adding additional burdons.
Isn't Qt still proprietary or semi-proprietary?
This discussion is about the Qt binding library for Go, not Qt. The existing Qt binding they're talking about is LGPL and cannot be bound dynamically, and therefore makes the distribution of proprietary software impossible even with a full Qt license. This new binding alleviates this problem because it's MIT licensed. You still need to adhere to Qt's licensing, i.e., buy a commercial Qt license or bind Qt dynamically like most people do. Qt has a commercial and a LGPL licensed version.
Most of Qt remains available under LGPL, but the Qt company does their best to dissuade you from using it without a commercial license.
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
Qt Widgets is GPL since Qt 2.2 in 2000, and LGPL since Qt 4.5 in 2009.
No. Just Qt Company hides this as much as they can.
It is only proprietary if you are building proprietary code AND statically link to it but open source/free (LGPL) if you are building software with a compatible license or are linking dynamically. I think it is fair.
LGPL doesn’t forbid linking statically with proprietary code.
No.
(There might be side projects like the squish test framework or the MCU port that are proprietary, but Qt itself is fully free software)
I guess you were not serious about the climate, as this will have no measurable effect on it, and with things like Jevons paradox [https://en.wikipedia.org/wiki/Jevons_paradox] could even have the opposite effect (more people using the app more because it is more usable)
But yes, for the love of your users, don't make an app using electron :-).
Vacuous comment. What action that an average person can take will have a "measurable" effect on the climate (excepting eco-terrorism)? In aggregate this kind of stuff is still meaningfull.
> In aggregate this kind of stuff is still meaningfull.
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.
Electron apps are probably responsible for multiple Gigawatt-hours of wasted energy annually.
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.
That's your definition of "useful", not mine. "political aversion"? We are talking about money and business here.
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.
Apple literally offered the clang/LLVM copyright to the FSF to be released under the GPL. This was basically just ignored.
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.
I doubt licensing is a "detail" -- various comments say it matters a lot, e.g. https://stackoverflow.com/a/14488011/3831197
> The GPLv3 was the final straw that ended Apple's interest in contributing to GCC which is the reason Apple ended it at GCC 4.2.x.
I guess GPLv2 is still GPL, but here we end up talking about copyleft licenses (GPLv3) affecting business decisions anyway.
> 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.
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.
> 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.
I honestly can't imagine any reasonable person arguing that GPL/LGPL have brought absolutely no societal good. Are you thinking of anybody in particular?
"no societal good" != "more societal good than alternatives"
The opposite of "some societal good" isn't "less societal good than other alternatives", it's "no societal good". The original statement didn't contain any comparisons. Even the worst alternative can still have some societal good.
The original statement is comparing against non-copyleft licenses like MIT. It is clearly stating the author's preference for the GPL.
It's not stating a preference - it's stating that, no matter what your preference is, there is some societal good from GPL/LGPL. Preferences don't change the existence of that good.
Not if you take "some societal good" to mean "some [marginal] societal good"
Sure, if you add words, the meaning changes. So what?
It's called nuance and context.
I honestly don't understand how you read this "nuance" into the original comment. They don't say that GPL/LGPL is absolutely better than MIT/BSD, and they speak positively about the project. There is no comparison here.
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.
You're only seeing the alleged benefits from GPL, without factoring in its costs. Everything is a tradeoff. Some companies don't touch GPL code, which means those projects receive less support than they would with a more permissive license such as MIT/BSD. You're claiming GPL "[encourages] organisations to release their code under a similar license". I'm saying it often discourages organisations from ever touching GPL code and picking other libraries instead.
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...
No, I'm not only seeing the alleged benefits, as I clearly explained in my previous comment. MIT/BSD brings their own societal good, but it's a different societal good, and it's not an equivalent societal good. Just because you gain some societal good doesn't mean you gain the exact same societal good. Unless you're trying to misunderstand OP, it's not a hard concept.
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.
> there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license
How often does this happen, though? I remember at my previous employer, there was a rule to never use GPL code in our projects.
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"
I'm probably oversimplifying things, but for me "permissive license" (MIT, BSD) is equivalent to the term "open source", and "copyleft license" ((L)GPL) <=> "free software". I know that the term "open source" also includes (L)GPL-licensed software, but the "free software" advocates resist being lumped together with software that they perceive to be less free, so they very much prefer "free software".
I don't know which advocates you have in mind, but the FSF does refer to MIT and BSD as Free Software licenses. For FSF, Copyleft is a desirable property (obviously), but not required by the four freedoms.
so less permissive = more free.
gives me something to think about.
All freedom is relative to the perspective you judge it. "Free" in this case is measured from the perspective of the software (and more specifically the source code), not the developer. The basic philosophy is that the easier it is lock up the source code and its development behind closed proprietary walls, the less free it is.
From the FSF perspective, your freedom to make the source code less free stands in direct opposition to the freedom of the source code.
The freedom prioritized is that of the user, not the developer working at a for-profit company. Copyleft software prioritizes users' freedom by attempting to prevent companies/developers from taking away their rights. (See also GPLv3's anti-Tivoization clauses: https://en.wikipedia.org/wiki/Tivoization that restrict companies to empower users)
Comment was deleted :(
> 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.
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.
You are not required to distribute those along with your app. You can just have them available for download separately if anyone needs it. LGPL requirement is the ability of the end user to relink (not recompile) the executable.
Yes, that's definitely possible.
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.
> But if you are required to distribute additional object files, that does somewhat reduce the benefits of static linking
Because of the total increase in size? Maybe one can just share a link from which the object files can be downloaded?
Comment was deleted :(
Comment was deleted :(
Comment was deleted :(
What is this for exactly? Go should be used serverside, and Qt looks like its for UIs on embedded devices?
Qt is a large framework and also includes e.g. a large network module which supported async event based communication long before there was Go. But it's unlikely that a Go application uses this, because Go has its own network library and even native language support for asynchronous communication (buffered channels). But Qt also has cross-platform user interface features even with 3D and OpenGl support, which might be useful for people using Go on the desktop.
Crafted by Rajat
Source Code