4 ms·

I honestly don't know. I mean i routinely see so many GPL violations too and all i had to do was grep the binaries/update packages for strings like GPL. All i

I honestly don't know. I mean i routinely see so many GPL violations too and all i had to do was grep the binaries/update packages for strings like GPL. 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.

joezydeco 5y ago
I'm a licensed commercial Qt developer, been so for about a decade now. My current org is still on 5.15 (the latest LTS release) and that's as far as we're going. I'm relieved they at least offered to go beyond 4.8 (the LGPL3 switchover) but that's mostly because other projects were already doing it. 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.
- ldiracdelta 5y ago
  I've used qt professionally for years and have been slowly coming to the same position, but I'm wondering about going the other direction with performance and using lvgl.io for GUI only and all the backend server communication and business logic in rust. Lvgl.io is beautiful and it runs all the way down to esp32-connected devices.
  - saidinesh5 5y ago
    With QML/QtQuick all/most of the ui is rendered on the GPU though. That leaves the CPU free to perform other tasks. Even at 1080p 60 fps your CPU usage sits under 10% on cheap iMX6 devices. 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)
    - ldiracdelta 5y ago
      Yeah, I think you would use other native technology for videos, but for simple UIs? If it can work on an ESP-32, it can work on x86 big-iron. ( I don't have a dog in this fight, yet, so tell me how I'm wrong.)
      - saidinesh5 5y ago
        Oh it really depends on your use case and the hardware you use for embedded devices. If all you need are some buttons and some kind of static lists, lvgl should be fine too. But for anything where you want things like smooth scrolling/higher resolutions you probably want to use the GPU. 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.
    - jollybean 5y ago
      QML comes with gigantically more memory usage and it's very inefficient at rendering text. If you want to render something that looks like a wikipedia page, prepare to pay a heavy price. 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.
- nextaccountic 5y ago
  Isn't Qt6 just LGPLv3? As in, the same as before?
  - joezydeco 5y ago
    It's the same if you're going open source. It's not the same if you go commercial. See above.
- saidinesh5 5y ago
  I feel you. In fact after a decade of mostly C++ / Qt jobs, I've realized it's time to move away to other tech. More companies i worked with are avoiding Qt where they can. And even i was getting tired of creating the same QtQuick controls over and over again. 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).
  - joezydeco 5y ago
    Qt 6 is available in LGPLv3 right? If you're already using 5.15, what would stop you from using Qt6? 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.
    - saidinesh5 5y ago
      Oh that sucks. Yeah Qt has gotten really aggressive with their licensing headaches. They broke so many of our CI scripts when they made it mandatory for you to log in to use their Qt installer even for online version. 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 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/ https://github.com/slint-ui/slint/ ).
- kabes 5y ago
  I think flutter might also fill the gap left by QT.
nextaccountic 5y ago
... what's the trouble with LGPLv3? Is Qt under LGPL 2.1? Were the changes so drastic?
- saidinesh5 5y ago
  The main problem with LGPLv3 is the anti-tivoization clause. That means you should basically provide the end user a way to replace the Qt libraries with their own. On embedded systems this can mean headaches for companies releasing commercial products. More details: https://embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/ 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.

joezydeco 5y ago

I'm a licensed commercial Qt developer, been so for about a decade now. My current org is still on 5.15 (the latest LTS release) and that's as far as we're going. I'm relieved they at least offered to go beyond 4.8 (the LGPL3 switchover) but that's mostly because other projects were already doing it. 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.

ldiracdelta 5y ago
I've used qt professionally for years and have been slowly coming to the same position, but I'm wondering about going the other direction with performance and using lvgl.io for GUI only and all the backend server communication and business logic in rust. Lvgl.io is beautiful and it runs all the way down to esp32-connected devices.
- saidinesh5 5y ago
  With QML/QtQuick all/most of the ui is rendered on the GPU though. That leaves the CPU free to perform other tasks. Even at 1080p 60 fps your CPU usage sits under 10% on cheap iMX6 devices. 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)
  - ldiracdelta 5y ago
    Yeah, I think you would use other native technology for videos, but for simple UIs? If it can work on an ESP-32, it can work on x86 big-iron. ( I don't have a dog in this fight, yet, so tell me how I'm wrong.)
    - saidinesh5 5y ago
      Oh it really depends on your use case and the hardware you use for embedded devices. If all you need are some buttons and some kind of static lists, lvgl should be fine too. But for anything where you want things like smooth scrolling/higher resolutions you probably want to use the GPU. 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.
  - jollybean 5y ago
    QML comes with gigantically more memory usage and it's very inefficient at rendering text. If you want to render something that looks like a wikipedia page, prepare to pay a heavy price. 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.
nextaccountic 5y ago
Isn't Qt6 just LGPLv3? As in, the same as before?
- joezydeco 5y ago
  It's the same if you're going open source. It's not the same if you go commercial. See above.
saidinesh5 5y ago
I feel you. In fact after a decade of mostly C++ / Qt jobs, I've realized it's time to move away to other tech. More companies i worked with are avoiding Qt where they can. And even i was getting tired of creating the same QtQuick controls over and over again. 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).
- joezydeco 5y ago
  Qt 6 is available in LGPLv3 right? If you're already using 5.15, what would stop you from using Qt6? 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.
  - saidinesh5 5y ago
    Oh that sucks. Yeah Qt has gotten really aggressive with their licensing headaches. They broke so many of our CI scripts when they made it mandatory for you to log in to use their Qt installer even for online version. 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 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/ https://github.com/slint-ui/slint/ ).
kabes 5y ago
I think flutter might also fill the gap left by QT.

nextaccountic 5y ago

... what's the trouble with LGPLv3? Is Qt under LGPL 2.1? Were the changes so drastic?

saidinesh5 5y ago
The main problem with LGPLv3 is the anti-tivoization clause. That means you should basically provide the end user a way to replace the Qt libraries with their own. On embedded systems this can mean headaches for companies releasing commercial products. More details: https://embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/ 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.