The preview can not leave it up to the interpreter to handle element selection
and highlighting. So add new functions to the interpreter (behind the
"highlight" feature-gate) to query positions of elements.
This exposes some of the code that is used by the existing highlighting code
and extends it where needed.
Two use-cases need to be covered:
1. Query the positions of a component (given by source file path and offset).
This is then used to highlight all occurences of a component as the
cursor position in a source file changes.
2. Query the position of an element (given as `ElementRc`).
This is used when selecting elements in the UI. We need to work at
the element level for this, not at the component level.
Also make the `highlight` module public but feature-gated, so that we
can put helper-types there.
* Make sure design mode stays enabled when refreshing the preview. This
stops the strange click-throughs from happening
* Keep highlighting enabled while in Design Mode
Clean the highlight pass so that it is in the same form as the paths
stored in the interpreter. Otherwise they do not match and highlighting
will fail.
* Extend the cspell word list
* Remove those extensions from individual source files
* white-list licenses and such as we should not meddle with those
* Fix spelling
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
* Configure clippy to not report about type complexity until *much*
later
* Configure clippy to only complain about more than 10 function
arguments
* Properly format safety sections
* Allow unnecessary main functions in doctests in the slint API crate
* AccessKit: Move big block of code before if condition
We need to check whether we wrapped around in the main part of the
logic: find_next can be called repeatedly in one walk of a tree, so it
fails if there are two or more items that are all sorted out later.
* compiler: Make mapping from source offset to line/column more reusable
* compiler: Improve mapping of offset to line/column
* Fix unit tests after line mapping update
* interpreter: Add code to have a element picker mode
* slintpad: Add picker mode to the preview
* slintpad: Do not try to highlight "empty" highlight requests
* Slintpad: Cycle through all the possible elements in design mode
* Slintpad: Ignore builtins and eat less clicks
* Slintpad: Highlight the element selected in design mode
* Slintpad: Do not use static mut variable in design mode
* slintpad: Rename `set_current_element_information_callback`
* Interpreter: Do not use unsafe in design mode code
Done with: @ogoffart and @tronical
Make sure this is the actual builtin type we are looking at and not a
re-defined component
Doesn't work for ListView unfortunately because ListView is not a
builtin type
CC #861
