We need to maintain the order of declaration and the sub-trees
of children need to be emitted before continuing with the parent.
This fixes the tab widget in the galler.y
There's a check that verifies that the relative item indices match, between what
the item tree building code in the generator sees and the generate_item_indices pass.
The counting of the relative indices was incorrect with regards to the sub-trees.
Avoid creating an intermediate array of items to free the graphics resources.
Instead call run-time function with the item tree as a parameter, which is traversed.
It's practically the same data structure that was previously created, except
that it is shared/global and has little holes for the dynamic tree items, but those are easy to skip.
By accident the tree was still depth-first instead of level-order. This implementation works better,
by placing the root element of sub-components as
parents and the children into the children space later.
There's still more work to do to clean it up and make work with more complex scenarios.
When the use-site of a component tries to set a binding on a property that is an alias,
it might be that the alias was optimized away.
To avoid needeless recursion, this patch generates a mutable property getter
for declared properties (which takes care of alias redirection).
This also removes the use of root_item() because it's insufficient: If the property is custom (and/or an alias), then we need to use the getter,
otherwise we need to recurse.
So there are three cases:
```
MyButton {
text: "Ok";
}
```
If `MyButton` is `MyButton := Rectangle { property<string> text; }` then
we go through the mutable prop reference getter. This also works for aliases.
If it's `MyButton := Text { ... }` or (more complex) `L := Text {} MyButton := L {}` then
we recurse.
Traditionally the recursion is not needed because in public API the "inherited" properties
aren't expose. But since in the language they are exposed, we need to continue.
As a bonus this cleans up the property access code a little by re-using access_member.
* Forward declare the root component
* Pass it as a parameter to the constructor and save it as m_root pointer and use it to access globals
* Make the sub-components friends of the root component, in order to access the globals
* Delay binding initialization to an explicit init() call in sub-components
The parent commit accidentally removed the case of the generation for
the implicit layout info call where the layout info property is
available on a component (i.e. it is in a layout).
Amends commit ae25dd3d07
Provide a layout_info implementation for sub-components and call it. This
disables the lowering the implicit_layout_info call again,
also to ensure that when this
is installed from the use-site of the sub-component, the self can be used to obtain
the info (by calling the new generated function).
Inline sub-components that are used along with children, similar to @children. This way
we don't need to jump through hoops for the correct children
count in the item tree (or their placement/offset).
For the item index generation and the member population for the C++
structs, a level-order variant of `recurse_elem` is sufficient - as also
indicate by the unused item index parameters.
In the generator for producing the members of built-in items, repeaters
or sub-components, we don't need to traverse into sub-components. The
C++ compiler will take care of instantiating the fields of
sub-components after all.
For the item tree however we do need to recurse, so this change attempts
to do that. Repeaters are explicitly not handled yet though.
Instead of requiring inlining, assume that the generated code will provide an
implementation of layouting_info as well as root_item.
They're not implemented yet though.
This reverts commit 6e8d463d4bb88720a9682c839c5754959dd57c20.
It's better if the generated code for sub-components implements a
root_item function, instead of blowing up the generated code.
(1) ... when the root element is a sub-component itself (the initialy child offset is not 1)
(2) when children themselves are sub-components, then they may occupy more entries in the item tree
Within sub-components we only know the local item index, and together with the
offset provided in the constructor we'll be able to
compute the correct index for items that's needed sometimes,
for example for focus setting.
The item indices are still wrong though, that'll need fixing in the corresponding pass.
Besides `is_global()` add `is_root_component` to Rc<Component>, so that
we can distinguish between the main component (that should have the full
API, etc.) and supplementary components.
This also avoids the generation of unnecessary members when inlining is
disabled.
Remove the roots vector again, with selective inlining it's better
to use the "live" data structures instead of a copy of the roots.
It would be nice to centralize that into a helper function that returns
say an `Ref<'_, impl Iterator<Item = &Rc<Component>>>>` but that's not
possible yet.
The same chained iterator pattern is also used in some passes already.
Make sure that doc.root_component.used_types.structs has all the
structs, instead of storing them in used_types for each sub-component.
That should also account for the same structures used by different
components.
The generation is still incomplete, but this change passes them to the C++ generator
when not inlining.
Another option would've been a "inline: bool", but that won't suffice in
the future when we may want to use heuristics to selectively inline some
and others not. And always taking used_types.sub_components is wrong
when inlining as those are ... inlined.
