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
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
