This is the counter-part, which removes focus from the element if it's currently focused. The window - if focused - may still be focused towards the windowing system.
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"
The call to load the image already prints a message to stderr, so don't
panic but return a null image instead - neither when calling load_from_path
nor when decoding embedded image data.
cc #4846
Semi-random selection of clippy topics that were
uncontroversial before:-).
Leaves about 84 deduplicated issues in the code base
according to clippy from nightly.
Fixes#4741
This commit move the property_binding_and_analysis from the inlining
pass to an associated funciton in the context.
Then re-use that from the rust and c++ generator to actually get the
right animation
```
error: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused
--> internal/core/item_tree.rs:1035:32
|
1035 | Pin::new_unchecked(&*(&**component as *const Dyn as *const u8)),
| ^^^^-----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| backing allocation comes from here
|
= note: casting from `vtable::Dyn` (0 bytes) to `u8` (1 bytes)
= note: `#[deny(invalid_reference_casting)]` on by default
```
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
Warning looks like that
```
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\tuple(144,47): warning C4244: 'initializing': conversion from '_Ty' to '_Ty', possible loss of data [D:\a\slint\cppbuild\examples\virtual_keyboard\cpp\virtual_keyboard.vcxproj]
with
[
_Ty=int
]
and
[
_Ty=float
]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\tuple(239): message : see reference to function template instantiation 'std::_Tuple_val<_This>::_Tuple_val<_Ty>(_Other &&)' being compiled [D:\a\slint\cppbuild\examples\virtual_keyboard\cpp\virtual_keyboard.vcxproj]
with
[
_This=float,
_Ty=int,
_Other=int
]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\tuple(239,81): message : see reference to function template instantiation 'std::_Tuple_val<_This>::_Tuple_val<_Ty>(_Other &&)' being compiled [D:\a\slint\cppbuild\examples\virtual_keyboard\cpp\virtual_keyboard.vcxproj]
with
[
_This=float,
_Ty=int,
_Other=int
]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\tuple(802): message : see reference to function template instantiation 'std::tuple<float,float,float,float>::tuple<std::_Exact_args_t,int,float,float,int,0>(_Tag,_This2 &&,float &&,float &&,int &&)' being compiled [D:\a\slint\cppbuild\examples\virtual_keyboard\cpp\virtual_keyboard.vcxproj]
with
[
_Tag=std::_Exact_args_t,
_This2=int
]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\tuple(802,12): message : see reference to function template instantiation 'std::tuple<float,float,float,float>::tuple<std::_Exact_args_t,int,float,float,int,0>(_Tag,_This2 &&,float &&,float &&,int &&)' being compiled [D:\a\slint\cppbuild\examples\virtual_keyboard\cpp\virtual_keyboard.vcxproj]
with
[
_Tag=std::_Exact_args_t,
_This2=int
]
```
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
The parent is already deleted when we delete the component that is kept
alive by the `grabber` ItemRc in `handle_mouse_grab`
When the ItemRc goes out of scope, we delete the component, but the
parent was already gone.
This doesn't solve a broader issue that we use the parent in many place
and it is not kept alive (for example when using properties of the
parent)
