Qt's Development Branch To Begin Forming Qt 6

[phoronix]

Phoronix: Qt's Development Branch To Begin Forming Qt 6

Following the feature freeze and code branching for Qt 5.14, the Qt "Dev" branch will likely be shifting immediately to Qt 6 development. A Qt 5.15 release is still expected to happen before Qt 6.0, but that 5.15 milestone will likely just be a polished release derived from Qt 5.14...

http://www.phoronix.com/scan.php?page=news_item&px=Qt-6-Development-Beginning

[alpha_one_x86]

Maybe C++ standard container type... to have greater performance.

[s_j_newbury]

I wish they'd drop QtWebEngine and pick back up QtWebKit since it's being maintained again. QtWebEngine was a terrible mistake on the part of Qt, being dependent on Google and presumably having to verify every Chromium sub-project for security/licensing since it duplicates pretty much all the functionality QtWebKit provided through system libraries (~3x the installed size). Not to mention that QtWebEngine is still stuck on Chromium-69 as it's impossible to maintain a stable API while keeping up with Chromium releases.

[timofonic]

I wish they'd drop QtWebEngine and pick back up QtWebKit since it's being maintained again. QtWebEngine was a terrible mistake on the part of Qt, being dependent on Google and presumably having to verify every Chromium sub-project for security/licensing since it duplicates pretty much all the functionality QtWebKit provided through system libraries (~3x the installed size). Not to mention that QtWebEngine is still stuck on Chromium-69 as it's impossible to maintain a stable API while keeping up with Chromium releases.

I partially agree. Do we need to depend on Apple Inc. bullshit instead Google crap? I see things depending on corporations like those are a big mistake to the World Wide Web and friends.

[Luke_Wolf]

Maybe C++ standard container type... to have greater performance.

[Citation Needed]
On a cursory Google search I did not see any benchmarks for this, and where there were comments about performance it was that Qt was faster because they use COW whereas STL is not guaranteed to. With the advances of C++11 (and C++14/17) and being able to standardize on these later versions with Qt6 you can make the argument that the STL containers have become easy enough to use to be able to replace the Qt versions, but in general the Qt versions of STL classes have been much more convenient in the API they provide unless you want to add Boost into your project.

[Luke_Wolf]

I wish they'd drop QtWebEngine and pick back up QtWebKit since it's being maintained again. QtWebEngine was a terrible mistake on the part of Qt, being dependent on Google and presumably having to verify every Chromium sub-project for security/licensing since it duplicates pretty much all the functionality QtWebKit provided through system libraries (~3x the installed size). Not to mention that QtWebEngine is still stuck on Chromium-69 as it's impossible to maintain a stable API while keeping up with Chromium releases.

tbh I would like to just have QtWebEngine removed wholesale and maintained as a separate library with it's own release cadence with neither it or QtWebKit being allowed in the main Qt Package, because Qt's release cadence is too slow vs that of browser engines.

[carewolf]

[Citation Needed]
On a cursory Google search I did not see any benchmarks for this, and where there were comments about performance it was that Qt was faster because they use COW whereas STL is not guaranteed to. With the advances of C++11 (and C++14/17) and being able to standardize on these later versions with Qt6 you can make the argument that the STL containers have become easy enough to use to be able to replace the Qt versions, but in general the Qt versions of STL classes have been much more convenient in the API they provide unless you want to add Boost into your project.

The STL can be faster especially for smaller data-structures (it can be cheaper to copy a few cachelines around instead of dealing with pointer indirection and reference counting), but it all depends on your exact use case, and you can get around the STLs copying with references and move semantics (but never both at once!!). In any case both STL and Qt are reasonably fast baselines with different trade-off, but like always if you want high performance in C++ you write your own data-structures. That is the power of the language, you can create data-structures optimized for your problems (just don't write your own generic containers, that way lie madness). If performance isn't your number one priority, well then use the good baseline performance from whatever library you are already using.

[alpha_one_x86]

[Citation Needed]
On a cursory Google search I did not see any benchmarks for this, and where there were comments about performance it was that Qt was faster because they use COW whereas STL is not guaranteed to. With the advances of C++11 (and C++14/17) and being able to standardize on these later versions with Qt6 you can make the argument that the STL containers have become easy enough to use to be able to replace the Qt versions, but in general the Qt versions of STL classes have been much more convenient in the API they provide unless you want to add Boost into your project.

I have do it https://catchchallenger.first-world....ception#String

[Gunnar67]

Not to mention that QtWebEngine is still stuck on Chromium-69 as it's impossible to maintain a stable API while keeping up with Chromium releases.

From New Features Page of the latest Release Qt 5.13
"Qt WebEngine

• Based on Chromium 73

"

[Luke_Wolf]

I have do it https://catchchallenger.first-world....ception#String

¯\_(ツ)_/¯
Not only does that benchmark not compare QString to std::string, as opposed to the various ways to initialize QString, including with a char *, but string handling is still crap with std::string as opposed to QString. I can see and get behind swapping out QVector with std::vector and such especially with the advances in <algorithm> but... I definitely prefer working with QString.