Announcement

Collapse
No announcement yet.

Qt's Development Branch To Begin Forming Qt 6

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Qt's Development Branch To Begin Forming Qt 6

    Qt's Development Branch To Begin Forming Qt 6

    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?pag...ment-Beginning

  • Vistaus
    replied
    Originally posted by timofonic View Post

    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!

    Leave a comment:


  • timofonic
    replied
    Originally posted by Vistaus View Post

    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.

    Leave a comment:


  • Vistaus
    replied
    Originally posted by timofonic View Post

    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?

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by alpha_one_x86 View Post
    ¯\_(ツ)_/¯
    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.

    Leave a comment:


  • Gunnar67
    replied
    Originally posted by s_j_newbury View Post
    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
    "

    Leave a comment:


  • alpha_one_x86
    replied
    Originally posted by Luke_Wolf View Post

    [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

    Leave a comment:


  • carewolf
    replied
    Originally posted by Luke_Wolf View Post

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

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by s_j_newbury View Post
    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.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by alpha_one_x86 View Post
    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.

    Leave a comment:

Working...
X