Qt 6.1 Beta Released With Porting More Modules To Qt6

[JackLilhammers]

Yeah, the question isn't about when we get KDE 6 but whether Qt6 will die eventually if no serious maintainer/company forks it.

I say, Intel, Google and Canonical should fund this.

Although tQtC sucks, they're not going anywhere. Qt is widespread in automotive and industrial software.
Still, one can only dream that Intel buys them

[lowflyer]

The fork of Qt already exists and is well and alive for a couple of years already.

[d3coder]

Why would they do that? Now that Qt Company is no longer putting out LTS releases for open source users, how could anyone base a big project like KDE on a constantly moving target? I think they will eventually have to bite the bullet and fork Qt for their own sanity. That, or at least keep their own GPL-only patch set for whatever Qt release is chosen to base KDE releases on. Let Qt Company go off and support their proprietary embedded stuff on their own.

KDE was written when Qt was 100% proprietary, that's why GNOME exist, people wanted fully free desktop environment

> how could anyone base a big project like KDE on a constantly moving target
KDE is already based on a constantly moving target, except LTS releases, LTS releases are based on Qt LTS
Somebody will figure out how to deal with Qt for KDE LTS

[Morty]

how could anyone base a big project like KDE on a constantly moving target?

The simple fact is, LTS is not very important for KDE users and developers.
The users get whatever their distribution packages, namely whatever version the distribution selected when going into release mode. Usually not the LTS version due to schedules not matching, and distribution often preferring newer releases regardless of LTS status.
The developers either use whatever their distribution ships or update when they see the need. Or they also do development of Qt, and stay at the latest/GIT for that reason.

[Charlie68]

Why would they do that? Now that Qt Company is no longer putting out LTS releases for open source users, how could anyone base a big project like KDE on a constantly moving target? I think they will eventually have to bite the bullet and fork Qt for their own sanity. That, or at least keep their own GPL-only patch set for whatever Qt release is chosen to base KDE releases on. Let Qt Company go off and support their proprietary embedded stuff on their own.

You may not know, but KDE has always built on the latest stable QT version, not the LTS, which is mostly only used by some LTS distributions.
LTS is not synonymous with stability, but with "long-term support, KDE always recommends using the latest version of QT.
So for KDE nothing changes, the only problem is the transition to a higher version, because it takes longer. I guess they will keep the last QT of branch 5. ** until the transition to QT6, otherwise nothing will change.

[JackLilhammers]

Charlie68 I think Kde has bigger fish to fry than porting to Qt6 while it's clearly still in its infancy.
My guess is that they'll start thinking about Qt6 after Wayland is usable, so I'd say that it'll be at least another year, probably 2.
As soon as Wayland becomes default in Kubuntu 22.04 (and Neon 22) they'll be swimming in bug reports :'D

[Charlie68]

Charlie68 I think Kde has bigger fish to fry than porting to Qt6 while it's clearly still in its infancy.
My guess is that they'll start thinking about Qt6 after Wayland is usable, so I'd say that it'll be at least another year, probably 2.
As soon as Wayland becomes default in Kubuntu 22.04 (and Neon 22) they'll be swimming in bug reports :'D

Yes, I agree, before KDE moves to QT6, I think it will take at least a year, also because at the moment there is only basic support, many things have yet to arrive in QT6.

[bug77]

Why would they do that? Now that Qt Company is no longer putting out LTS releases for open source users, how could anyone base a big project like KDE on a constantly moving target? I think they will eventually have to bite the bullet and fork Qt for their own sanity. That, or at least keep their own GPL-only patch set for whatever Qt release is chosen to base KDE releases on. Let Qt Company go off and support their proprietary embedded stuff on their own.

Funny thing: Qt is less of a moving target than GTK. Major Qt versions are binary compatible, which is not necessarily true for GTK.
That's why withholding LTS releases has no big impact: you want something that's fixed in 6.2.15 (LTS)? You'll probably find the fix in 6.3 (non-LTS). Sure, upgrading the whole toolkit is costlier than just installing a bugfix release, but most open source projects target the latest Qt anyway.

[Vistaus]

Why would they do that? Now that Qt Company is no longer putting out LTS releases for open source users, how could anyone base a big project like KDE on a constantly moving target?

If KDE devs don't want a moving target, then they should at least set a good example by only shipping LTS Qt packages in their very own KDE Neon distro.

[cochise]

The fork of Qt already exists and is well and alive for a couple of years already.

It's dead Jim.

Charlie68 I think Kde has bigger fish to fry than porting to Qt6 while it's clearly still in its infancy.
My guess is that they'll start thinking about Qt6 after Wayland is usable, so I'd say that it'll be at least another year, probably 2.

It's already being worked.

And, if anyone forget this, KDE is a 1996 project. Qt's first LTS release was 4.8, from 2011. This "moving target" problem was not a issue for 15 years.