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.
... 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
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).
PR #642 fixed making the window not resizable when it has initially a
fixed size. This change applies a different logic with the same
resulting effect when the window item changes later, for example when
transiting in the live-preview from a fixed size to a resizable window -
by looking at the min/max constraints.
Treating the Tab key as text disallows handling Shift-Tab because
the shift modifier will not be passed down. This makes the
handling of Tab analogous to Escape, Return and other non-text
keycodes.
Avoid creating an intermediate array of items to free the graphics resources.
Instead call run-time function with the item tree as a parameter, which is traversed.
It's practically the same data structure that was previously created, except
that it is shared/global and has little holes for the dynamic tree items, but those are easy to skip.
