Qt 5.15 Standard Support for Legacy License Holders Ends Today
qt.io
qt.io
That is quite a bold claim. Tesla used QT which I think they are referring to, but I don't think the choice of QT contributed to the disruption on the automobile industry.
I don't see Microsoft making such claims.
And frankly, there are some technical properties of Qt that do make it well-suited to the kinds of problems car makers need to solve. For example, Qt is quite good at offering customizability and extension points at low/mid/high levels of the toolkit. It's easy to subclass/extend/replace UI controls in various ways. When you need your UI controls to do unusual things not found on other kinds of systems, for example implement regional rules for driver distraction, that's useful.
At the end of the day, there's likely more EVs on the road with Qt on them than without.
The Dragon dashboard is also mostly presenting information, it's not used to, say, pilot/operate the vehicle, change settings or other complex applications.
Average people need not apply.
What I'd be curious about is how they handle updates. The Web platform is a moving target, and it's not like Chromium engineers are pushing features with "astronomical" failure cases in mind. Even if the SpaceX software is perfectly tested, it could break in possibly uncovered ways with each new update. So does SpaceX keep it up to date and run the same battery of tests on each version? Or do they freeze the version and only update along with their normal SDLC?
EDIT: FWIW, it looks like the original source of the Chromium claim is a Reddit AMA [0] with more details from the SpaceX software team.
[0] https://old.reddit.com/r/spacex/comments/gxb7j1/we_are_the_s...
A minimum and easy to build fork of QT
Edit: thank you for your responses!
Remove every use of the previous QRegExp class (no longer existed in QT6), which was always bad, and replace it with the similar but slightly different behaving QRegularExpression class. Different enough that it's not just a simple grep.
Rip out huge chunks of XML processing code that used QT5 XML libraries that were outright withdrawn, and replace them with alternatives.
Rewrite some sound generating code to switch away from Qt5 classes that straight up no longer existed, to something else.
Rip out uses of the QT5 web engine classes; I think I recall it was replaced wholesale in QT6, but it was nothing but trouble through its life so there was an outright rewrite of everything using it to just do something non-web instead.
Any others that were outright withdrawn we also must have replaced. Can't remember them all, but here's a list: https://doc.qt.io/qt-6/whatsnew60.html#removed-modules-in-qt...
Some of those have an extended life in a QT6 "QT5 compatability module", but that's clearly not going to get a lot of security and bugfixes and there's no telling when it might vanish.
Lots of very fiddly changes to the Qt metatype system had people trawling through weird and wonderful error messages working out what was going on and how they could replace it.
QT6 demanded to be built under C++17; after switching the compiler to that, there sure was a whole lot of old code that either didn't compile at all, or flashed heavily red when the compiler looked at it, that demanded a rewrite.
All this, and when you're done, you've got something that's probably functionally about the same as what you had beforehand, but the previous version of the software under QT5 had a decade of use testing and this is brand new.
No customer is going to pay for all this effort, so there is very little impetus on anyone to move from QT5 to QT6 if the QT5 version works and updates keep coming. It's only at the end that people are finally forced to make a move.
If you're using Qt applications purely in the open source world (e.g. KDE on some Linux distro) there's no new news here.
A lot of small businesses use Qt for free under the LGPL license (allowing them to keep their application closed-source as long as the user is free to replace the Qt dynamic libraries). For the past several years many new modules are commercial or GPL only, preventing their use by LGPL users. For example, QtWayland, QML Virtual Keyboard, WebGL, Qt Quick 3D.
Some companies would bite the bullet and pay for Qt their exorbitant fee, then let the license expire and keep using the old version. As you say, this will no longer be possible.
I find Qt 6's license policy awful, I simply don't believe in "pay us forever even if you're happy with an old version". Early on Qt 6 even had a draconian commercial policy that wouldn't allow you to distribute an old binary after if your license was expired and you stopped new development, thankfully they walked this back.
- The initial versions of LTS point releases (so e.g. something like a 5.15.0) are open source. The commercial-only begins a few point releases in, say with something like a 5.15.3.
- Due to the KDE Free Qt Foundation agreement, also those initially commercial-only point releases do become open source eventually, at a max 12 month delay.
This was indeed very controversial when it was done for the first time with Qt 5.15.*, since that is the last major version if Qt 5, which effectively meant no same-day open source maintenance releases for Qt 5 anymore after some point. Within the Qt 6 release series it's less of a big deal, in that by the time a 6.x.y is released commercial-only, usually the next 6.x is already around the corner.
Years ago, I used to write software for medical devices which used QT, and those were supported in the wild for 10 years.
I think its also popular in cars and stuff nowadays.