KDE Now Maintaining Their Own Set of Patches For Qt 5

[MadCatX]

Because people on here believe that you can't maintain a toolkit if you don't have 200+ people working on it.

Considering the less than ideal state of Qt which is developed by a team much larger than KDE, these people probably have a point.

[Charlie68]

No, KDE must remain QT, otherwise it has no reason to exist. Mental saws are users who often prefer one toolkin to another ..., QT is open source.

[M@GOid]

Here is something worthwhile for the rust people to rewrite ...

And them call it ...

Rt

[Yeayo guy]

All the discussions in this thread are nonsense, a waste of time and to spread hatred to Qt.
First, Qt is GPL and LGPL licensed.
Second, if you contribute Qt you allow them to make a dual license in GPL/LGPL and proprietary, yes, but your code will still be GPL. Also Qt is not a program, it's just a toolkit to make programs, it's not such a problem to allow a dual license when GTK for example can be included in proprietary programs in the same way as the proprietary version of Qt. Of course everything you contribute to GTK remains free software, but so does Qt because of its dual license.
Third, in a year KDE will be transitioned to Qt6.

[RealNC]

So there are already halfway towards doing their own https://www.copperspice.com/, why not just move over?

It would most probably be a hell of a lot of work to bring copperspice up to date, since it's a fork of Qt 4.

[cl333r]

Here is something worthwhile for the rust people to rewrite ...

Rust is not fit this kind of stuff, it's much worse than C++, it shines in the realm of little tools and random small libs.

[zerothruster]

I don't have much interest in kde, but for some purposes I use a browser (falkon) which is nominally within kde. And for that I need qtwebengine, so I'm pleased to see this development - in the future it might make it easier to keep that up to date. At the moment, a quick look suggests they are "only" at the 5.15.3 webengine fixes, for later fixes see https://code.qt.io/cgit/qt/qtwebengine.git/log/?h=5.15

To be fair, gentoo and Arch were at a similar point to that when I last looked.

Getting into the webengine fixes (i.e. chromium fixes) is a bit of a pain, the submodule needs to be on the 87-based branch at the moment.

And perhaps this will mean that distros like fedora and debian start to pick up the recent CVE fixes for qtwebengine.

[discordian]

It would most probably be a hell of a lot of work to bring copperspice up to date, since it's a fork of Qt 4.

If you drop using QTEverything (god awful QString, QXML, QNetwork, etc) then that would actually help in just using state-of-the-art libraries without layers of bugs and lower maintaining costs.

[cynical]

You're implying GNOME would accept patches that go against their "vision," which is... not true at all.

I don't write desktop applications for Linux so I'm not familiar with GTK/QT APIs, though from what I gather, QT takes the kitchen-sink approach. From what I see, Gnome developers were amenable to libhandy for augmenting GTK with new widgets that support mobile form factors, even to the point that there now exists a libadwaita to make that integration more official. What is GTK missing that Qt app developers want? Could anything less interesting to Gnome devs just be made into a library?

The only major thing I've seen people complain about is that GTK doesn't support other platforms well, but I think that argument is weaker now that mobile platforms are taking over, and afaik, Qt integration on iOS and Android is pretty terrible.

[cl333r]

What is GTK missing that Qt app developers want?

Just like with games, C++ is the preferred language when it comes to desktop apps or AAA games, it just has the best trade-offs.
So GTK being a C solution is enough not to like it. Its C++ backed (gtkmm) doesn't feel like C++ more like what it is - a C++ wrapper around C, not to mention the docs aren't fully ported, often have C copy-pasted material.
In the past GTK was a Linux only solution, the windows port was a crappy joke, don't know about now.
And as an API GTK isn't as professional as Qt.

OTOH Qt is too large, buggy and closed source these days.