If you have a window like so:
```
component W inherits Window {
width: 200px; // or some other bindings
}
```
Before this patch, it will be converted by the compiler to something like
```
component W inherits Window {
width: 200px; // or some other bindings
min-width: width; // (not actual property, but part of the layout_info)
max-width: width;
}
```
When the window is on the screen, the platform backend will set the max
with and min width on the window manager window to the value from the
layout info.
But slint will also set the width and the height of the WindowItem to
the actual value. This will break the binding for width if any, and
will also cause the min and max with do be updated, which is wrong.
We haven't had much problem with that before, but with the
ComponentContainer, this becomes a problem as we want to set the width
and height of the inner from the outer by adding a two way binding,
which cause a binding loop at runtime.
The behavior change is that if you have a fixed window size and use that
on a MCU or platform that has a different size, the window will be
cropped or padded but will no longer be resized
commit 975abf3c42 introduced a regression.
Two problem:
- we were taking the geometry from the parent instead of the element
that need the shadow
- Element::make_rc override the geometry with its own properties
Unfortunately annot be tested as this only visual, and the software
renderer don't support shadow yet
Fixes#3743
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
Parents surch as Opacity, Clip, and co, used to steal the x and y
property of their children, making the property not what they ought to
be.
Now that we refactored recently the code so that geometry need not to be
always linked to a property of the same name, we can dissociate the x
and y property of these generated elements and their content so that the
actual "x" property of the former elementstay some value, despite its
relative item property is now 0.
Had to change a bit of code that was still assuming a literal "height"
or "width" or "y" or "x" property that no longer worked when the
geometry is dissociated from its property
Fix#1072
* 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
This is used in slintpad to map relative image URLs to their real
download locations.
This has the side-effect of removing the service worker.
Fixes: #2905
Resolve an image path to soemthing relative to the syntax node that
pulls it in if the path can not get resolved.
This typically happens in WASM as file existence is checked during image
resolution, which is not possible there.
We see that a lot in the fluent style. For example:
```
font-size: Typography.body.font-size;
```
Where Typography.body is a contant expression define as
```
out property <TextStyle> body: {
font-size: 14 * 0.0769rem,
font-weight: regular-font-weight
};
```
But because this first converts from an annonymous tuple struct to a
named struct, the const propagation used to be confused. Now with this
patch it is properly simplified
Before this change
cargo run -p slint-compiler -- examples/printerdemo_mcu/ui/printerdemo.slint -f rust | rustfmt | wc
38643 84506 1925846
cargo run -p slint-compiler -- examples/gallery/gallery.slint -f rust | rustfmt | wc
103210 224427 5291034
After this change
cargo run -p slint-compiler -- examples/printerdemo_mcu/ui/printerdemo.slint -f rust | rustfmt | wc
38629 84473 1924995
cargo run -p slint-compiler -- examples/gallery/gallery.slint -f rust | rustfmt | wc
102628 222423 5261760
This makes the layout code a bit bigger in size as the inlined version
is constructing struct from constant, but let the slint compiler "see"
though more code and allow to optimize away many layout related properties
Before this change
cargo run -p slint-compiler -- examples/printerdemo_mcu/ui/printerdemo.slint -f rust | rustfmt | wc
38873 83654 1925830
cargo run -p slint-compiler -- examples/gallery/gallery.slint -f rust | rustfmt | wc
103817 224874 5316553
After the this change
cargo run -p slint-compiler -- examples/printerdemo_mcu/ui/printerdemo.slint -f rust | rustfmt | wc
38643 84506 1925846
cargo run -p slint-compiler -- examples/gallery/gallery.slint -f rust | rustfmt | wc
103210 224427 5291034
Layout code generates a lot of code and it may be beneficial not to
generate constraints if there is no constraints in that direction
Before the change:
cargo run -p slint-compiler -- examples/printerdemo_mcu/ui/printerdemo.slint -f rust | rustfmt | wc
40014 86643 2010535
cargo run -p slint-compiler -- examples/gallery/gallery.slint -f rust | rustfmt | wc
105715 229009 5434115
After this change:
cargo run -p slint-compiler -- examples/printerdemo_mcu/ui/printerdemo.slint -f rust | rustfmt | wc
38873 83654 1925830
cargo run -p slint-compiler -- examples/gallery/gallery.slint -f rust | rustfmt | wc
103817 224874 5316553
No measurable changes in compilation time.
* Export interpreter stuff on private_api namespace
* Update api/napi/src/interpreter/value.rs
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Update tests/driver/napi/build.rs
Co-authored-by: Simon Hausmann <simon.hausmann@slint-ui.com>
* Update tests/driver/napi/Cargo.toml
Co-authored-by: Simon Hausmann <simon.hausmann@slint-ui.com>
* Avoid unwanted prompt on Windows when running npm run build twice
Don't generate "napi.js" as then Windows will try to open it when running just "napi",
if nodejs registered .js as extension.
* Remove windows path workaround
It doesn't look like that it is needed.
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Simon Hausmann <simon.hausmann@slint-ui.com>
Co-authored-by: Simon Hausmann <simon.hausmann@slint.dev>
Add some code to do platform-independent path processing.
This is necessary aas WASM does e.g. not have any absolute paths and
such and the compiler tended to produce wrong results in that case.
Side-effect: We no longer need to depend on `dunce`
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
This is a fairly large struct and it uses lots of the limited thread
local space which is limited on some platform
This also doesn't need to be on a thread local since we only use it once
just to register the types.
Should help with #3551
- Remove extra padding from the todo demo. Box in Box causes the
padding to be added twice otherwise. And the Box have extra big
padding with the material style.
- Fixup the combobox size to be consistant with fluent wrt sizing
- Use the proper color for the checkbox border, following the
style specification
This moves most of the version information we need to update into one
place.
Note that the workplace dependency features are in *addition* to any
feature set when using the workspace dependency. So we have all
workspace dependencies defined with `no-default-features = true`.
