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.
This is listed under the reference ("how to") and explains `SIXTYFPS_SLOW_ANIMATIONS`, SIXTYFPS_DEBUG_PERFORMANCE` as well as `SIXTYFPS_SCALE_FACTOR`.
cc #728
* 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.
Similar to the parent commit, the model tracks changes to the rows and
marks an internal property dirty. Since we have a base class this is a
little less intrusive.
cc #98
This allows compiling with SIXTYFPS_EMBED_RESOURCES=true and
images/fonts are embedded as inline variables.
Generated data is emitted into the header file as
inline uint8_t sfps_embedded_resources_123[789] = {
0x1, 0x2, 0x3,
};
