Live data from Hacker News

Miqt: MIT-licensed Qt bindings for Go

github.com

61–70 of 92 posts

Re: Miqt: MIT-licensed Qt bindings for Go

#61
post #46

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.

Re: Miqt: MIT-licensed Qt bindings for Go

#62

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.

[deleted]

Re: Miqt: MIT-licensed Qt bindings for Go

#63

> 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

#64

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…

> 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.

Re: Miqt: MIT-licensed Qt bindings for Go

#65
post #57

Earlier quoted context omitted.

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,…

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.

[1] https://www.notes-foss.com/

Re: Miqt: MIT-licensed Qt bindings for Go

#68
post #19

Earlier quoted context omitted.

> 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 i…

> 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…

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.

Re: Miqt: MIT-licensed Qt bindings for Go

#69
post #50
post #20

Earlier quoted context omitted.

> 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"

Re: Miqt: MIT-licensed Qt bindings for Go

#70
post #66

> 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.

Post reply on HN