Qt's Development Branch To Begin Forming Qt 6

[Vistaus]

What about forking both Bink and WebKit to resurrect KHTML and Konqueror? Neither Google nor Apple deserve that power in World Wide Web.

Anyway, I have hopes in Servo after it's fully written in Rust. I hope both projects finally become worthwhile.

Konqueror is still being developed, but it's nowhere near as good as it once was and KHTML isn't going to solve its problems. HOWEVER, Falkon + KHTML would be terrific!

[timofonic]

Back to good ol' KHTML then?

What about forking both Bink and WebKit to resurrect KHTML and Konqueror? Neither Google nor Apple deserve that power in World Wide Web.

Anyway, I have hopes in Servo after it's fully written in Rust. I hope both projects finally become worthwhile.

[Vistaus]

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.

Back to good ol' KHTML then?

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

[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

"

[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

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

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

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

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