Hmm, i could have sworn that years ago Qt Creator was free? But maybe i'm misremembering things...

Just that the Qt company lately has been trying everything to scare / annoy people into getting licenses, sign up for their online accounts etc... So they're just not advertising their open source offerings as much.

1. https://www.qt.io/download-open-source

All i can tell you is most of the small-medium sized companies i worked for over the last few years are still using the very old and outdated Qt 5.6 just to avoid the newer LGPLv3 license. In fact i haven't heard of anyone who purchased a Qt Commercial license to date.

We're never going to Qt6, the newer licensing terms are just too much for us. Calling v5 old and outdated is subjective - we develop 2D interfaces on Linux framebuffer and that's good enough for the task. It's a bit sad that Qt is focused on 3D stacks and particle effects and acceleration and - mein gott in himmel - I just got an email about in-app advertising coming to Qt6. While core features and deficiencies in the system have gone unaddressed for years, sometimes nearly a decade.

Sadly the next generation of our products will be going to React or Electron. So now we need to beef up our hardware and burn millions of unnecessary watts over the decades because we will need Node or some other backend server running on our little devices.

They've won, and I'm sad about it.

Tbh Qt 5.15 is still plenty good for most embedded Linux use cases. Just that organizations i worked with are stuck with Qt 5.6 (last lgpl v2 version?) And it was a pain to keep backporting fixes to it. The 3D stack rewrites were also unavoidable when trying to write cross platform applications because the underlying graphics stack changed. OpenGL isn't getting much support from the drivers and ANGLE was a pain for them to integrate/maintain apparently.

Qt 6 is available in LGPLv3 right? If you're already using 5.15, what would stop you from using Qt6?

Interestingly, flutter seems to be taking off even in the embedded world where QtQuick used to work really well. You might want to consider that if you're averse to electron. (Eg. Flutter-pi).

We're commercial distribution so we don't care about LGPLv3 for Qt. The problem is more about the previous contract we have in place with Qt that gives us some favorable terms. Qt wants us to drop that contract to go to Qt6, and we won't do it. Qt will get their customers on their subscription model eventually, and the rest will be learning how to write for embedded webkit. Like us.

On a purely personal/professional angle I won't use Flutter. I have a blanket policy of refusing to use any Google-developed project for embedded devices, including Android.

And yep. Relying on just Google can be a death sentence. I was hoping to use Android things for a quick demo last month only to find out that it is discontinued. What made me look at flutter was because companies like Sony are driving forward it's development on embedded space ( https://github.com/sony/flutter-embedded-linux ). Tbh I am still looking for something that was as nice as QtQuick on embedded devices, but with a permissive license.

So other than electron, what options do you see moving forward? All i see is slint ( https://github.com/slint-ui/slint/ ).

For 1 slint/flutter/lvgl expert in the field I can find 100 experts in React or Node. I try to design systems where it's easier (management translation: cheaper) to hire developers instead of making it harder. Or finding someone that claims to be an expert in Qt or Flutter and the best they can do is a flashier version of the examples off of Github.

Perhaps Flutter will survive Google and become something useful. But I really don't need to learn another language right now.

Slint does look interesting, however. Kind of feels like QML in a number of ways. But, again, GPLV3 or commercial so it's going to be a lot of work to move.

With lvgl it looks like it doesn't utilize that GPU much, so as you move to higher resolutions, your performance and fps drops hard. If you're doing video rendering etc... That will be a pain. (Take a look at CPU usage on their YouTube videos)

GPU were designed for graphics, not UIs, we can certainly make them work within constraints, but it's not always a huge andvantage, and has drawbacks. 99% of what you use a UI for doesn't really get that much advantage from the GPU.

That said, I think there is advantage there, we just have to learn how to use it well.

For desktop I mostly suggest QWidget based UIs for more than one reason.

For eg. A badly implemented "speedometer widget" was making our whole embedded GUI stutter at 15-20 fps and 100% cpu usage (which caused other problems like overheating, timing problems etc...). 5 lines of change to make the GPU do most of the work and we were back to smooth 60fps and low cpu usage.

At my last job, the requirements were like: you might as well directly target embedded linux socs instead of microcontrollers like ESP-32, because the price difference between them is not that much for the number of these devices we wish to sell.

It's not the same if you go commercial. See above.

Is Qt under LGPL 2.1? Were the changes so drastic?

More details: https://embeddeduse.com/2016/04/10/using-qt-5-6-and-later-un...

Qt from 4.8(?) To 5.6 offered an LGPL2 license too but after that it's mostly LGPLv3 i think.

And if you're developing external software there's no real way you can hide the fact that you're using Qt. They wouldn't need to audit you.

The good:

1. Their QWidgets library is very stable and mature for cross platform desktop applications and i can still recommend it very much. I don't think there's a good enough alternative to it tbh.

2. For embedded systems in certain sectors (automotive, house appliances etc..) their QtQuick (with QML) is almost like the defacto standard. It is kind of like flutter but with a much better GUI describing language and very nice integration with C++.

3. Their C++ libraries and tools are also kind of nice when developing non GUI applications (networking, cli tools etc..), but these days C++ ecosystem has much nicer alternatives. Qt Creator is still my fav. C++ IDE though.

The bad: 1. Using QtQuick for mobile application development is fine until it isn't. The ecosystem is a lot smaller than say flutter, react native etc... So you end up hand rolling various integrations yourself.

2. The licensing situation can be a bit of a headache when developing a commercial product. For eg. You cannot easily statically link your application with the open source offering, and you need to statically link when targeting iOS.

3. Licensing can be very expensive, even on embedded systems. LGPLv3 means you need to provide the end user a way to replace your Qt libraries and for many companies, that's a no go. So even today, i see a lot of companies still using the very old Qt 5.6 (when there was an LGPL v2 offering). If you're developing a desktop or Android application or an open source application, none of the licensing headaches should apply to you though.

4. With QtQuick, Qt Multimedia etc... things changed a lot during the last 5-6 years, so a lot of times the 3rd party libraries you find aren't that useful to you or are just half baked in the ecosystem.

I'd still use Qt for my personal projects, but with all the licensing headaches i see more and more companies trying other alternatives. If you want to try out, try out QML: https://doc.qt.io/qt-5/qmlfirststeps.html

Sadly, like you mention, the rest of the ecosystem is languishing and the company's attention is elsewhere. Licensing has become a major headache (not just cost but terms) and I've grown tired of spending weeks and months trying to get it through management and explained properly.

I assume you mean companies developing interfaces/applications for closed-down end-user systems like set-top boxes?

Sailfish OS was stuck on Qt5.6 for a long time because of this.

As far as UI programming goes, it's very slow moving. Once you get the right flavour chosen, it's not so bad.

If you are making an app for a Kiosk, like a ticket console, that's not going to change every day, Qt is a good choice, it's well supported.

For other things it's a tougher decision.

The main downside is that realistically you have to use C++, and it doesn't run nicely on the web like e.g. an Electron app would (something like Slack for example).

Also QML is not very good - QtWidgets is much better unless you really need animations, but unfortunately QtWidgets is in maintenance mode.