The geometry of the box shadow element does not include the offset and
the blur. So our clipping may ignore the shadow when it shouldn't. This
could be changed by making geometry() return bounds that include the
blur and offset, but that in turn will add a visual offset when a
repeated rectangle has a shadow, because the shadow because the root of
the repeated element and the previous rectangle a child.
Fixes#713
The cached shadow image should just be the cache of the shadow. This
removes a visible "edge" from the shadow sometimes and brings the
rendering in line with the Qt backend.
two problems
- For the interpreter, properly handle the case of an alias to a global
- For the rust generator, we can't return a reference to a property held
in a global, so we must 'inline' the get_xx funciton on sub-components
... and using the sixtyfps! macro
The problem is that the OUT_DIR in the build script of the macro crate
is reporting a target directory for the host (since the macro itself is
built for the host), but we need to get the OUT_DIR of the crate, so query
it in the macro. Unfortunatelty, that env variable is only set when the
crate (using the macro) has a build script. So use a fallback to find the
target directory
Fixes#462
I used a `#[cfg(..)]` instead of a feature flag because then it is enabled
for both the compiler and the lib at the same time, and since it is only a debug stuff
it does not need to be enabled within the project. So one must enable it with
`RUSTFLAGS='--cfg sixtyfps_debug_property'`
Due to a bug in Qt's implicit sharing in QPalette, the resolve mask of
QGuiApplicationPrivate::app_pal would get changed with an unrelated setColor
call and thus break color resolution from a new base palette when the theme changes.
For the MCU port, we need to proccess the image to save them in the binary
in a convenient format.
This patch start this work by trying to anaylyze what format should an image
be using, and saving it as a texture in the binary.
The current graphical backend and the C++ frontend are not yet supported
The default backend does not select any features or backends by default
on the Cargo.toml feature level. And with this change it also doesn't do
that anymore based on the target platform.
That means if the rust api crate is built with default-features = false,
no backend will be selected and the user has to take care of backend
initialization through other means.
The feature defaults, generally, are in the rust API crate, the
interpreter crate and C++ CMakeLists.txt. The latter triggers a cargo
build of sixtyfps-cpp with --no-default-features. However the cpp_test
job in the CI doesn't build sixtyfps-cpp with CMake but instead calls
cargo directly. Therefore the defaults are now also coded in the
sixtyfps-cpp Cargo.toml, to ensure that *a* rendering backend is chosen
(since the cfg.target bit is gone).
