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.