1. 20
  1. 4

    In the context of QML

    Introduce strong typing. Weak typing makes it hard for our users to apply large changes to their codebases. A strong type system allows for IDEs and other tools to support our users in this task and dramatically ease the maintenance. Also, we will be able to generate much better-performing code and reduce overhead.


    Make JavaScript an optional feature of QML. Having a full JavaScript engine when using QML can complicate things and is an overhead especially when targeting low-end hardware such as microcontrollers. It is however extremely useful in many use cases.


    1. 3

      This looks pretty great! Moving to CMake seems like the smart move, and I’m super psyched at their continued level of investment in Python.

      Kinda sad about their intent to move away from OpenGL and to Vulcan, Metal and Direct3D though. I guess the idea of one 3D graphics API to rule them all is dead?

      1. 4

        Apple claims that they’re going to remove opengl support from MacOS at some unknown point in the future, Qt is just preparing for that I guess.

        1. 4

          Apple is super annoying these days :) (I mean, I know they always have been, but lately I feel like they’ve turned it to 11, or maybe just in areas I care about!)

          I wonder if Vulcan is a possibility on OSX. Betcha it will be once all the game studios start writing for Google Stadia (Ungh.)

          1. 10

            There is moltenvk, which implements (a subset of) vulkan on top of metal.

            1. 8

              And gfx-portability too.

        2. 2

          My understanding is that OpenGL is a pain to use in general, not just cuz of driver stuff but that the API itself is not something that (notably) game developers enjoy using.

          So there aren’t too many people going to bat for OpenGL

          1. 1

            I thought that Vulcan is supposed to be the new “one 3D graphics API to rule them all”?

            1. 3

              Not without Apple’s buy-in it won’t be.

            2. 1

              Moving to CMake seems like the smart move

              I’m a little disappointed that they’re dumping QBS development on the “community”. My impression is they went straight from “Technology preview” to “We’re not going to continue developing QBS because noone’s using it” without any sort of “QBS is ready now, please try it” announcement.

              1. 1

                Aren’t you supposed to be able to throw away prototypes?

                1. 1

                  Absolutely, but not with the justification that customers weren’t using them.

                  Edit: “details” can be found in this mailing list thread if you’re interested: https://lists.qt-project.org/pipermail/development/2018-October/thread.html#34023

            3. 3

              I hope they follow through on supporting languages besides C++ and Python.

              There were really awesome Common Lisp bindings to Qt4, but they were based on “Smoke”, a tool used by the original Qt Python bindings. Qt5 stopped working with Smoke and the CL bindings (as well as Ruby and a few other languages) stagnated at Qt 4.8.

              1. 1

                I saw there’s a ton of work going into rust bindings. https://github.com/rust-qt

                1. 1

                  I know it’s a implementation-specific solution but EQL5 works pretty well: https://gitlab.com/eql/EQL5/wikis/home