We support directly nested layouts, but we did not support indirect
nesting:
GridLayout {
Rectangle {
l2 := GridLayout { ... }
}
}
This patch fixes that by detecting this scenario and merging the layout
info of the element (Rectangle) and the layout inside (l2). This makes
it much easier to create re-usable components that use layouts
themselves and allows placing them in layouts.
Sometimes re-usable components need to act as containers that allow the
user to place other items inside. The component needs to be able to
control the placement of these user-provided elements. That is what the
new
$children
expression inside elements does.
This will allow us to break up the styles, so that one can have for example
button.60
checkbox.60
and finally widgets.60:
import { Button } from "button.60";
import { CheckBox } from "checkbox.60";
export { Button, CheckBox };
and then the users have to only import "widgets.60";
Instead of doing the SyntaxNodeWithSourceFile construction as late as
possible (in Document::from_node), we can do it as early as possible.
That'll reduce the chances of missing out the source file and prepares
for dependency loading just based on a SNWS :)
This also makes the source_file optional in the SNWS, but that's
consistent with what the diagnostics expect.
When going from the plain rowan::SyntaxNode tree to the syntax_nodes::*
elements, attach the source file and keep track of it from that point
on. That'll pave the way for proper multi-file diagnostics generated
later on from the passes, where we store syntax_nodes::* types.
Let the bulk of the push_error() calls take a Spanned trait impl, so
that we can pass node on the call sites. Then when later change the
underyling trait to pass something that can also provide the source file
and we don't have to change all call sites again.
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.
