Find a replacement for PropertyChanges

The PropertyChanges element is commonly used in State elements in order to change properties of other objects when the state is active. For example

    State {
            name: "a_base"
            PropertyChanges {
                target: bottomRight
                anchors.margins: root.a_padding
            }
    }

This changes the "margins" property of the "anchors" property of an object with the id "bottomRight" when the "a_base" state is activated.

PropertyChanges has a fundamental drawback: It uses a custom parser. PropertyChanges itself does not have an "anchors" property, and from the structure of the program we cannot know that its "target" property denotes the object the change applies to. In order to know that we need to know the inner workings of PropertyChanges.

Therefore, in order to make the above code work in qmltc or qmlcachegenplus we would need to hardcode PropertyChanges into the compiler. This is undesirable because PropertyChanges is part of QtQuick and therefore not automatically available as builtin type. The QML language has to be decoupled from QtQuick as a UI library.

In order to solve this, we might provide a generic "binding" keyword that allows you to create bindings on any property, not just the ones available from the current scope:

    State {
            name: "a_base"
            binding on bottomRight.anchors.margins: root.a_padding
    }

This would produce a binding that lives in the scope of the a_base state, but applies to the anchors.margins property of bottomRight.

In order for this to work, State would need a way to disable and enable such bindings. Furthermore, such syntax would be a convenient replacement for the "Binding" element. The "Binding" element has an explicit "when" property that conditionally enables the binding. Such a "when" clause could be added to our binding keyword, too:

    State {
            name: "a_base"
            binding on bottomRight.anchors.margins: ()=> { return root.a_padding } when ()=> { return enabled }
    }

Such a "when" clause will probably need one or both of the expressions to be explicit functions in order to disambiguate the grammar. However, State might just access those same "when" conditions from C++ and automate this. This way we would only have to write the original syntax:

    State {
            name: "a_base"
            binding on bottomRight.anchors.margins: root.a_padding
    }