Qt 6.0 Might Be Coming After Qt 5.14, Could Depend Upon C++17

[carewolf]

Out of curiosity, which applications are those? I don't think I'm currently using any Qt 4 applications, although that was the case for me back in 2015-2016.

Yeah, the last one I had was clementine, and it has had a qt5 version for years, and last time I used the qt4 version was a few years back.

Anyway. That whole situation with getting projects to upgrade is why source compatibility is so strongly pursued by Qt, without too may projects do not upgrade. Particular Qt3->Qt4 was tough.

[miabrahams]

Hopefully the KDE port will be less aggravating since there is no major overhaul like the split of kdelibs into KDE Frameworks. But the Qt developers really need to minimize the massive source incompatibilities if they want it to be less horrible. It does sound like they understand this now.

A Qt 6.0 release in 2020 means the first stable versions (Qt 6.3 most likely) won't come out until until around 2021. That gives Qt users have about three years before porting becomes a real concern. That is also enough of a time window for Qt to create sufficient tooling.

[ssokolow]

Yeah, the last one I had was clementine, and it has had a qt5 version for years, and last time I used the qt4 version was a few years back.

Anyway. That whole situation with getting projects to upgrade is why source compatibility is so strongly pursued by Qt, without too may projects do not upgrade. Particular Qt3->Qt4 was tough.

I'm still running TDE's Qt 3 version of BasKet Note Pads because, when I tried to load my data into the KDE 4 version, it froze up.

That said, in the near future, I hope to start working on a more comprehensive PIM solution which would subsume the aspects of BasKet that I use. (As well as a ton of other silo'd data stores I've come up with over the years.)

[t.s.]

Yeah, the last one I had was clementine, and it has had a qt5 version for years, and last time I used the qt4 version was a few years back.

Anyway. That whole situation with getting projects to upgrade is why source compatibility is so strongly pursued by Qt, without too may projects do not upgrade. Particular Qt3->Qt4 was tough.

My Arch still have quite plenty qt4 related packages: attica-qt4, libdbusmenu-qt4 phonon-qt4, polkit-qt4, qca-qt4, kdelibs, kdebase-runtime, breeze-qt4, oxygen-qt4, etc.. Maybe I'll try to remove those package and see if it will break my plasma desktop or not.

[Vistaus]

Source compatible means a program written to be compiled on X [...]

But we're trying to get rid of X. Sorry, I couldn't help myself :P

[Vistaus]

Apparently we will need three versions of Qt simultaneously. I still have apps that depend on Qt 4.

Meanwhile, people are complaining about the "GTK 3 mess" while Qt apps still aren't even fully ported to Qt 5...

[Vistaus]

Particular Qt3->Qt4 was tough.

But everyone keeps touting that Qt has a very easy upgrade path, so how can it be "tough"? And aside from the community, even the Qt team themselves tout that it's very easy to upgrade: https://blog.qt.io/blog/2018/05/24/porting-from-qt-1-0/

[cochise]

I'm still running TDE's Qt 3 version of BasKet Note Pads because, when I tried to load my data into the KDE 4 version, it froze up.

Try the 2.49a version with Qt 5 and Frameworks 5.

I don't have any Qt 4 program, but many programs still using deprecated KDE 4 classes (ported to Qt 5) from kdelibs4support.

[Luke_Wolf]

But everyone keeps touting that Qt has a very easy upgrade path, so how can it be "tough"? And aside from the community, even the Qt team themselves tout that it's very easy to upgrade: https://blog.qt.io/blog/2018/05/24/porting-from-qt-1-0/

It's because when they say "Qt 3 -> Qt 4" was tough what they really mean is Qt 3 -> Qt 4 + KDElibs3 -> KDElibs4 + Refactoring and General Rearchitecting + that whole shift to the Plasma Architecture... in a massive codebase. Which means the whole process was fairly involved and therefore "tough"

Same goes for Qt4 -> Qt 5. because KDE decided it was time to decouple the project and replace KDELib with KDE Frameworks and upstream a lot of it into Qt, among other things

Qt5 -> Qt6 shouldn't be particularly disruptive. There's no flashy new tech in Qt like there was with the Qt 4-> Qt 5 transition with Qt Quick, and the KDE side should be fairly stable unless there's news I've been missing.

[carewolf]

But everyone keeps touting that Qt has a very easy upgrade path, so how can it be "tough"? And aside from the community, even the Qt team themselves tout that it's very easy to upgrade: https://blog.qt.io/blog/2018/05/24/porting-from-qt-1-0/

The example in that blog was using simple things, Qt always strives to make the 90% simple and the rest possible. One big problem with the Qt3 to Qt4 upgrade was the redesign of model-control-view, where it was heavily integrated in monolithic classes in Qt 3, but was split apart in more flexible classes in Qt 4. This splitting apart meant that applictations using the model-view Qt3 classes had to do some refactoring. Other classes went into Qt3Support like containers with auto-delete of containted pointers, which you had to port away from if you wanted to avoid libqt3support, or at the latest when upgrading to qt 5. For most applications this was not a problem, but for a few it was either tough, or just non-trivial in semi-dead project, which made it tough for the Qt project as some Qt-using applications lacked for a long time.