Announcement

Collapse
No announcement yet.

Lars Knoll Shares His Technical Vision For The Qt 6 Tool-Kit

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

  • Lars Knoll Shares His Technical Vision For The Qt 6 Tool-Kit

    Phoronix: Lars Knoll Shares His Technical Vision For The Qt 6 Tool-Kit

    Longtime KDE/Qt developer Lars Knoll (and current CTO of The Qt Company) has shared his technical vision for the upcoming Qt 6 tool-kit...

    http://www.phoronix.com/scan.php?pag...chnical-Vision

  • #2
    Official Rust support would be great

    Comment


    • #3
      Why bother with DX12 support when Windows supports Vulkan?

      I await similar Phoronix posts like this: Hey Nate, Plasma using QT6 with the DX12/DXVK backend broke the vsync on KWin again.

      Comment


      • #4
        They should remove the CLA.

        Comment


        • #5
          Originally posted by skeevy420 View Post
          Why bother with DX12 support when Windows supports Vulkan?

          I await similar Phoronix posts like this: Hey Nate, Plasma using QT6 with the DX12/DXVK backend broke the vsync on KWin again.
          I also thought MoltenVK was about making Vulkan the perfect target for serving macOS instead of implementing Metal directly.

          Comment


          • #6
            I am not sure how Qt company can afford maintaining such a large framework and design tools, I guess that means they must be doing pretty good. I hope Qt keeps trucking on, it's the only sane C++ framework.

            Also, preach it! CMake is king.
            QMake as the build system used in Qt 5 has lots of quirks and limitations. For Qt 6, we aim to use CMake as a standard 3rd party build system to build Qt itself. CMake is by far the most widely used build system in the C++ world, and better integration with it is sorely needed. We will continue to support our users on QMake, but not develop it further or use it to build the Qt framework itself.

            Comment


            • #7
              A new "Rendering Hardware Interface" is being worked on for Qt in order to abstract those graphics APIs.
              No, there is already a cross-platform abstraction and it's called Vulkan. I don't want to learn a new abstraction API with its own quirks and limitations each time I upgrade or use a different toolkit.

              Comment


              • #8
                Originally posted by cen1 View Post
                it's the only sane C++ framework.
                Unfortunately Qt isn't standard C++. It is C++/MOC. This makes it hard to maintain; from my experience, compiling an ancient wxWidgets project is still possible whereas compiling an ancient Qt 2.x project is very hard.

                (If you are going to use non-standard C++, then C++/CLR is actually pretty decent for Winforms programming.)

                So C++ basically has no sane GUI frameworks.

                Originally posted by cen1 View Post
                Also, preach it! CMake is king.
                We tend to use this but the non-standard MOC preprocessing step makes it quite awkward.

                So its pretty obvious from my post but I would really like to see work done to replace MOC with standard C++. (Even using the latest standard if absolutely necessary). Something like this: https://github.com/woboq/verdigris

                Comment


                • #9
                  Originally posted by kpedersen View Post

                  Unfortunately Qt isn't standard C++. It is C++/MOC. This makes it hard to maintain; from my experience, compiling an ancient wxWidgets project is still possible whereas compiling an ancient Qt 2.x project is very hard.

                  (If you are going to use non-standard C++, then C++/CLR is actually pretty decent for Winforms programming.)

                  So C++ basically has no sane GUI frameworks.


                  We tend to use this but the non-standard MOC preprocessing step makes it quite awkward.

                  So its pretty obvious from my post but I would really like to see work done to replace MOC with standard C++. (Even using the latest standard if absolutely necessary). Something like this: https://github.com/woboq/verdigris
                  Qt had to innovate in the past when C++ was still just C with classes. For example, signals and slots is such a simple and useful mechanism I couldn't care less how it's handled behind the scenes. There is also some duplication with qt containers and stl but I believe there are plans to slowly phase the custom stuff out in favor of pure C++ or at least make it more interop. For me it is a sane c++ framework, "sane" meaning getting shit done!

                  Comment


                  • #10
                    • Qt on the web with HTML5? Canvas? WebGL? WebAssembly?
                    • Qt on Android, iOs and mobile devices such as phones and tablets?
                    • Qt in VR and AR applications?
                    • Qt integration in game engines?
                    • Qt on .NET Core?
                    • Qt bindings for Rust?

                    Comment

                    Working...
                    X