Live data from Hacker News

Miqt: MIT-licensed Qt bindings for Go

github.com

41–50 of 92 posts

Re: Miqt: MIT-licensed Qt bindings for Go

#41
post #30
post #7

Earlier quoted context omitted.

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.

Re: Miqt: MIT-licensed Qt bindings for Go

#42
post #40

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

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.

Re: Miqt: MIT-licensed Qt bindings for Go

#43
post #8
post #4

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

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.

Re: Miqt: MIT-licensed Qt bindings for Go

#44
post #39

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

Re: Miqt: MIT-licensed Qt bindings for Go

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

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.

Re: Miqt: MIT-licensed Qt bindings for Go

#47
post #14

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

Re: Miqt: MIT-licensed Qt bindings for Go

#48

Earlier quoted context omitted.

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.

Re: Miqt: MIT-licensed Qt bindings for Go

#49

Earlier quoted context omitted.

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…

Electron apps are probably responsible for multiple Gigawatt-hours of wasted energy annually.

Re: Miqt: MIT-licensed Qt bindings for Go

#50
post #20

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. 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?
Post reply on HN