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
- s/physical_size/size/ (consistant with the slint::Window API)
- remove const of virtual function (they don't need to be const and
make implementation potentially easier)
- Move the WindowProperties in it
- make sure the Platform::Clipboard type is properly documented
- Use the actual enum in the interface (even though it is
#[non_exhaustive] so we need to slience a warning)
CC: #3265
... and provide hints in there about implementing window close requests.
Note: The links to set_size() and set_position() are not resolved, as
these virtual functions are still missing from the WindowAdapter base
class.
- Fix pre-processor include search path setup so that pre-processing
slint.h finds slint_internal.h and (most importantly)
slint_generated_public.h for the feature defines.
- Add missing documentation that caused doxygen errors.
Copying the Rust enum instead of using cbindgen because we would need to
create a new header just for it for bublic types generated in the
platform namespace. I've also put it in the SoftwareRenderer class since
the equivalent enum is in the software_renderer module in Rust.
