LeanQt VS cxx-qt

> Then do you (developers on HN) stay away from CLAs?

Depends on the CLA, but generally I do stay away. E.g. I never checked in anything to the official Qt repository because I don't agree the the CLA by QTC. Instead I finally made my own fork and call it LeanQt and LeanCreator (see https://github.com/rochus-keller/leanqt/ and https://github.com/rochus-keller/leancreator/).

The "weird licence which is basically a modified version of the MIT licence but with a clause that prevents competitive usage" is likely not even recognized as a true "open source" license.

> would it be possible to relicense a fork of Polaris to MIT (removing the Shopify clause?)

Likely not, because only the IP owner can determine who can do what with their IP under what license. If you use the software of an IP owner under a specific licence, you usually don't have the rights to re-license their work, even if you modified it.

My response to this question was https://github.com/rochus-keller/LeanQt, but I'm not using QML nor xmlpatterns.

I made myself independent of the adventures in Qt Land by switching to https://github.com/rochus-keller/LeanQt.

https://github.com/rochus-keller/LeanQt

A minimum and easy to build fork of QT

If you (like me) don't need all that stuff and are not up to the latest craze, have a look at LeanQt (https://github.com/rochus-keller/LeanQt).

Right. In the Gui module you have everything you need for this: platform independent windows and events, 2D bitmap and vector graphics, fonts and even rich text handling. Unfortunately there are some dependencies in Qt Gui to Qt Widgets, but if you use e.g. https://github.com/rochus-keller/leanqt/ instead of original Qt these are resolved. So with this you can implement your own widget toolkit on top of the Gui module if you want, and still benefit from the very powerful platform independent foundations of Qt.

> Qt for MCU [..] seems like a big advantage over Qt LGPL-3.0. I have my doubts. MCUs powerful enough to run Qt GUIs smoothly are more expensive than, say, an i.MX6ULL with a Cortex-A7 application processor and Linux. It’s a lot easier to find developers for an embedded Linux system ...

This is a very convincing argument. A Linux embedded system is also more flexible and the degree of code reusability is usually higher.

> Shall we use Qt LGPL-3.0 or Qt Commercial?

LeanQt (https://github.com/rochus-keller/leanqt/) is still available under LGPL v2.1. I will not switch to Qt 6 with my projects.

My employer, KDAB, is building an excellent Rust binding for Qt: https://github.com/KDAB/cxx-qt

You can use cxx-qt or qmetaobject-rs. Or use Slint

Rust has several Qt bindings. The most popular are Ritual, CXX-Qt, and qmetaobject. Ritual is not maintained anymore, and qmetaobject doesn't support QWidgets. So CXX-Qt is our best bet for now.

Qt bindings for Rust also exist, although I'm not sure how mature they are: https://github.com/KDAB/cxx-qt/

We're getting closer, but you're still likely to run into missing features in CXX-Qt at this point. If you do, please report it on GitHub!

This is no longer required in CXX-Qt as of this week (https://github.com/KDAB/cxx-qt/pull/428). Next release coming soon.

From my understanding KDAB isn't trying to "replace" Qt. They're working on cxx-qt to make using Qt and Rust together much easier.

I second this. I wrote an internal Qt/QML app that ran on Windows, Linux, Android, and Raspberry Pis. We had ~20 Raspberry Pi's running this app in kiosk mode. If only KDAB/cxx-qt[1] were ready there, I would have done as much as possible in rust .

- [1] https://github.com/KDAB/cxx-qt/