Always use a Pin<Rc> for the component. (This is required to support repeater
within repeater as well anyway)
Do not use the context within the binding. We can get along by simply capturing
a weak pointer to the component
When the path was constructed from events (SVG commands), then we don't really need to build an intermediate path,
neither for rendering nor for path layouting.
Use two arrays, one for events and one for coordinates. That simplifies
the code generator and the generated code, and it also provides for
a more compact memory representation.
Using the commands property we can just paste SVG paths. This makes it
much easier to write examples/demos. A good online path designer is
for example https://codepen.io/anthonydugois/pen/mewdyZ
They are represented as lyon-style path events. We can use this to
compile SVG paths ahead of time and use them
without including lyon's SVG path builder.
Remove Property::set_binding_object and instead have an associated
helper method on PropertyImpl, as in C++ only we have the inner impl.
Also removed set_notifier_callback() from the Binding trait, as it's not
needed there anymore - we can set up the callback right away at property
animation construction time, so that it also works without a Property<T>
but just an inner.
Rename properties::PropertyAnimation to PropertyAnimationBinding -- it's
mostly an internal type anyway. This way
abi::primitives::PropertyAnimation remains the only type with that name
and exposing it to C++ is straight-forward.
The trait functions that allowing a binding (animation) to intercept a
new value or binding is not needed anymore since the generated code is
supposed to cover all call sites and pass the appropriate animation at
that point.
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.
