As previously mentioned, I’ve been working on a YAML-based replacement for QML that would allow using JavaScript alternatives in QtQuick applications.
But, it is not only about a different syntax. It also allowed me to make some improvements to make the life easier.
Less typing
One of the things that I find tedious in QML is the verbosity of some
parts like the anchoring system. For example, when you want to anchor
everything to the parent, it is trivial
(anchors.fill: parent
), but when you want to anchor all but
one side, you need to write quite a bit more:
left: parent.left
top: parent.top
right: parent.right
PUCK will allow you to shorten definitions like these:
PUCK | QML
width,height: Settings.screen_ | width: Settings.screenWidth
| height: Settings.screenHeight
And even:
PUCK | QML
^bottom: parent._ | left: parent.left
| top: parent.top
| right: parent.right
Alternative id definition
Another thing I tried to improve is the id
specification
of QML items. In QML, you would do something like this:
Rectangle {
id: root
// :::
}
The id
looks like an ordinary attribute, but it is not.
It must be unique, you can not override it, etc. I think it should be
more prominent.
In PUCK, the id
definition is moved to the same place
where you specify the type You can use the 'as'
syntax like
in the import statements, or, if you prefer trailing types, you can just
write the id
and the type after it.
Rectangle as root:
// :::
root Rectangle:
// :::
If you don’t like this, and prefer defining the id
inside the object like in QML, nothing will stop you - PUCK supports
that as well. It will just show a warning to suggest changing your
style.
Some experiments
I’ve also experimented with wide arrows, but I’ll probably remove this option in the future.
root <= Rectangle:
// :::
Rectangle => root:
// :::
And also for imports:
imports:
- QtQuick 2.2 as Qt
- Particles <= QtQuick.Particles 2.0
- org.kde.plasma => Plasma
You're completely correct about QML id attributes. They are in no way an attribute of the object instance, despite "appearing" that way in the syntax. If anything, they could be considered a Component (or, really, QML context) attribute (or to be precise, key into a context's object dictionary).
If I had my time again, I'd have pushed for the syntax you suggest, ie "Object as ObjectId { ... }" style declarations. Perhaps this is something to be considered for QML 3.0 (in some distance future).
Your anchor suggestions are nice too, specifically something like: "anchors.!bottom: parent" might be doable via extending the QML syntax even in the 2.x series.
However, personal opinion: I don't like your binding syntax simplification, although I can't quite elucidate why. Maybe the fact that the match is to some extent case-insensitive, and thus a potential source of errors, I don't know. It just seems a bit wrong, to me.
Overall, I really like the idea of allowing different expression syntaxes (i.e., not just JS) into QML. I tried to push for that back in the day (via optional "pragma <language>" specifiers for .qml files) but of course without a Lua/CS/whatever else engine to support it, we took the more pragmatic route of ignoring that possibility for now ;-)