On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote: > The first point I would make in reply, though, is > that the convenience of creating code with a/b/c are going to be > significantly better in my experience.
Code for d) look like this: https://github.com/uwerat/qskinny/blob/master/examples/buttons/buttons.qml IMHO the code for a/b would be very similar, the only one that requires more work would be c as you need extra code for creating the button itself. > Let's take > another good example from the top of my head: Item::anchors. Behind the > scenes, it's implemented as a QQuickAnchors, which is a QObject. Let's > turn it into a Q_GADGET, and we're done, right? No, but please let's stay with gradients, where the answer is yes. QSkinny offers this class to expose gradients to QML: https://github.com/ uwerat/qskinny/blob/master/src/common/QskGradient.h Now when having an control with a property like this: class MyRectangle : public QQuickItem { Q_OBJECT Q_PROPERTY( QskGradient gradient READ gradient WRITE setGradient RESET resetGradient NOTIFY gradientChanged ) ... }; you can write your QML code this way: MyRectangle { gradient { orientation: "Vertical" stops: [ { position: 0.0, color: "MediumAquamarine" }, { position: 0.5, color: "..." }, { position: 1.0, color: "DarkSeaGreen" }, ] } } The equivalent code offered by Qt/Quick needs 4 QObjects - for each instance of an item. So when having 100 rectangles these are 400 QObjects - good for nothing. Uwe _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
