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`
As per commit 69feb7f0f40cc8dc4ca52777cf87a4c879d4b953 in meta-slint and
others, the Skia build is tricky because clang needs to be indirectly
and carefully instructed where gcc headers are located. In the Yocto
recipes, we go through lengths to set CLANGCC/CLANGXX correctly so that
the --target matches the triplet sub-directories in
recipe-sysroot/usr/lib and recipe-sysroot/usr/include/c++/$ver/ .
For aarch64 it's simple, there's usually just aarch64-$distro-linux, but
for example for armv7-$distro-linux-gnueabihf magic has to come
together: The gcc install dir is typically
recipe-sysroot/usr/lib/arm-$distro-linux-gnueabi (note the v7 and hf
absence). That means that's what --target needs to be when invoking
clang. But now the `hf` suffix is gone, which means clang relies on for
example -mfloat-abi=hard to avoid the use of gnu soft-float stubs. All
that's meticulously prepared in the Yocto recipe and placed for easy
consumption in CLANGCC/CLANGCXX environment variables. Therefore, when
those environment variables are set, don't overwrite them in
CORROSION_ENVIRONMENT_VARIABLES.when those environment variables are
set, don't overwrite them in CORROSION_ENVIRONMENT_VARIABLES.
TODO:
- Polish the API
- Most screenshot test are failling because the rotation don't draw the
rounded rectangle exactly the same (that's because the border
rectangle algo is not perfect), and also scaled image are not pixel
perfect
The updated screenshot is because of a small change in the image
rendering algorithm that changes the rounding slightly.
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 reverts commit 292f487815.
Olivier had the brilliant idea of preceeding the path with a slash
on the Yocto side, so we can go back to the correct "type".
This reverts commit 0773e51d92.
By the SLINT_COMPILER being a `FILEPATH`, cmake will convert any
relative path to an absolute path. That's not wanted for the Yocto
build, because there we pass
'$ENV{OECORE_NATIVE_SYSROOT}/usr/bin/slint-compiler', so that
the path is resolved dynamically against the environment variable that
the Yocto SDK sets.
CMake would convert this to an absolute path that points into the build
directory, i.e. it would be /home/blah/foo/\$ENV{...}
Commit 9b62b08ed6 fixed
https://github.com/slint-ui/slint/issues/1066 initially, but commit
1036c0d082 erroneously regressed this
again, because while Corrosion sets this property, it is only set on the
locally generated CMake target. We still need to propagate that also
into the installed CMake target, which this patch does.
When building with cmake, buildroot sets PKG_CONFIG_SYSROOT_DIR in its
toolchain file, and therefore it's only available at configure time but
not build time, which is when our dependencies need it.
We enable libseat's custom_logger feature by default, which redirects
log output from libseat into the Rust log facade. That's nice, but as
part of the implementation of this feature unfortunately libseat's
build.rs unconditionally adds /usr/local/include to the list of the
search include paths when compiling the log_handler.c file. That breaks
the Yocto build, rightly so:
warning: cc1: error: include location "/usr/local/include" is unsafe for cross-compilation [-Werror=poison-system-directories]
We can do without this feature, so let's not enable it.
What happens is that the item is destroyed and removed from the layout
when clicking. But the send exit event still query the geometry if the
ItemRc which points to position in the layout cache that is not valid.
The Rust and C++ generator already check for the vailidity of the index
and return 0 if it's too large.
Fixes#3589
