KDE Now Maintaining Their Own Set of Patches For Qt 5

[MadCatX]

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

What do you consider standardized and how is it relevant for the discussion?

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.

Neither std::string, std:wstring nor QString store code points. std::string stores an array of bytes. std::wstring stores an array of wchar_ts, wchar_t is an implementation-defined integral type that may be as small as 8 bits (yes, really). QString stores an array of UTF-16 code units. std::string and std::wstring make no assumptions about the data they store. Since QString assumes its content to be a UTF-16 code unit sequence, it can implement Unicode-aware text handling consistently across multiple platforms. You still need to exercise caution when dealing with surrogate pairs in QString. However, AFAIK there is no string manipulation library that is considerably better in this regard.

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

When people talk about a local socket, I imagine that most people think of AF_UNIX kind of socket. Most APIs and SDKs use the name local socket to describe this device.

[ssokolow]

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

Maybe I just haven't used my KDE applications in folders with enough files, but I haven't noticed that myself. If it's true, it needs to be fixed.

Funny enough, years ago (5? I can't remember), I loathed the GTK picker because it far outstripped the KDE pickers I was using it alongside in exactly that problem. (Useless until all the files have loaded in a big directory.)

In fact, I think my solution at the time was using that LD_PRELOAD-based hack to get KDE file dialogs in GTK applications because, otherwise, they were practically useless.

[wertigon]

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

Well... Not to pop your bubble, but with std::string and pals you can just do:

#include <regex>
#include <string>

if std::regex_match(string, std::regex("^foobar"))
string = std::regex_replace(string, std::regex("^[ \t]+"), "")
string = std::regex_replace(string, std::regex("[ \t]+$"), "")
std::regex_match(string, std::regex("[Ss]ome regexp?"))
string | view::split(',') | ranges::to<std::vector<std::wstring>>();

Which all does precisely what you want them to, with little to no extra code. As the C++ STL evolves, the need to keep a separate library is drastically reduced. Of course, the examples you cite all have easy boost counter parts as well, but if you do not wish to use that library you are free not to use it.

Not to mention a future C++ developer would be more likely familiar with the standard code than QT code.

[Vistaus]

I thought I said it was nominally within kde. It wants extra-cmake-modules from kde. That is the only kde package I install in my normal builds.

In that case you might want to contact your distro maintainers as I don't need extra-cmake-modules for Falkon on my distro, nor on Haiku.

[MadCatX]

Well... Not to pop your bubble, but with std::string and pals you can just do:

#include <regex>
#include <string>

if std::regex_match(string, std::regex("^foobar"))
string = std::regex_replace(string, std::regex("^[ \t]+"), "")
string = std::regex_replace(string, std::regex("[ \t]+$"), "")
std::regex_match(string, std::regex("[Ss]ome regexp?"))
string | view::split(',') | ranges::to<std::vector<std::wstring>>();

Well, this code is:

- Difficult to read
- Error prone
- Probably slow (depends on your STL implementation)
- Less flexible (What if you want to match against a string passed in runtime instead of "foobar" for instance?)
- Problematic with Unicode
- Strictly speaking wrong (your trimming "functions" are not sufficient)
- A complete departure from a well established and perfectly functional QString API

You can write your own string manipulation library with plain STL but if you are using Qt, why would you do that when Qt already provides one?

[zerothruster]

In that case you might want to contact your distro maintainers as I don't need extra-cmake-modules for Falkon on my distro, nor on Haiku.

From falkon-3.1.0/CMakeLists.txt

# Project name and version
project(Falkon VERSION 3.1.0)

# Find ECM, with nice error handling in case of failure
include(FeatureSummary)
find_package(ECM 5.27.0 CONFIG)
set_package_properties(ECM PROPERTIES TYPE REQUIRED DESCRIPTION "Extra CMake Modules." URL "https://projects.kde.org/projects/frameworks/extra-cmake-modules")
feature_summary(WHAT REQUIRED_PACKAGES_NOT_FOUND FATAL_ON_MISSING_REQUIRED_PACKAGES)
set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${ECM_KDE_MODULE_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/cmake)

# Many includes from ECM, to get all the nice cmake functions and settings
include(KDEInstallDirs)
include(KDECMakeSettings)
include(KDECompilerSettings NO_POLICY_SCOPE)
include(ECMInstallIcons)
include(ECMSetupVersion)
include(ECMAddAppIcon)
include(ECMQtDeclareLoggingCategory)
include(ECMPoQmTools)

[wertigon]

Well, this code is:

- Difficult to read
- Error prone
- Probably slow (depends on your STL implementation)
- Less flexible (What if you want to match against a string passed in runtime instead of "foobar" for instance?)
- Problematic with Unicode
- Strictly speaking wrong (your trimming "functions" are not sufficient)
- A complete departure from a well established and perfectly functional QString API

You can write your own string manipulation library with plain STL but if you are using Qt, why would you do that when Qt already provides one?

So your criticism is basically "Well, this is not what I'm used to, so..." naturally this code is not the easiest to read for an untrained eye, and sure you can find places where one approach or the other is preferable. Is it "Add-15-MB-of-extra-dependencies" preferable though? What about 300 MB?

At this rate I see Qt eventually becoming another jQuery. You know that JavaScript augmented library that allowed you to do cool stuff with even old IE6 back in the day. Then it got obsolete as ECMAScript evolved, and these days people mostly just drop it over standard JS and CSS. I would suggest very careful trimming of the Qt fluff going forward, start deprecating things that are now part of the standard C++17 like regexps, et cetera.

[MadCatX]

So your criticism is basically "Well, this is not what I'm used to, so..." naturally this code is not the easiest to read for an untrained eye, and sure you can find places where one approach or the other is preferable. Is it "Add-15-MB-of-extra-dependencies" preferable though? What about 300 MB?

I'm afraid you're thinking about this all wrong. There are numerous huge software projects that use Qt - a lot of them commercial. Imagine the sheer amount of work that'd have to go into moving away from QString to std::string API. How would you explain to your customers that they have to rewrite all of their container code if they want to upgrade to Qt6? Why would anybody do that?

Qt containers are fine. They have a STL-like and Java-like convenient APIs. They do copy-on-write (STL doesn't). They use signed integers for indices (I think it was Scott Meyers who said that using unsigned ints for indexing is one of STL's biggest mistakes). They are guaranteed to work exactly the same on all platforms. They are used consistently across the entire Qt. What exactly do you gain by switching over?

At this rate I see Qt eventually becoming another jQuery. You know that JavaScript augmented library that allowed you to do cool stuff with even old IE6 back in the day. Then it got obsolete as ECMAScript evolved, and these days people mostly just drop it over standard JS and CSS. I would suggest very careful trimming of the Qt fluff going forward, start deprecating things that are now part of the standard C++17 like regexps, et cetera.

Qt does adopt things from STL. Qt5 relies on STL. QString has fromStdString() and toStdString() methods since Qt5. You can use std::thread with Qt slots for example. At one point they did consider adopting some STL containers but eventually decided against it.

[Vistaus]

From falkon-3.1.0/CMakeLists.txt

# Project name and version
project(Falkon VERSION 3.1.0)

# Find ECM, with nice error handling in case of failure
include(FeatureSummary)
find_package(ECM 5.27.0 CONFIG)
set_package_properties(ECM PROPERTIES TYPE REQUIRED DESCRIPTION "Extra CMake Modules." URL "https://projects.kde.org/projects/frameworks/extra-cmake-modules")
feature_summary(WHAT REQUIRED_PACKAGES_NOT_FOUND FATAL_ON_MISSING_REQUIRED_PACKAGES)
set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${ECM_KDE_MODULE_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/cmake)

# Many includes from ECM, to get all the nice cmake functions and settings
include(KDEInstallDirs)
include(KDECMakeSettings)
include(KDECompilerSettings NO_POLICY_SCOPE)
include(ECMInstallIcons)
include(ECMSetupVersion)
include(ECMAddAppIcon)
include(ECMQtDeclareLoggingCategory)
include(ECMPoQmTools)

However, it compiles just fine without ECM on at least Deepin and Haiku, so I repeat: ECM is *not* needed.

[JackLilhammers]

So your criticism is basically "Well, this is not what I'm used to, so..." naturally this code is not the easiest to read for an untrained eye, and sure you can find places where one approach or the other is preferable. Is it "Add-15-MB-of-extra-dependencies" preferable though? What about 300 MB?

Well, your few lines of code are hard to read even for the somewhat trained eye.
I'd trade a few tens of mbs of precompiled dependencies and some performance for more readable code. (within reason, of course)
Because things will be easier for me and my users will never notice the difference

At this rate I see Qt eventually becoming another jQuery. You know that JavaScript augmented library that allowed you to do cool stuff with even old IE6 back in the day. Then it got obsolete as ECMAScript evolved, and these days people mostly just drop it over standard JS and CSS. I would suggest very careful trimming of the Qt fluff going forward, start deprecating things that are now part of the standard C++17 like regexps, et cetera.

I think that Qt devs would be happy to wrap Qt classes around standard libraries if it makes sense.
By the way, do you have any idea of just how many sites still rely on jQuery?
A little context: https://trends.builtwith.com/javascript/jQuery