Certainly elements are only allowed as children of certain others, such
as Row only within GridLayout, for example. This patch implements this
constraint at type lookup type and allows removing "Row" from the
general list of types that can be instantiated anywhere.
This mechanism will also be used for path elements, in the future.
* Make sure to move the animation declarations when moving property
declarations to the root
* In the interpreter, we need to do a little extra dance to get the RTTI
right for custom properties and also apply the animations.
Setting values on animated properties now results in set_animated_value
being called on the property instead of set, and the animation data is
passed on the spot.
So
animate x { ... }
is basically a short-hand for
PropertyAnimation {
...
}
<magically associated that animation with x whenever x is changed>
We could also support a shared animation syntax in the future:
blah := PropertyAnimation { ... }
animate x with blah;
animate y with blah;
This patch also adds a primitive PropertyAnimation struct, which will be
used by the generated code to collect the values specified in the .60
markup.
While properties declared in the root component are named as-is and
exposed as Property<T>, their get() function in particular is hard to
use because it requires an EvaluationContext as a parameter.
This patch adds get_foo() and set_foo() accessors for each public
property and hides the evaluation context business for the getter.
The added test uses this right away and adds missing test coverage for
the conditional expression.
The following scenario would fail compiling to C++ because we failed to
determine the return type of the conditional expression:
Test := Rectangle {
property<bool> condition;
property<color> extra_color;
color: condition ? root.extra_color : 4289374890;
}
The type of the true branch would be color and the false branch would be
a float. Since they "disagree", ty() on the expression would return
Type::Invalid. This was temporarily worked around in the C++ generator
by always returning the type of the true branch, but that's wrong.
Instead this patch changes maybe_convert_to to apply the Cast expression
to the individual branches, placing the cast only to the numberic
literal and correcting the return value of ty() on the conditional
expression.
This is relatively straight-forward via a pass in the compiler to
collect the resources to embed and then use include_bytes! (once per
resource).
What's really annoying is that the rust resource enum can't store a
&'static [u8] because cbindgen doesn't represent that, probably because
the slice representation isn't guaranteed to stay as it is. So instead
this, for now, uses raw pointers.
The Image's source property used to be a string. Now it is a Resource
enum, which can either be None or an absolute file path to the image on
disk. This also replaces the internal Image type.
The compiler internally resolves the img bang expression to a resource
reference, which shall remain just an absolute path. For now the target
generator passes that through, but in the future the target generator
may choose a target specific way of embedding the data and thus
generating a different Resource type in the final code (through
compile_expression in the cpp and rust generator).
The C++ binding is a bit messy as cbindgen doesn't really support
exporting enums that can be constructed on the C++ side. So instead we
use cbindgen to merely export the type internally and only use the tag
from it then. The public API is then a custom Resource type that is
meant to be binary compatible.
