KDE Now Maintaining Their Own Set of Patches For Qt 5

[MadCatX]

The reason Qt didn't use STL isn't that it didn't exist. It's that 20 years ago STL sucked.

You're not thinking sufficiently ancient history. First version of libstdc++ was released with GCC 2.95 in 1999. EGCS 1.0 with a borrowed STL implementation came out in 1997. Qt1 was released in 1995. First publicly available STL library ever saw the light of the day in 1994.

[oleid]

[QUOTE=Nth_man;n1249517]

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

> Neither you can cite, nor you can argue properly [...]

Neither you can cite, nor you can argue properly. Like when you write "but that's all" about object orientation (really mistakenly).
.

It is all. Object orientation is syntactic suggar. You can transpile C++ to C. Your CPU doesn't know a thing about objects.

But you missed the whole point. The argument was about object oriented C libraries. Like GTK or glib or gstreamer.
Which can nicely be wrapped in idiomatic c++. You don't need a language which natively supports polymorphism and whatnot to be able to create object oriented code. Certainty it is easier to use e.g. C++ to do that, but that was not the question.

Or when you wrote that "Qt forces you to do stuff in a pre-C++11 way".
.

Congrats that you dug up a four year old post. I was referring, for example, to things like code preprocessors (moc) and the usage of new and delete. You don't use these in modern c++ codebases. Also, I was using Qt4.8 at work back then. And we all know, Copperspice was created for good reason. Things improved with Qt5 since then.

Feel free to write but I’m done reading there and have much better things to do.

I guess that's better for the sake of the forum.

[tildearrow]

[*]GTK developers consider it to be as-intended that you can't rename or delete things inside the file picker but, instead, have to open up the file browser and navigate to it the long way. As soon as I upgrade my Kubuntu LTS, I'm planning to set USE_PORTAL globally to see how many GTK apps I can rid of it.

I would like to complain.

The KDE file picker is extremely slow on directories with a lot of files. For some reason it fills the list with file updates as it reads more files, which might give the user the illusion that the files are loading, but it blocks (even delays!) user input, making it hard to type the filename if the user already knows it in the "file" text input field (even worse, if you press Enter before the file picker has finished loading the directory, it QUEUES your input until all the files have loaded for some dumb reason, forcing you to wait 30 seconds for the list to finish loading).
On the other hand, the GTK file picker doesn't do this, which allows you to type the file name and press Enter even before the directory is loaded (of course, the file list doesn't update to give you an illusion of "loading" but at least it doesn't block like crazy)......

Furthermore, when using portal, the KDE file picker takes up to 10 seconds to appear (the GTK picker takes one second).

[lowflyer]

STL has become a standard in 1998.

I don't deny that. When did Qt become standardized?

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.

Well, you're wrong. The range of a codepoint in std::string is [1;255]. The biggest difference between std::string and QString is not the character handling, it's the memory handling. QString does "implicit sharing". That's why QString copies are fast - but they are actually not copies.

Regarding character handling, the Trolls at Qt made the same mistake that Microsoft did and used UCS-2 (not to confuse with UTF-16). This is the same that you get with std::wstring. QString is just a container for 16-bit codepoints. When you are working with any of the UTF-* encodings you'll run into exactly the same problems on both. Perhaps a little bit later than with std::string.

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.

Well, that is different. In your original post you were talking about local socket.

[lowflyer]

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

Every time there's a Qt thread there's also someone praising Qt high above the sky while denying any shortcomings (and there are many of course) ...

You accuse me of ignoring the "bigger picture". Well, I'm working daily on a >1MLOC project with some modules using Qt and some not being able to use Qt. Well, you can call that an "ecosystem", and you're correct it's the ecosystem that matters. On a daily basis I'm confronted with the "bigger picture" question: shall we keep the Qt application framework as part of our ecosystem?

Over time we have found more an more areas where Qt actually sucks, including licensing and support. This made us look around for alternatives. It's almost always better to use the STL. While I don't deny that Qt provides its users "a lot of stuff", the "cohesive way" is provided by other libraries as well. No distinct advantage of Qt. The only "advantage" is that you get "everything out of a single hand". But that depends heavily on the platform. (library dependency handling is different windows than on Linux. On some platforms you do not care...)

