* 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`.
The problem is that the file stays in the `currently_loading` hashmap
and therefore we thinkg we need to await for the result, while it is not
actually loading
Regression since f1f5a86d0dFixes#3468
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)
Since they no longer have a builtin width/height property, the test
that checked the type was wrong. But since we can't override the width
or height property with another type, this should not be relevant
This doesn't work yet as we need to do more "patching" of anything that
uses the x and y properties
This reverts commit 2d6fec78f9ff01c8b4904685fae0ce587a3c8e9a and
036ddfe23aa5f5b63778b8056d58c30c08f942fe.
The WindowItem did not have a x or y before, so these property
were unused for it's geometry(), but now it is used in the new
item_geometry on the ComponentVTable.
So make sure we don't initialize them
