This patch replaces the 'install()' approach for property animations
with explicit set_animated_value() and set_animated_binding() functions
in Property -- to be called from generated code.
This requires a little dance-around for the time being that
PropertyAnimation is designed to act automatically on value transitions,
but that can be removed later without changing the interface.
Also the animation details are copied right away. This is sub-optimal,
we should somehow keep a reference to the properties or get notified
when they change, for example perhaps through a simple property binding.
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.
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.
Remove the Optional from the evaluation context passing for property
evaluation. Unfortunately there are nullptr uses left on the C++ side,
that need to be replaced with passing through.
Forward the text and color properties to the rendering backend, where
right now we just rendering all the glyphs into a dedicated texture.
Next steps are a glyph atlas texture, blending the specified color with
the alpha of the glyphs, configurable size and family, shaping with
Harfbuzz and may more things.
The name node suggests some kind of connected (tree) data structure, which
isn't quite what it is. It really is meant just
to be a way of storing cached rendering data for this item.
