When called from inside some winit event handler, we'd go straight to
`with_window_target` to get hold of the event proxy and send it. However
when called through some external event handler (DOM), the scoped
CURRENT_WINDOW_TARGET would not be set and MAYBE_LOOP_INSTANCE would
also be empty because `run` takes it. So instead we'd end up creating an
new event loop instance and the event would sit in there forever.
Instead, this change brings WASM in line with the other platforms by
using the dedicated event loop proxy (global_proxy). Because of the lack
of threading the dance of storage for that is a little different though.
On Windows 10, the creation of symlinks by normal users requires
enabling the developer mode, which may or may not be acceptable in
corporate environments with restricted IT setups.
We introduced the symlinks for the shared special key codes mapping,
which instead this patch places into a shared sixtyfps-common crate.
This issue was caused by two bugs:
* The scale factor was not a property dependency of the Image cache entry's property tracker
* The texture cache key for SVGs should include the target size that's scaled to.
Fixes#734
Separate the image cache from the texture cache.
The latter needs additional data in the key. The two have less in common that it seemed.
This also fixes a small issue with `CachedImage::upload_to_gpu` that for
SVGs would return a decoded (rendered) SVG image, instead of a texture.
That was harmless because we always call `ensure_uploaded_to_gpu`
later, but now we assert that the texture cache only holds textures,
because clear() (former remove_textures()) just clears everything.
Share the code that defines the key with a macro over all the backends using
a symlink.
This is a symlink rather than exposing the macro directly since we add this
module in every backend, and each backend re-declares the macro to handle
the part that it needs. This needs to be a symlink because it will also be shared
with the compiler that does not depends on sixtyfps-corelib
The initial clipping was set in physical size rather than in logical size.
When scaling up, this does not have visible effect, but when scaling down
it clips too much.
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.
