[Development] QML 3 and JavaScript

Simon Hausmann Simon.Hausmann at qt.io
Wed Nov 13 16:42:02 CET 2019

Am 11.11.19 um 18:13 schrieb Jason H:
> If not Javascript, then what? Python? This is the first I've heard of 
> this. Just wondering what it is if not javascript?

This is a little tricky to answer just in email text. But what I think I 
can do safely is show you two snippets of code from our examples from 
the MCU side that are compiled to as-fast-as-handwritten C++:

(From a wearable example's .qml file)

     property int activeIndex: 0

     property int activePage: -1

     property int previousActivePage: -1;

     function setActiveIndex(i: int) {
         if (i == activeIndex) {
             previousActivePage = -1;
             activePage = i;
         } else {
             var deltaPos = (activeIndex + 7 - i) % 7;
             var deltaNeg = (i + 7 - activeIndex) % 7;
             if (deltaPos > deltaNeg) {
                 angle = angle - angleDelta * deltaNeg;
             } else {
                 angle = angle + angleDelta * deltaPos;
             activeIndex = i;

and further down below:

         Repeater {
             delegate: RoundButton {
                 onClicked: {

                 enabled: !angleAnimation.running
                 active: index == self.activeIndex
                 angle: self.angle + index * self.angleDelta
                 centerX: launchView.width / 2
                 centerY: launchView.height / 2
                 radius: Math.min(launchView.width, launchView.height) * 0.5
                 title: modelData.title
                 icon: modelData.image

This is the kind of code we want to support in QML 3. As you can see, 
it's ... just QML. It's not large business-logic heavy stuff, but it's 
simple enough to implement UIs.

What's different are type annotations for parameters to functions and 
their return value. Grammatically this is also available in Qt 5.14 for 
invocable functions 
(https://codereview.qt-project.org/c/qt/qtdeclarative/+/267234 ).


> *Sent:* Monday, November 11, 2019 at 3:10 AM
> *From:* "Dmitriy Purgin" <dpurgin at gmail.com>
> *To:* "Qt development mailing list" <development at qt-project.org>
> *Subject:* [Development] QML 3 and JavaScript
> 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 
> that bothers me: the optionality of JavaScript.
> What I didn't quite get is whether JavaScript becomes optional in QML 
> 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?
> As for QML 2, there is a lot of JavaScript code in the existing 
> codebase. Just look at Sailfish OS (actively developed) or Ubuntu 
> Phone, there are tons of logic implemented in QML/JavaScript. I 
> 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.
> Our company has multiple customer projects where JavaScript is 
> 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 [1], sometimes even 
> Animation [2] or Timer [3]. And there are also signal handlers that 
> can execute arbitrary JavaScript code now, and even a simple 
> console.log() is so practical for debugging.
> (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).
> 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.
> Another question is: how will we control the JavaScript engine? Will 
> 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 
> JavaScript engine that we, in fact, don't need, right?
> [1] https://doc.qt.io/qt-5/qml-qtwebsockets-websocket.html
> [2] https://doc.qt.io/qt-5/qml-qtquick-animation.html
> [3] https://doc.qt.io/qt-5/qml-qtqml-timer.html
> Thanks & cheers
> Dmitriy
> _______________________________________________ Development mailing 
> list Development at qt-project.org 
> https://lists.qt-project.org/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

More information about the Development mailing list