KDE Now Maintaining Their Own Set of Patches For Qt 5

[eltomito]

I hope the people who suggest that KDE move away from Qt to some other framework are just trolling. Anyone who's done any GUI programming knows that switching to another framework amounts to pretty much rewriting the whole thing.

So, KDE is sticking to Qt. But this proprietary move is obviously a problem for them, because whenever the Qt people decide, KDE will be left without upstream support until they manage to bring all their code to the new version of Qt. This is the first time it's happening. We'll see how long it takes KDE to transition to Qt6. But I sort of suspect it's going to take so long and so much effort that KDE will have no choice but to strike some kind of special deal with Qt, because both forking it and updating to higher versions all the time will prove to be a death sentence.

[cynical]

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.

Yeah that's a fair criticism. I have my own language preferences, and I can understand people not liking C or the C++ bindings. Personally I don't like either of them myself and would prefer Rust. It's not even that I like Rust itself, it's just the most tolerable of the manual memory management languages, and I favor functional programming over OO.

Basically everything. Qt knows how to do file system access, networking, image manipulation, audio and video playback, IPC, process management, threading. It also does it equally well on a lot of platforms from Windows to QNX. GTK has always been a Linux-focused GUI toolkit which is today developed mostly to serve the needs of GNOME.

Well you have GIO and other libraries for things like file system access. Of course all of those libraries are dependent upon C. Part of the reason that KDE's fate is tied to Qt is that everything is handled there. I'm starting to be convinced that the reason people favor one over the other comes from the difference between C and C++. I think it's pretty clear that C++ provides a nicer API in general for something like UI or networking programming because it is OO, and Gnome ends up having to simulate that in C to make a poor man's C++.

I wonder if Rust can fix that in the future. I firmly believe that functional programming has the better UI model. There are no good short term answers though.

I hope the people who suggest that KDE move away from Qt to some other framework are just trolling. Anyone who's done any GUI programming knows that switching to another framework amounts to pretty much rewriting the whole thing.

That's why I said it was a dream. I'm well aware they would have to rewrite everything, and so it won't happen. They will always have a precarious relationship with that company though. It will no doubt become worse over time as their financial pie shrinks. Qt Company is betting the farm on IoT/embedded use cases, which is sensible, but why would you choose to use Qt over something like Flutter, which will have much better support on mobile?

[Yeayo guy]

Poor Qt, it must really suffer from all that hatred.


Sure, but the Qt company and only them decide if a certain release is GPL/LGPL or if it stays fully proprietary as they wish. That is nothing but a loose promise of the Qt


That is technically incorrect.
The moment you commit to the Qt repos, you have to give away all rights to your code, it is not anymore GPL/LGPL licensed and you do not hold any rights on it, you could not even have it removed later. That is a workaround around the net of ownership that normally protects a GPL/LGPL project from ever ending up proprietary.
Right in this moment, a technician at the Qt Company could extend code that was committed by a KDE person in the 5.x stack and the KDE community will never see that improved code.



More like 3 years for the core projects and another 2 for the surrounding projects.

That's not true, I think you should read again the Qt's Contribution Agreement.

[MadCatX]

Well you have GIO and other libraries for things like file system access.

But this is exactly the problem. Sure, you can use TinyXML and jsoncpp to parse internet resources and stuff, GnuTLS to fetech them securely, C++20 coroutines to do it asynchronously, GStreamer to play multimedia, GIO or std::filesystem to access files, etc. It will probably work just fine but it will much more of a pain to maintain code written like this. If you write code against Qt and use as much of Qt functionality as possible, you are targeting a single framework that is developed, tested and deployed as a whole. This is a lot better than having to target fifteen independent libraries with their own APIs, datatypes and release cycles.

[danielnez1]

I disagree. For at least 90 % of cases, functionality provided by Qt is good enough. Need to load a PDF and paint in on the screen? Or do text encoding conversions? Or fetch a JSON from a server over TLS, parse it and display the content? Or maybe you have some data in a SQLite database? Perhaps now you want to visualize that data in a 3D chart? Not a problem, Qt has your back. Unless you have some very specific needs, I really don't see what is Qt doing badly.

And unlike Qt, GTK is basically a non-entity outside the Linux/FOSS bubble.

[oleid]

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

There are a few rust based toolkits, check out https://github.com/hecrj/iced and https://github.com/linebender/druid - they are the most popular ones.

[oleid]

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.

Well, there are rust-native toolkits. They have a different design than your usual off-the-self C++ GUI toolkit, but guess what: what you get is thread-safe

[oleid]

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++

I don't know, I think the API of gtkmm is much cleaner and nicer than Qt. And it integrates nicely with STL.

In the past GTK was a Linux only solution, the windows port was a crappy joke, don't know about now.

Fast forward to today: GTK4 is very easy to build on windows, is fully hardware accelerated.

And as an API GTK isn't as professional as Qt.

How do you measure that?
I recall trying to use Qt to create PDF files from a batch process. Using the QConsoleApplication. Turned out you need a QApplication to create PDF files. For some reason, PDF files were handled using some printing context.

In the end, I created the PDF files with cairo. Cairo doesn't care what device you are writing to, everything is nicely abstracted away.

[Nth_man]

But this is exactly the problem. Sure, you can use TinyXML and jsoncpp to parse internet resources and stuff, GnuTLS to fetech them securely, C++20 coroutines to do it asynchronously, GStreamer to play multimedia, GIO or std::filesystem to access files, etc. It will probably work just fine but it will much more of a pain to maintain code written like this. If you write code against Qt and use as much of Qt functionality as possible, you are targeting a single framework that is developed, tested and deployed as a whole. This is a lot better than having to target fifteen independent libraries with their own APIs, datatypes and release cycles.

And you work better with coherent code that follows norms and styles, source code that does not look like a Frankenstein monster (a part from that library, a part from another one...).

The API is much cleaner - a lot of that is because it's based around an object-oriented C++ base rather than C.

And you prefer well done documentation. Obviously a nicely designed API makes it easier and less expensive to document.

[oleid]

But this is exactly the problem. Sure, you can use TinyXML and jsoncpp to parse internet resources and stuff, GnuTLS to fetech them securely,

You would use libsoup in the gnome universe.

C++20 coroutines to do it asynchronously, GStreamer to play multimedia, GIO or std::filesystem to access files, etc. It will probably work just fine but it will much more of a pain to maintain code written like this.

Is it?

If you write code against Qt and use as much of Qt functionality as possible, you are targeting a single framework that is developed, tested and deployed as a whole.

Ack.

This is a lot better than having to target fifteen independent libraries with their own APIs, datatypes and release cycles

It depends on the length of the release cycles.

C++ stl is *INSANELY* stable.
gstreamer is *VERY* stable since its 1.0. No breaking changes for years.
libsoup is stable for years.

Actually, you have more breakage with Qt.

EDIT:

I wonder why the same people which argue pro UNIX philosophy prefer huge frameworks over libraries.