Announcement

Collapse
No announcement yet.

Qt 5.9 To Be An LTS Release, Qt 6 Planning On Radar

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

  • Qt 5.9 To Be An LTS Release, Qt 6 Planning On Radar

    Phoronix: Qt 5.9 To Be An LTS Release, Qt 6 Planning On Radar

    Lars Knoll has made some interesting remarks regarding the future of Qt 5 as well as Qt 6...

    http://www.phoronix.com/scan.php?pag...S-Qt6-Planning

  • #2
    Qt 6 Planning On Radar
    I can almost hear KDE users yelling "not again ".

    Comment


    • #3
      Originally posted by hussam View Post
      I can almost hear KDE users yelling "not again ".
      Why? You think anyone expected 5.x to last forever?
      That's just how software is: if you don't clean it up, you end up with unmaintainable code, if you clean it up, you sometimes break stuff.

      Comment


      • #4
        I really hope they will modernize the style with Qt6. There's to many new and deletes when using Qt right now. Also, less useless heap usage == more speed.

        Qt5 right now promote using pointers and new for every widget, and forces you to add all those widget to the parent's list so they can be deleted automatically. This is not only less performant, but also is a bad style. Using automatic storage is easier, clean itself and is faster (at least since move semantics).

        Comment


        • #5
          I really hope they fix some bugs, just few of 1400 that are currently marked as important/critical
          testing qt beta/rc releases is useless, you report bug that crashes application, they mark it as important, and release qt anyway

          Comment


          • #6
            Originally posted by jKicker View Post
            I really hope they fix some bugs, just few of 1400 that are currently marked as important/critical
            testing qt beta/rc releases is useless, you report bug that crashes application, they mark it as important, and release qt anyway
            Totally agree. They are piling up bugs by adding more and more modules. They need to fix the current stuff before jumping to another major.
            When Qt4 reached 4.8 it was pretty solid. Can't say the same for Qt 5.8 (which won't even see patch releases...)

            Comment


            • #7
              Originally posted by gufide View Post
              I really hope they will modernize the style with Qt6. There's to many new and deletes when using Qt right now. Also, less useless heap usage == more speed.

              Qt5 right now promote using pointers and new for every widget, and forces you to add all those widget to the parent's list so they can be deleted automatically. This is not only less performant, but also is a bad style. Using automatic storage is easier, clean itself and is faster (at least since move semantics).
              It depends: new is for GUI necessary, because GUI objects are long living objects. And because they aren't created frequently, you won't feel any performance penalty.

              Comment


              • #8
                Originally posted by Steffo View Post

                It depends: new is for GUI necessary, because GUI objects are long living objects. And because they aren't created frequently, you won't feel any performance penalty.
                I don't understand why newing for widgets should be necessary. I understand, from a C++98 standpoint that indeed it was necessary in order to have a nice syntax, and Qt 5 was started as C++98, but now things have changed a lot. Newer version of Qt already require C++11. An updated syntax could look like this:

                Code:
                std::vector<Qt::Widget> w;
                
                Qt::PushButton b{"text"}; // no parent, will delete itself.
                w.emplace_back(b); // the Qt::Widget would hold a reference to b
                
                b.doWhatever(); // affect the button in the list, effectively a reference
                
                w.emplace_back(Qt::PushButton{"other text"}); // w is owner of the second push button, since the button is an rvalue
                
                Qt::PushButton b2{"test 2"};
                w.emplace_back(std::move(b2)); // same here, b2 moved in the container, the Qt::Widget holds the button directly instead of a reference.
                I've seen a lot of code like this. It's very pleasant to work with such code. It look modern and encourage value semantics when needed, and if done correctly, probably much faster.

                With templates in mind, old pointers to PushButton could also be supported, making the old syntax also compatible.

                The only problem I see is people seeing a too much drastic change will back off to older versions. Ideally, such idiom should be gradually integrated into the framework. Sadly, I highly doubt Qt will ever see such changes.

                Comment


                • #9
                  gufide I have never seen Qt classes not starting with a capital Q but instead everything packed in the Qt namespace. Since when is it like this.
                  And with "no parent, will delete itself", you mean it is default behavior now that the flag Qt::WA_DeleteOnClose is activated? This requires that you actually show the button otherwise it will be there forev0r. What happens in this case since you're not allocating things in the heap? ;-)

                  Comment


                  • #10
                    Qt 5.9 will probably ship with proper font rendering of CFF (.otf) fonts. Yay!

                    Comment

                    Working...
                    X