Qt 6.0 RC1 Takes Flight - Qt 6.0 Should Be Here By Mid-December

[JackLilhammers]

That's not ideal either...

Indeed, but as a user I'd gladly wait a year for Qt 6 if that means perfecting Plasma 5.
Except of course if there are bugs that block Wayland and whose solution necessarily passes from Qt 6.

PS: Wayland or one of the other goals set in 2019

[StefanBruens]

I don't think binary compatibility between major versions will happen. As non-disruptive as this release is supposed to be, simply removing deprecated stuff prevents older binaries from working.

The main reason for a new major version is breaking binary compatibility, otherwise one could just call it Qt 5.16. Qt 5.0 happened 8 years ago, still supporting C++03 which was the only supported version for some platform specific proprietary toolchains. Keeping support for deprecated stuff indefinitely becomes a support burden.

Qt6 rips out all the deprecated stuff from the C++03 days. The good part is, Qt5.15 (and even 5.12) already has support for the majority of cleaned up APIs from Qt6, so the is no ABI compatibility but source compatibiliy.

As for what this means for KDE... probably not much at the moment. The whole team barely copes with adding support for Wayland+Qt5. If Qt6 doesn't simplify that dramatically, my guess is they'll do what they did with Wayland: sit it out until in matures significantly.

Would be nice if people who are not involved with KDE would stop speaking up and spreading nonsense. Porting is already happening for months, mostly ripping out use of deprecated APIs from the C++03 era. Nobody is sitting anything out ...

Regarding Wayland porting, most applications are completely done, for many months. Qt does abstract away platform differences. There are some applications which need more effort though, e.g. KRDC and Spectacle (both grabbing screen contents) both require the quite recent APIs implemented on top of pipewire, and of course kwin+ksceen which are just to platform specific and lowlevel to be covered by Qt.

[StefanBruens]

That's not ideal either. It means you won't have anything ready to ship for 2 years from now. You'd normally start working on porting right away, in a separate branch, report bugs and add more stuff as things get added back to Qt. But like I said, there aren't enough people working on the project to do that.

Stop spreading lies. Qt6 (KF6) porting is already on the way in the main branch for months.

[bug77]

Indeed, but as a user I'd gladly wait a year for Qt 6 if that means perfecting Plasma 5.
Except of course if there are bugs that block Wayland and whose solution necessarily passes from Qt 6.

PS: Wayland or one of the other goals set in 2019

But we weren't talking users here, we were talking about developers

Stop spreading lies. Qt6 (KF6) porting is already on the way in the main branch for months.

I wasn't spreading anything, I was expressing my feelings, based on my interactions with KDE so far.
If work is already underway, good for them and good for us (but I'm sure someone will pop up saying they shouldn't bother with porting until they fix Wayland support).

[cochise]

Frameworks 6 and Plasma 6 are on the way. Qt6 will be source compatible with Qt 5.15 if you don't use deprecated classes, so the work already started a long ago.

Qt6 will remove a lot of deprecated things, and KDE is porting away from that for months. Frameworks 6 will remove a lot of things almost no one uses, like Kross, so, the applications are being ported away.
As Qt Quick will have a lot of changes (removing all the points its haters dislike, like a JS runtime) porting the plasma should be a little harder.