KDE Now Maintaining Their Own Set of Patches For Qt 5

[oleid]

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...".

I'm sorry to destroy your worldview, but objects essentially boil down to structs. C has structs. So you can create objects in C. C++ provides syntactic sugar on top of that, but that's all.
A member function is little more than a function, whose first parameter is a this pointer.

It is not hard to add that sugar when wrapping it in C++.

[discordian]

STL has become a standard in 1998.

C++ has become a standard in 1998. Why was Qt using it before?

I just recently had to build some Linux-only code on Windows. I ended up ifdefing to WinAPI because it required no additional dependencies and was most likely to actually work.

Well, glad you dint need to install some external package like QT.

Really now? I was under the impression that the proper equivalent of AF_UNIX socket on Windows was a named pipe. Google search for a winsock equivalent of this comes up empty.

can you code an socket interface around a named pipe? If yes, then that providing this as a QAbstractSocket inteface would be preferable.
I mean, you dont complain about QString not beeing 8bit UTF on Linux...

Which is not multiplatform at all because it discusses POSIX sockets on UNIXes and those few bits about Windows are outright wrong (it's _beginthreadex() and not CreateProcess() for instance). It's been a while since I've done this but I recall that even select() behaves a tad differently between Win/Lin. QSockets also come with a nice async interface whereas with raw sockets you have to fork, block, synchronize...

POSIX is a standard, supported by multiple Platforms natively and many more through compat layers. Even down to hard RTOS for microcontrollers with 256K RAM. Cant get more crossplatform than that.

[discordian]

I am not sure you know how old QT is, but these things either exist in the old days of C++ or had problems (particularly when it comes to portability) hence why Qt implemented themselves, it was the completely rational thing to do.

And CVS was created when Git was nonexistent, is that now an argument to stick to non-distributed systems nowadays?

Not only that but since we are talking about C++ here, the package/library management systems in C++ are absolutely terrible/pathetic from a usability standpoint when you compare it to languages like Python, Ruby, Java, Scala, Rust etc etc. In C++ there is no standardized way to deal with moduless/libraries and everyone kinda tries to do their own thing so the while concept of pulling in a really good library for IO and a really good library for networking and a really good library for command line parsing etc etc etc is painful in C++ contrasted to newer languages (iirc the C++ standards team tried to make a standard for modules but I have no idea how that went).

The issues with C++'s lack of standard packaging still prevails, if you want to use Qt libraries outside of the "base installation". And on any distro that issue is necessarily solved.
You cant write modern C++ with Qt, you cant mix libraries because Qt doesn't use the existing standard library.

So why not just use Java, why does Qt even exist? Cant think of a downside compared to Qt, AFAIR Qt even manages to be slower for parsing XML.
Heck they even are bold enough to deprecate their badly designed libraries (probably already half of their API).

So yeah, I agree with you that its not ideal that Qt contains a GUI library and the whole kitchen sink, but considering that its a cross platform widget toolkit that runs on every major OS and its using a language that had a terrible way of dealing with multiple libraries and their transitive dependencies I am not surprised it turned out this way. If there was a Qt in Rust, then yeah this wouldn't be the Rust way of doing things because Rust has cargo which is something that pretty much every Rust programmer uses.

Well, I could just code assembler for C64 and have it run everywhere Qt does and more. You are quickly reaching the point of the advantages and limitations of an Emulator (or "virtual machine" like the young grasshoppers say). A sensible cross-platform definition would mean adapting to the platforms, not replacing them (eg wxWidget). Otherwise everything is cross-platform if you package it with qemu/vmware/c64emulator.

[MadCatX]

Not quite correct. First public release of the STL was in 1994 while the first public release of Qt1 was in 1995. Despite that "technical detail" I'd assume both were concieved at around the same time. But the Trolls at Trolltech were not interested in any standard and went with the only thing they knew at that time: Java. (superiority complex?)

STL has become a standard in 1998.

Wrong. Proper unicode support is difficult. QString does not cut it either. With QString you assume you're correct until the first time you deal with real unicode.

I knew somebody would bring this up. With std::string, every character that lies outside the [1;127] ASCII range is a potential edge case. WIth QString your edge cases will be actual edge cases.

Dirent.h predates both and is still easy to use with C++20. But if you prefer a mess then QFile and QDir (and the necessary companion classes like QFileInfo) are quite handy. Any other library is easier to use.

I just recently had to build some Linux-only code on Windows. I ended up ifdefing to WinAPI because it required no additional dependencies and was most likely to actually work.

It's funny to watch how many people make a whole herd of Elephants (including the oxpeckers) out of that single tiny difference between WinSock2 and POSIX sockets. And wrong again: local sockets were always available on winsock and significantly more performant than on Linux.

Really now? I was under the impression that the proper equivalent of AF_UNIX socket on Windows was a named pipe. Google search for a winsock equivalent of this comes up empty.

Regarding multiplatform, nothing beats Beej's guide to network programming which is available since the dawn of time. The wrapper classes of QNetwork are simply not necessary.

Which is not multiplatform at all because it discusses POSIX sockets on UNIXes and those few bits about Windows are outright wrong (it's _beginthreadex() and not CreateProcess() for instance). It's been a while since I've done this but I recall that even select() behaves a tad differently between Win/Lin. QSockets also come with a nice async interface whereas with raw sockets you have to fork, block, synchronize...

[mdedetrich]

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.

I am not sure you know how old QT is, but these things either exist in the old days of C++ or had problems (particularly when it comes to portability) hence why Qt implemented themselves, it was the completely rational thing to do.

Not only that but since we are talking about C++ here, the package/library management systems in C++ are absolutely terrible/pathetic from a usability standpoint when you compare it to languages like Python, Ruby, Java, Scala, Rust etc etc. In C++ there is no standardized way to deal with moduless/libraries and everyone kinda tries to do their own thing so the while concept of pulling in a really good library for IO and a really good library for networking and a really good library for command line parsing etc etc etc is painful in C++ contrasted to newer languages (iirc the C++ standards team tried to make a standard for modules but I have no idea how that went).

So yeah, I agree with you that its not ideal that Qt contains a GUI library and the whole kitchen sink, but considering that its a cross platform widget toolkit that runs on every major OS and its using a language that had a terrible way of dealing with multiple libraries and their transitive dependencies I am not surprised it turned out this way. If there was a Qt in Rust, then yeah this wouldn't be the Rust way of doing things because Rust has cargo which is something that pretty much every Rust programmer uses.

Actually MadCatX just said everything better than I did.

[JackLilhammers]

discordian
lowflyer
Every time there's a Qt thread there's also someone listing all of Qt shortcomings (and there are many of course), why it sucks (it doesn't), and why you could replace this part of the framework with this new standard, or how you can achieve the same functionality of that module with that library, and so on...

You're both ignoring the bigger picture. It's not the single classes, it's the "ecosystem" that matters.
Qt is an application framework and as such it provides its users a lot of stuff to do things in a cohesive way.

This brings the discussion to a whole different level, that is: should I use a framework?
As you can imagine this is not Qt specific and there are tons of literature about pros and cons of both sides of the argument...

[MadCatX]

C++ (the standard) was released with STL, so either thats wrong, or QT did not have a standardised language either

C++ the programming language was first released in 1985, then updated in 1989. STL was conceptualized in 1993 and it only became a part of ISO C++ standard in 1998. Qt1 was released in 1995.

Oh god no, there are issues on ARM atleast where definitions don't agree between clang and gcc, and this ends up changing your ABI because of name mangling.

This looks like an ARM-specific issue. x86 and x86_64 is okay in this regard.

QString is not fitting anywhere, the encoding of the filesystem can and often is different to the UI. Is easy to add a localized string type on top of std::string.

Filesystems don't have encodings (NTFS being a notable exception). A filename is just a raw string of bytes with no "human meaning". QString provides both Unicode support and conversion routines to multiple encodings, the fact that it uses UTF-16 as internal representation is just an implementation detail which probably made sense back then. The problem of proper text representation goes far beyond filesystems. If you, say, need to translate your UI to multiple languages, good Unicode-aware toolkit is a must and Qt is such a toolkit.

POSIX has been around longer, so what?

I believe we are discussing C++ and platform-agnostic APIs. POSIX is neither C++ nor platform-agnostic.

I used POSIX sockets before that, good standards take time.

On Windows?

Both stem from Boost which had those libraries (filesystem and asio) around for quite some time. Proper C++, openly developed vs shoddy "First!!!".
Another notable library would be std::format. But of course, someone using QT wouldn't know a thing about anything that's happening in the world,
its another language than C++ for what I am concerned.

Boost had its filesystem extension since version 1.30 released in 2003. By that time Qt was already at Qt3. Asio came even later (2008?)

How long till QT supported critical language features like move semantics btw?

QString, for example, has had move c-tor since Qt 5.2 released in late 2013. Considering how long it took some compilers to support C++11 it'd say that's reasonable. To be fair, Qt developers do admit that the state-of-the-art STL containers are superior to what Qt has. That, however, doesn't make the Qt containers bad or useless.

Another option wouldve been to take a well established standard (POSIX) and implement the pieces missing on the one OS that doesnt support it, instead of effing things up for everyone else. Including doing ridiculous stupid stuff like dropping the already bound address if you did a udp connect (fixed in QT5 I believe).

The whole idea of Qt is to enable development of complex and truly multiplatform applications with as few ifdefs and platform-specific hacks as possible. You can't do that without some abstraction. Just because they didn't always get it right the first time doesn't mean that Qt's philosophy is inherently wrong.

[JackLilhammers]

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

Yes, it's likely, but nobody ever compares Qt looks with with OS/2's. At least none of the usual trolls

[lowflyer]

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

Not quite correct. First public release of the STL was in 1994 while the first public release of Qt1 was in 1995. Despite that "technical detail" I'd assume both were concieved at around the same time. But the Trolls at Trolltech were not interested in any standard and went with the only thing they knew at that time: Java. (superiority complex?)

The situation is worse on Windows but that's a Windows problem not a Qt problem.

It's actually not so bad on windows. (You can always compile yourself from source ... !!?!) Just the license situation is worse on windows.

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.

Wrong. Proper unicode support is difficult. QString does not cut it either. With QString you assume you're correct until the first time you deal with real unicode.

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

Dirent.h predates both and is still easy to use with C++20. But if you prefer a mess then QFile and QDir (and the necessary companion classes like QFileInfo) are quite handy. Any other library is easier to use.

How thrilling, maybe we'll finally get there by C++23. We've had QtNetwork since Qt4 I believe.
...
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.

It's funny to watch how many people make a whole herd of Elephants (including the oxpeckers) out of that single tiny difference between WinSock2 and POSIX sockets. And wrong again: local sockets were always available on winsock and significantly more performant than on Linux.
Regarding multiplatform, nothing beats Beej's guide to network programming which is available since the dawn of time. The wrapper classes of QNetwork are simply not necessary.

[discordian]

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

C++ (the standard) was released with STL, so either thats wrong, or QT did not have a standardised language either

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.

Oh god no, there are issues on ARM atleast where definitions don't agree between clang and gcc, and this ends up changing your ABI because of name mangling.

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.

QString is not fitting anywhere, the encoding of the filesystem can and often is different to the UI. Is easy to add a localized string type on top of std::string.

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

POSIX has been around longer, so what?

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

I used POSIX sockets before that, good standards take time.

Both stem from Boost which had those libraries (filesystem and asio) around for quite some time. Proper C++, openly developed vs shoddy "First!!!".
Another notable library would be std::format. But of course, someone using QT wouldn't know a thing about anything that's happening in the world,
its another language than C++ for what I am concerned.

How long till QT supported critical language features like move semantics btw?

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.

Another option wouldve been to take a well established standard (POSIX) and implement the pieces missing on the one OS that doesnt support it, instead of effing things up for everyone else. Including doing ridiculous stupid stuff like dropping the already bound address if you did a udp connect (fixed in QT5 I believe).