Note: this adds a mendatory template parametter to the
(experimental) `render_by_line` function.
I tried to get the PixelType auto-detected from the callback but i
didn't manage
This is a hacky approach, but does help a lot with the tedious fixes.
See https://rust-lang.github.io/rust-clippy/master/index.html#/unnecessary_map_or
```
__CARGO_FIX_YOLO=1 cargo clippy --fix --all-targets --workspace --exclude gstreamer-player --exclude i-slint-backend-linuxkms --exclude uefi-demo --exclude ffmpeg -- -A clippy::all -W clippy::unnecessary_map_or
cargo fmt --all
```
Only the interpreter is implemented so far
MacOs won't work yet because we don't disable the default winit menubar
The viewer don't support removing the MenuBar yet
The origin of this proposal is the name of the `swipe-left`, etc.
directional, boolean properties. They're missing another verb in their
name. In principle the right choice would be "recognize". That is what
the type name suggests, that's the term the documentation uses, so the
code should read `recognize-swipe-left: true;`. However that is a long
word. "Handle" is a verb that's simpler. It's also more generic (that's
a downside), but it's otherwise short enough to make things look
"right":
```
SwipeGestureHandler {
handle-swipe-left: true;
swiped => { something.naviate-left(); }
}
```
Therefore this patch proposes to rename the type to SwipeGestureHandler
and prefixes the boolean directional properties with "handle".
The C++ build started failling with nightly rust:
https://github.com/rust-lang/rust/pull/125174 changed the output of
strignify! to contins more spaces between tokens, which we relied on to
perform some type substitution from Rust types to C++ types, resulting
in compilation errors:
```
build/api/cpp/generated_include/slint_builtin_structs_internal.h:71:5: error: ‘Option’ does not name a type
71 | Option < core :: ops :: Range < i32 >> replacement_range;
| ^~~~~~
build/api/cpp/generated_include/slint_builtin_structs_internal.h:75:14: error: ‘core’ was not declared in this scope
75 | Option < core :: ops :: Range < i32 >> preedit_selection;
| ^~~~
```
Workaround by cleaning whitespace before matching the types.
Updated the version from 1.1 to 1.2
Renamed the header to "Slint Royalty-free Desktop, Mobile, and Web Applications License"
Added definition of "Mobile Application" and grant of right
Moved "Limitations" to 3rd section and "License Conditions - Attributions" to 2nd section
Added flexibility to choose between showing "MadeWithSlint" as a dialog/splash screen or on a public webpage
Moved the para on copyright notices to section under "Limitations"
We have a nice FFI-compatible wrapper areound rust timers in C++, so
allow to use that in other types exported to C++.
This also makes sure the rust and C++ side agree on the size of the
type, with the nice side effect that the rust Timer now uses half as
much space now as it did before.
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