A serious software engineer always keeps an eye on alternatives. We have recently managed to get away from qmake. Our next step is to get away from Qt Creator. Don't get me wrong, Qt is probably really the best user interface toolkit. But the trolls just tried to dance on too many weddings simultaneously. To get rid of the rest of the Qt libraries is already a discussion point on our table. Whether we are able to pull that off is another question.

[JackLilhammers]

It is all. Object orientation is syntactic suggar. You can transpile C++ to C. Your CPU doesn't know a thing about objects.

Following that thought, C is syntactic sugar over machine code...

[TemplarGR]

Following that thought, C is syntactic sugar over machine code...

It is

[JackLilhammers]

Every time there's a Qt thread there's also someone praising Qt high above the sky while denying any shortcomings (and there are many of course) ...

You accuse me of ignoring the "bigger picture". Well, I'm working daily on a >1MLOC project with some modules using Qt and some not being able to use Qt. Well, you can call that an "ecosystem", and you're correct it's the ecosystem that matters. On a daily basis I'm confronted with the "bigger picture" question: shall we keep the Qt application framework as part of our ecosystem?

Over time we have found more an more areas where Qt actually sucks, including licensing and support. This made us look around for alternatives. It's almost always better to use the STL. While I don't deny that Qt provides its users "a lot of stuff", the "cohesive way" is provided by other libraries as well. No distinct advantage of Qt. The only "advantage" is that you get "everything out of a single hand". But that depends heavily on the platform. (library dependency handling is different windows than on Linux. On some platforms you do not care...)

A serious software engineer always keeps an eye on alternatives. We have recently managed to get away from qmake. Our next step is to get away from Qt Creator. Don't get me wrong, Qt is probably really the best user interface toolkit. But the trolls just tried to dance on too many weddings simultaneously. To get rid of the rest of the Qt libraries is already a discussion point on our table. Whether we are able to pull that off is another question.

I'd say that these are different pictures and different ecosystems.
Qt must be considered as a whole, but each project (even big ones) is a "pocket universe".

Of course I'm always looking around for better alternatives, but I still haven't found one.

I'm not saying you're wrong, but your argument is not about Qt, but about frameworks.
Whenever there are lots of parts moving together (and this is especially true for big projects like yours) frameworks become harder to use.
I'd say that the more the moving parts, the more the constraints imposed by each framework you're using.

With that in mind, IMHO, Qt is still pretty awesome because while being a big application framework, it's very modular and you in most cases you can shred the things you don't need and replace them with whatever works best for your project

[wertigon]

As a low-end programmer with just enough knowledge about GUI programming to become dangerous; I can understand why Qt once, historically, did things a certain way. I can understand the argument that it did not start with, say, std::string since the type sucked in the early days.

What I cannot understand, is why the heck Qt 6, released in 2021, must insist on spending resources and burning goodwill with their own incompatible qt::QString instead of deprecating it completely and simply do:

typedef qt::QString std::wstring;

In my humble opinion, qt should strive towards the std:: libs as they improve and rely less on their own, incompatible stuff where possible. The advantages of rolling their own is decreasing more and more every year, while the disadvantages pile up. How long before the pain is bigger than the benefits?

[doom_Oo7]

In my humble opinion, qt should strive towards the std:: libs as they improve and rely less on their own, incompatible stuff where possible. The advantages of rolling their own is decreasing more and more every year, while the disadvantages pile up. How long before the pain is bigger than the benefits?

It would be absolutely terrible.
Like, with QString I can just do stuff like

if(string.startsWith("foobar"))
string.trimmed();
string.matches(QRegularExpression("[Ss]ome regexp?");
string.splitRef(",");

etc etc... all of those are a pain to write with std::wstring ; also with QString I can just do QString::{from,to}Utf8() and things JustWork, just like writing to the console JustWorks. Try writing unicode characters to the console in a cross-platform win / mac / linux with just std::.