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.
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.
Removed the drop and create from the ComponentVTable:
since we are not using VBox<ComponentVTable>, this simplifies a bit
the code of the interpreter and everything else.
But there is still a lot of changes everywhere to support that the Component
is pinned.
This is just for the component. Which would be required if later we want
to access the properties as Pin<Property<_>>. But we have not yet ability
to do projections
For the generated
std::make_shared<sixtyfps::ArrayModel<3,float>>(1, 3, 2);
gcc would complain
non-constant-expression cannot be narrowed from type 'int' to 'float' in initializer list [-Wc++11-narrowing]
So this patch casts the individual elements to the target (float) type.
* Renamed PropertyNotify::notify to register_current_binding_as_dependency
as the implementor doesn't actively notify anybody, it merely results
in registering the currently evaluating binding as a dependency.
Also fixed the docs that I added a short while ago -- I got it the
wrong way around :)
* Renamed CURRENT_PROPERTY to CURRENT_BINDING to reflect that this is
about the currently evaluating binding (that'll become a dependency to
notify)
My fix for creating textures from html canvas elements was merged into
upstream. Until a new version is on crates.io, let's use a pinned sha1
from upstream instead of my fork.
This comes with a factory function that re-directs to the backend and a
run member function to replace
sixtyfps_runtime_run_component_with_gl_renderer. For now it's all still
hidden in the generated run() method.
