On: SwiftUI

[jcelerier]

The syntax example is still not as clean as QML, which is already a ten-year-old language (examples: http://qmlbook.github.io/ch04-qmlstart/qmlstart.html).

[aseipp → jcelerier]

Depends on what you mean by "clean". I'd say it's pretty good from what I can see? The examples are also incomparable; the one you link to is nearly 20 lines of code to define nothing more than an embedded triangle image and single text embed with a few colors, while the Swift example hosts an entire modal list with embedded picture components and text (while handling fluid scrolling, right-to-left langs, dark mode theming, etc all implicitly) -- all in the same number of lines or so (and had further mods made during the Keynote by a developer with similar brevity.) Judging from lines only or "cleanliness" I'd say SwiftUI is doing pretty good here, but ultimately the examples are too apples and oranges to draw any real conclusions from.

Syntax aside, there is a large semantic difference between the two: QML is a separate language/modeling tool that is embedded into the application runtime. SwiftUI is in fact ordinary Swift code and the UI you define with it is also ordinary Swift code too, code that XCode and the Swift compiler understand and analyze and refactor and compile like any other. Just with some special magic to make the UI builder work with it. I think this has a lot of advantages notably from a toolchain perspective, since you don't even need XCode (just the Swift compiler) to do things like xrefs/refactorings across SwiftUI code, nor maintain tooling like that across two languages (XYZ + whatever UI modeling language)

Given that, my first impressions of how far they took it (and how well it came out) are pretty good.

[stabbles → aseipp]

> while the Swift example hosts an entire modal list with embedded picture components and text (while handling fluid scrolling, right-to-left langs, dark mode theming, etc all implicitly)

I think you might check out more of QML / QtQuick 2 before drawing any conclusions.

    import QtQuick 2.12
    import QtQuick.Layouts 1.12

    ListView {
        model: Model.items
        delegate: RowLayout { 
            Image { source: image }
            Column {
                Text { text: title }
                Text {
                    text: subtitle
                    color: "gray"
                }
            }
        }
    }

This should be more or less the same. Fluid scrolling is backed by the underlying Flickable [1]. RTL support is available an can be changed in runtime [2]. Themes / colors can be changed in runtime as well [3].

Lastly, it runs on Windows, Linux and Android as well as OSX and iOS.

[1] https://doc.qt.io/qt-5/qml-qtquick-flickable.html

[2] https://doc.qt.io/qt-5/qtquick-positioning-righttoleft.html

[3] https://doc.qt.io/qt-5/qtquickcontrols2-styles.html

[_fbpt → jcelerier]

I think QML is used for Qt Quick and not compatible with desktop-style Qt Widgets. Qt Widgets .ui files are human-unreadable, and when edited in Qt Designer, usually lead to incorrect tab order (see LMMS's settings screen).

All of these seem somewhat conceptually similar to Audacity ShuttleGUI (https://wiki.audacityteam.org/wiki/ShuttleGui)

Or the Python context-manager-based declarative GUI (wrapping PyQt) I wrote for my relatively small program corrscope (https://github.com/corrscope/corrscope/blob/master/corrscope...)

[jcelerier → _fbpt]

> I think QML is used for Qt Quick and not compatible with desktop-style Qt Widgets.

yes, but it does not prevent you to make desktop apps with it. See e.g. Kirigami UI which is based on QtQuick : https://kde.org/products/kirigami/

(and for "large" desktop apps made with QtQuick, look at the Blizzard launcher, or Substance Designer which is as much a desktop app as one can aspire to be : https://cdn.studiodaily.com/wp-content/uploads/2019/05/subst... )

QML has a fundamental difference with the links you showed : it is able to create bindings according to variables used in expressions / functions / etc.

e.g. if you do

    MyWidget { 
         width: { if(y > 50) 
                    return f(height) + x;  
                  else 
                    return otherItem.height / height;
         }
    }

then whenever any of the properties used in the expression changes, the width is recomputed.

[untog → jcelerier]

But it is Swift, which (at the risk of stating the obvious) QML is not. And you can't write an entire app in QML.

There's something to be said for being able to use one language for all things.

[stabbles → untog]

Well, you can almost surely write entire apps in QML if you take the C++ entrypoint for granted.

Just a couple examples: you can do Bluetooth discovery scans in QML without writing any C++ [1], you can read from ~20 sensors without writing any C++ [2], you can write complete 3D scenes declaratively in QML [3], and the list goes on.

[1] https://doc.qt.io/qt-5/qml-qtbluetooth-bluetoothdiscoverymod...

[2] https://doc.qt.io/qt-5/qtsensors-qmlmodule.html

[3] https://doc.qt.io/qt-5/qt3d-wireframe-example.html

[jcelerier → untog]

> But it is Swift, which (at the risk of stating the obvious) QML is not.

sure, and I agree that Swift has some better features and a better foundantion than JS on which QML is based upon

> And you can't write an entire app in QML.

This however is not true. I've worked on multiple pure QML apps so far (well, if you don't count the auto-generated main.cpp). Remember that you have access to a complete ES7 JS engine which allows for a lot of stuff.

[stabbles → jcelerier]

I don't understand why this gets downvoted. It's an entirely valid point and probably SwiftUI took inspiration from it.

[mmargerum → jcelerier]

Rectangle calculations. how quaint.