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
No need to chack that the signal exist since `emit_signal` will
actually return an error in that case already, and this is not
possible to call emit_signal on a invalid signal from the public
API
The test is unrelated
Typically their emission requires an evaluation context parameter.
Similar to properties, provide a public emitter function that takes care
of the context.
This also required two fixes in the compiler, in order to make the
following (as part of the test case) work:
signal foo;
foo => { ... }
(1) Register declared signals before attempting to implement the
connection handlers.
(2) When looking up the signal property, not only look in the base
type but also in the current type.
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.
By setting RUSTFLAGS in the Cargo config we run into the situation that
when doing a host build, all rust files are compiled with the flags,
including build.rs. When cross-compiling, build.rs is not build with the
RUSTFLAGS specified. That makes kind of sense, but it also means that
all the build scripts are always recompiled when switching between a
target and a host build - and that applies to *all* packages, including
dependencies.
So short of a better solution, this patch removes the need to set
RUSTFLAGS. It was used to extract the system library dependencies for
the static library we'd create. Instead we're now building two shared
libraries and are linking against them. They contain the rust library
twice, so that's not really a desirable final state either, but
productivity wins right now :-)
It might make sense to go back to creating *one* shared library through
a dedicated crate and -- since 'pub extern "C"' functions are not
transitively exported, it may require re-exporting them by hand or using
some clever build trick perhaps.
This is not working because spawning cargo for each tests is too slow,
and cannot even re-use the same target directory because it would block
on the cargo lock file. and rebuild all the dependences because of
different flags
