A `Path` with `MoveTo`/`LineTo`/etc. sub-elements now maps to an Expression::PathData of type
Type::PathData.
The llr lowering creates an Array of Type::PathElement, which is casted to PathData.
This only covers the element case. The compiled path events are still todo.
Our web site and READMEs direct to our Rust API crate, which makes sense as it provides
fundamental traits and types. However as pointed out in
#811 we should advertise the existence of the interpreter API.
Ideally we'd link to the crate documentation that
(1) perfect matches the version number
(2) uses sixtyfps.io for our built docs and docs.rs for the published crates
I could not find a way to do this (not without making the crate a dependency and adding features), so
this patch is a compromise that I've seen used in other
crates.
The indexes stored in `VisitChildrenResult` are unsigned. We have 64
bits to store two values and we need to have one special value as a flag.
So accept any index `< u32::MAX` instead of `< i32::MAX`, which should
allow for more data to be visited;-)
The docs were living in the public header file while the enums/structs were defined in Rust.
With the infrastructure of the parent commits we can join them together.
This change makes the start of sharing the docs for the `TimerMode` enum
between Rust and C++. The reference to Timer::start in there works as
both doxygen and rustdoc find the right reference, but this needs
careful editing in the future and double-checking!
Another "caveat" is that the docs for the TimerMode enum say that the
enum is defined in the file "sixtyfps_generated_public.h", which is
correct as-is but not as pretty as "sixtyfps.h". I tried various ways
with \file and \includedoc, but couldn't get it working differently.
To implement this, the cppdocs steps now also runs cbindgen and cbindgen
generates a new sixtyfps_generated_public.h file that contains types we
do want to have in the public sixtyfps namespace.
* Improve headings and linkage
* Replace "you can use XXX to YYY" with "Use XXX to YYY"
* In the limitation about exported components, link to the tracking
issue.
This is listed under the reference ("how to") and explains `SIXTYFPS_SLOW_ANIMATIONS`, SIXTYFPS_DEBUG_PERFORMANCE` as well as `SIXTYFPS_SCALE_FACTOR`.
cc #728
... 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
* Rename the package to `SixtyFPS-cpp-*` to make it easier to see that these are for C++
* Refer to the download and extraction process in the two C++ "READMEs"
* Set the home page url in the cmake project() command, from where cpack will pick it up for inclusion in the installer.
cc #631
We bundle Qt and Qt needs the VC runtime DLLs. There are two options:
Find and locate vcredist.exe, include it in the NSIS installer and run
it. Alternatively, a cmake module exists to locates the DLLs and
install them.
This patch uses the latter option, for simplicity. When upstream ticket
https://gitlab.kitware.com/cmake/cmake/-/issues/17725 is implemented, we
could switch to the first option.
Note: This might include a few DLLs that Qt probably doesn't
need.
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).
We copy the sixtyfps_cpp.dll into the bin directory where the examples
are, but that needs to be a Debug/ or Release/ sub-directory in case of
a multi-config generator.
