`@image-url("")` should translate to `Resource::None` instead of
`Resource::AbsolutePath` to avoid that the rust compiler tries to
include a directory when embedding images.
Use only specific lyon packages instead of pulling all of them in.
This slightly speeds up compilation as well as for example lyon_tesselation
doesn't need to be compiled anymore.
Add support for built-in property aliases and rename `color` to
`background` - in preparation for it also changing to type brush.
Right now the alias is silent, a deprecation and overall change
will come in a subsequent change.
This also makes the focus() method available as a member function on any
item, but the resolve_element_reference_in_set_focus_calls() pass will
check if the elements are valid.
The check for `has-focus` to determine a focusable item was replaced
with an annotation on the built-in elements, so that `has-focus` can
later be implemented as a built-in function through the run-time,
without the need for a boolean property.
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.
When converting from object literal to object literal, we would check
recursively if the individual fields can be converted and then generate
code to convert each field.
For a conversion frmo object literal to a struct, we would a per-field
can_convert check as well, but there would not be any code (Expression)
generated for the conversion, instead it would be a straight cast. That
was fine so far in our tests and example code, because the fields never
required a conversion. With commit
071ab9fda1 the percentage number literals
used in the printer demo however would now require a conversion
(multiplication by 0.01) before the assignment to the float level field.
This patch adds the missing conversion by matching the Object -> Struct
conversion case, generating an intermediate Object type based on the
struct's properties, call maybe_convert recursively and *then* cast the
result to a struct.
Typically `some_length_prop: 40%` produces an error, but if there's a
matching property in the parent, then it will be allowed and interpreted
as relative value and creates a dynamically updated binding.
Delay the conversion of percentage to the float to code generation type
by inserting the multiplication into the syntax tree. That way we will
be able to detect plain uses of percetages and interpret them
differently.
The logical pixels are now just called "px" and the less frequently
used physical pixels have the "phx" suffix.
The existing markup was adapted using the syntax updater and the
following patch:
+ if node.kind() == SyntaxKind::NumberLiteral {
+ if node.text().ends_with("lx") {
+ return write!(
+ file,
+ "{}px",
+ node.text().as_str().split_at(node.text().as_str().len() - 2).0
+ );
+ }
+ if node.text().ends_with("px") {
+ return write!(
+ file,
+ "{}phx",
+ node.text().as_str().split_at(node.text().as_str().len() - 2).0
+ );
+ }
+ }
Fixes#49
