Don't just try to resolve relative paths against the current path,
resolve them against all directories in the include search path.
Together with the include search path directive for tests in tests/cases
this will allow working around the fact that the base directory for the
rust tests is different than for the C++/NodeJS tests.
We need to embed resources in wasm builds. Unfortunately we can't detect
that we're called by say wasm-pack and "TARGET"/"HOST" only works inside
build.rs. So instead, to keep things simple, this change always embeds
the image resources when targeting Rust.
The `SIXTYFPS_EMBED_RESOURCES` environment variable can be used to
override this anywhere for any language.
Fixes#130
Ideally we would put the bindings dirrectly in the builtins.60
But this is unfortunately not possible because the "StyleMetrics" is not
yet available there and that would be a circular dependencies.
When referencing an image a repeated element and were targeting a
configuration that requires resource embedding, then that image would
not embedded.
This was due to the fact that we didn't recurse into sub-components in
the resource collection phase and the generators made a per-component
embedding decision. The field responsible for that was also not
propagated to sub-components.
This patch addresses these two bugs by cleaning up the entire mechanism:
The compiler first generates the new ResourceReference::AbsolutePath for
all img!"foo.png" expressions. If the compiler is configured to embed
resources, then the embed_resources pass will traverse all
sub-components and expressions in them to change them to
ResourceReference::EmbeddedData with a unique integer id. Simultaenously
all the resources to be embedded get also collected in the root
component, so that the build script as well as the generator can take
care of dependency handling and actual resource embedding.
Instead of determining the focus item through item tree traversal and
pointer comparison and storing the intermediate indices in the
components in the tree, remember the focus item by a pair of
VWeak<ComponentVTable, Dyn> and item_index: usize.
This speeds up determining the focus item as well as delivering events,
which can now be done directly after retrieving an ItemRef with
get_item_ref.
This also fixes the duplicate line edit focus in the 7gui cells
test case.
Extract the StyleMetrics from the style and pass it to the layout
lowering pass for application.
The tests were adjusted to explicitly specify the padding/spacing to
override the ugly style default.
The all_documents member does not have to be externally provided, as
long as we keep the typeloader in scope instead. Since we'll later pass
it down to the layout lowering pass, that's fine.
This will allow the online editor to load imports from URL asynchroniously later
Since currently the compiler is only working on a single thread, and that we
never await on a future that could block, it is allowed to use the spin_on executor
Given the test case
import { SomeType } from "somewhere.60";
import { Blah } from "foo.60";
and foo.60 trying to use "SomeType":
export Blah := SomeType {}
then the lookup for "SomeType" in foo.60 should fail. Instead it leaked
through the populated type registry when processing the dependencies for
the outer file.
This is fixed by ensuring that the type registry for a file only has the
global type registry as parent. To ensure that the test reliably covers
this, the import dependencies are now processed in declaration order
(hence the switch to IndexMap that preserves insertion order).
We decided that their type mapping is not ready for public API yet. For
example for duration we'd like to replace the opaque i64 with another
opaque type that however has convenient conversions to
std::time::Duration or std::chrono::milliseconds. We can't use either
directly because we need ffi compatibility, in order to create an
instance in C++ and pass it to the Rust run-time.
So this hides such properties and instead produces a warning.
Instead of panicking in later phase.
Use the same function in the syntax_tests that the one we use in the different
compiler frontend so that the problems would also be shown in the tests
The Rectangle element has properties for a border outline. If those are
used, then the generated code should use BorderRectangle. But if they are
not used, then we can fall back to just generating a Rectangle.
