Simon.Hausmann at qt.io
Mon Nov 11 09:53:22 CET 2019
Am 11.11.19 um 09:10 schrieb Dmitriy Purgin:
> Hi all,
> as we learned at the recent Qt World Summit in Berlin, we're getting
> QML 3 with Qt 6. There are some cool features and changes to improve
> the clarity and the performance of the QML part but there is one thing
> 2 already and will be disabled in QML 3, or will it be optional in QML
> 3 only, and QML 2 remains as it is now?
QML 2 will remain as it is now. Although many language related features
are being added to it still, especially related to hygiene.
> codebase. Just look at Sailfish OS (actively developed) or Ubuntu
> understand that UI should be separated from the logic but in the real
> world, you can't completely enforce this that unless it is technically
> impossible. And I'm afraid if it becomes impossible with QML 3, this
> will be considered a step back by many Qt users.
Right, and a step back for our users would not be in our interest. So
when you read "optional", it does not mean that we want to eliminate
(imperative) code from .qml files. Quite in contrary, the ability to
write little pieces of code in binding expressions, signal handlers or
just functions is incredibly powerful and we have no intention of
removing that concept. What we'd like to offer is a subset of the
language that looks the same (modulo type annotations) and works the
same but has a slightly reduced feature set in exchange for the ability
to perform vastly better in terms of runtime-performance and memory
We have tried this and are continuing to develop this technique with the
new Qt for MCUs graphics engine. We as well as some of our early
customers have been writing UI related _code_ in .qml files just the way
they're used to with great success. It's just that "heavier" code, such
as say taking a function closure with captures that keep an outer
variable alive, or making an xml http request within .qml files is not
possible (at the moment).
> actively used to implement parts of the view logic. One of the
> projects is a domain-specific framework where we do the framework part
> in C++, and the customer implements almost all of the logic themselves
> solely in QML.
> I'm sure some parts of the codebase can be rewritten to be
> declarative-only and work exclusively through bindings but there is
> another thing: there are QML components that *require* imperative code
> to work with them: the QML WebSocket type , sometimes even
> Animation  or Timer . And there are also signal handlers that
> console.log() is so practical for debugging.
Yes, and I don't see a problem with those and the code around them. The
objective is to allow writing code that can be compiled to sane
(generated) C++. Even websocket handling might work if we make a good
mapping for array buffers (which we already do in the dynamic setup with
> (btw how do you guys debug complex bindings and state changes? I know
> the QML debugger exists but in most cases it's quicker to add a
> console.log() to the property change and see what's wrong).
QML Debugger and console.log() :-)
> I understand that QML 2 is not going anywhere in Qt 6 but maintaining
> both QML 2 and QML 3 will be a burden for the developers of the Qt
> Framework, and I'm afraid QML 2 won't get much love after QML 3 is
> released. Just as it happened to Widgets, it will be in the "done" state.
One thing we'd like to do differently is to allow good co-existence and
> there be a compile switch to disable or enable it (like QtQuick
> Compiler) or will it be a runtime option to the QML engine? If it's a
> runtime option, there will still be the library size penalty for the
I think most likely it'll be a compile time option, per app/project as
well as for Qt itself.
More information about the Development