It should be possible to load multiple times into the same registry,
which will require interior mutability: While a loaded type has a
reference to the registry, a newly loaded type shall be added.
Don't need an accessor function in the Document for a public field. That said,
the choice of registry instance for the path "compilation" doesn't really matter,
as the lookup shall always end up
in the global registry.
For a .60 files the locally defined components are now stored in a separate
per-document TypeRegistry instance that falls back to the global registry
for lookups.
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.
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.
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.
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.
