KDE Now Maintaining Their Own Set of Patches For Qt 5

[oleid]

An object-oriented C++ base is better and cleaner than a C++ wrapper around a not-object-oriented base...

Good thing then that GTK, Glib, gstreamer & co are object oriented.

And yes, even Qt wraps certain non object oriented libs.

[Nth_man]

C is not an object oriented language, as we know.

Trying to use it as an object oriented language (and also putting a C++ layer on top of it), will bring the result of "an object-oriented C++ base is better and cleaner than a C++ wrapper around a not-object-oriented base...".

[mdedetrich]

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.

If we are talking about C/C++ (Qt is written in C++) then those start of the art libs either didn't exist or were reinvented with the typical C NIH syndrome (due to the fact that library/dependency management in C/C++ is a PITA). There were good reasons why Qt includes everything and the kitchen sink and arguably they still are good reasons. This is also the reason why GTK will never replace QT/KDE, GTK does window GUI/rendering and thats it.

Now if we are talking about something like Rust then yes what you are saying is true, Rust has extremely high quality libs and decent standardized package manager that makes it very easy for application to include an SQL library (for example).

[JackLilhammers]

... Mental saws ...

OT: I'm not sure you can translate it to english :'D

[Guiluge]

Because one of them decided to go with a fully proprietary toolkit in 1994 based on the promise that it may get GPL'd. So Gnome was born.

KDE is not a tech demo of Qt anymore, nothing for Qt to shine about, easily visible in the importance the Qt company sees in KDE, like zero, no importance at all.
KDE can go their own way, its not like there is much innovation in Qt6 anyways. They should focus on making a working desktop like back in the KDE 3 times.

What a nice little troll we have here...
KDE4 was a mess at first for sure, but it came to be nice and usable (after many iterations, that's true).
Plasma 5 works just fine, period.
If you don't like it, no problem, but stop ruining KDE threads for the sake of it.

[Guiluge]

Guiluge Alex is right that Qt doesn’t care about KDE.

So what ? My post wasn't about this statement.

[JackLilhammers]

Gtk fans in Qt threads remind me of the fox and the grapes :'D

By the way, we all know Gtk has slightly better licensing, but it's not enough to fill the technical gap with Qt.
Also, it's wrong and misleading to think about Qt in terms of Kde looks (it looks like Windows 95*), or to compare the relation between Qt and Kde to that between Gtk and Gnome.
In fact, most of those who taught me Qt programming were not running Kde. Many were not even running Linux.

Alexmitter
*I wouldn't discredit Windows 95 so easily. It shaped the modern desktop and it still feels familiar.
I'm quite sure you could use it without many hassles despite you weren't even born when it came out

[discordian]

If we are talking about C/C++ (Qt is written in C++) then those start of the art libs either didn't exist or were reinvented with the typical C NIH syndrome (due to the fact that library/dependency management in C/C++ is a PITA). There were good reasons why Qt includes everything and the kitchen sink and arguably they still are good reasons. This is also the reason why GTK will never replace QT/KDE, GTK does window GUI/rendering and thats it.

Qt has just nothing to do with C++, its more or less Java with its isolationist approach, own set of conventions separate from the OS (16bit strings on Linux) and a deep inheritance mess. "Being first" really is not any kind of good argument.

There is something to argue about hiding everything between a "binary interface", but given how bad C++ is interoperable between compilers and even versions of the same compiler hs is not a particular good argument outside of shipping every app with your own QT-libraries or requiring the same/compatible version systemwide.

Now if we are talking about something like Rust then yes what you are saying is true, Rust has extremely high quality libs and decent standardized package manager that makes it very easy for application to include an SQL library (for example).

Not sure if this is still because Rust is a one framework/compiler thing for now, the test will be how it will fare after a few big revisions.

You dont need to pick Rust, std::string is a proper C++ entity, there is std::filesystem, std::networking is in work. Those are thin layers over the used OS, instead of its own plattform with absurd levels of abstractions, bad design and limitations.
There is nothing wrong with C libraries either, glib is alot leaner and provides some of the abstraction in a way less intrusive way, and if you want performance you'd use something like libuv. even using raw posix sockets is a better interface than QNetwork with local sockets having another interface instead being transparently supported.

[Nth_man]

Gtk fans in Qt threads remind me of the fox and the grapes :'D
[...] it looks like Windows 95

More like OS/2 (which is previous), which in turn...

[MadCatX]

Qt has just nothing to do with C++, its more or less Java with its isolationist approach, own set of conventions separate from the OS (16bit strings on Linux) and a deep inheritance mess. "Being first" really is not any kind of good argument.

Qt was developed before STL became a thing so they had do roll their own standards.

There is something to argue about hiding everything between a "binary interface", but given how bad C++ is interoperable between compilers and even versions of the same compiler hs is not a particular good argument outside of shipping every app with your own QT-libraries or requiring the same/compatible version systemwide.

Qt has actually done a pretty good job to maintain binary compatibility. C++ on Linux has a well defined ABI so there should be no problems with building your apps with whatever compiler you want and link against any Qt version you want. I've been doing in for years, it works. The situation is worse on Windows but that's a Windows problem not a Qt problem.

You dont need to pick Rust, std::string is a proper C++ entity,

Unlike std::string, QString is a class specifically designed to handle text and by text I mean a human-readable set of symbols that represent a written language. std::string, OTOH, could almost be a typedef to std::vector<char> with a few utility functions. If you want proper Unicode support in your code, std::string alone is not sufficient whereas QString is.

there is std::filesystem,

QFile and QDir have been around since Qt1. That makes std::filesystem some 22 years late to the party.

std::networking is in work.

How thrilling, maybe we'll finally get there by C++23. We've had QtNetwork since Qt4 I believe.

even using raw posix sockets is a better interface than QNetwork with local sockets having another interface instead being transparently supported.

Except when you want to go multiplatform. WinSock2 is different to POSIX sockets and there had been no local socket on Windows at all until 2018. Qt devs knew that and introduced proper abstractions to make creating multiplatform applications as effortless as posssible.