Only the hand-picked sensible things, not all of it ;-)
Also fix a few typos that cspell complained about when I
tried to commit and some formatting changes that cargo fmt
insisted on when commiting.
Otherwise, programatic changes to the text are not told to the input
methods.
This is important in the case of the todo example on android.
For example if one type
`foo<enter>bar`, the enter will cause foo to be added in the list, and
the text will be cleared. But then when typing bar, the input method
things "foo" is still in the text and "foo" will be re-added
As a side effect this fixes the infinite recursion from #4390
because there is a prevention that focus being sent to the element
inside a ComponentContainer (the bug is that this cause the size to be
computed which cause recursion)
I've tried to make sure the behavior match the one of native Window (and
Qt on Linux) apps, and android apps.
Windows set the focus on press, but android set the focus on release.
Also, the paste selection on middle click happens on release on Linux.
On android, when taping a text edit that currently has the focus,
we should show the virtual keyboard again if it was hidden by the user.
Having platform specific behavior like this in i-slint-core is not
optimal, but on the other hand, I'm not sure this deserve a new function
in the Platform trait
So that we don't erase selection or call edited unless there is
something typed.
Workaround a bug in which plasma/wayland sends many empty ime event:
```
WindowEvent { window_id: WindowId(WindowId(94309690701616)), event: Ime(Preedit("", None)) }
```
Fixes#4184
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
Otherwise we end up with outdated pre-edit data if we change focus while
editing.
Note: Qt doas actually send a "commit" event when the focus change
(but of course that does not happen when changing the focus within
slint)
But firefox does discard the preedit when loosing the focus.
CC #1925
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.
When the TextInput item is read-only, it should not report availability
or any other status to the input method via the window adapter.
This also fixes the order of events when clicking on a TextInput: We
would send the ime position update request before enabling the ime,
because we set the focus _after_ setting the cursor pos.
Fixes#2812
In the compiler this is still very primitive, but an attempt to start a
generic interface. The basic assumption is that all item functions will
eventually need access to the window adapter and itemrc. Support for
additional arguments is still missing.
Also missing is support for the function access via rtti in the
interpreter, hence the hardcoding at the moment.
Make text_input_byte_offset_for_position and text_input_cursor_rect_for_byte_offset
low-level in the API, where the implementation becomes easier. Two
helper functions in TextInput in turn collect the necessary parameters
and thus also reduce the amount of duplicated code.
This also decouples the renderer further from the window.
So that we don't need to query the geometry multiple time, and this pave
the way to not have the geometry in the items
Part of #1932
As a drive by, fix the clipping of the Path element which incorrectly
offseted the clip by (x,y).
Similar fixes happen in the Clip element in some renderer, but that
didn't have effect because x and y are always 0 for the Clip element
