This changes the component containers away from using a "MAGIC" index in the
placeholder dynamic item tree node it creates. These are hard to
integrate across sub-components.
Use index numbers right after the index numbers used by repeaters and
"extend" the repeater offset by the number of component containers in
the sub-component. This way we can piggy-back on the forwarding of
repeaters.
This has one annoying side-effect: We do have indices in our item tree
that are out of range for a repeater. But I think that is acceptable
considering that we never materialize that array anyway.
For the backend selector, this means that when a backend is selected explicitly,
and initialization fails, don't try `create_default_backend()` but
propagate the error.
For the Rust code generator, propagate the first ensure_backend()
errors. Any subsequent onces (unlikely, since the first thing any
public new() calls is ensure_backend) will unwrap.
In `ItemRc::find_sibling` we currently do:
1. get the range
2. check that the next index is within the range
3. call `get_subtree`
The problem is that get_subtree itselg will call 'ensure_updated' which
will do the relayout of the ListView and may get a different range of
element.
So don't query the range before and just have get_subtree to return an
empty ItemWeak if we are out of the actual range.
Couldn't really find a way to make a test since this is called from
the accessibility code which is hard to test as is
For #3700
and their related name.
Also move the component module in the item_Tree module
register_component -> register_item_tree
ComponentItemTree -> ItemTreeNodeArray
For #3323
Rationale from that issue:
Right now, we use the term `component` in the Slint language and in the compiler to be a a tree of elements that can be used as an element in a .slint file.
The term is also currently used in the runtime as a tree of runtime Items that are allocated together. (declared in ComponentVTable)
But there are no 1 to 1 mapping between a `component` in the slint language, and a runtime Component.
(for example, the items behind a `if` or `for` or `PopupMenu` are in a different runtime component. And `component` declared in Slint are often inlined)
So we should rename the internal runtime `Component` to `ItemTree`
The currently public `slint::ComponentHandle` wraps the "root" of the ItemTree, but that's ok because it is generated from a .slint `component`, so it doesn't change name
So it doesn't appear in the LLR and the C++ codegen can be simplified.
In particular, this removes the need to throw/catch exception to handle return
across generated lambdas
... if they are not set as actual binding before
As reported in #3068
The problem is that the pass will properly create the Rotation or
Opacity item, but will not create the two way binding if there is no
existing binding. This causes code like `img.rotation-angle = ...` to
change the rotation angle of the image, but not its parent Rotation
item.
Fix it by making sure there is always a binding.
Since the change only affect visual representation, I abused one of the
screenshot test to test this feature. And I also patched another bug
that some #[allow(unused_parens)] was not set in the 'init' callback and
would cause a warning in the test
using `use slint::private_unstable_api::re_exports as sp;` should
allow to safely qualify everything will keeping things shorter.
For the `todo` example:
- before 1_050_650 octets for 24_012 formatted lines
- after 934_049 octets for 23_032 formatted lines
This also makes the generated code more readable if needed.
The type of thep property is `Point`, which existed before. It was
mapped to `slint::private_unstable_api::re_exports::Point` (euclid) and
is now mapped to slint::LogicalPosition (also in C++).
This will be needed for embedding - to avoid creating two window
adapters - and it will be needed for the API to allow creating a
component from an existing window.
