PR #669 changed the wording, but the tutorial uses the sixtyfps! macro
for which that wording was fine.
Instead, be more explicit about chere the file is looked up in both situation
After commit becb4574c1 we'll
make sure not to set the plugin application attribute when initializing
the Qt backend. Unfortunately in the generated struct the NativeStyleMetrics field
is placed and initialized before the m_window. The Default::default() impl
calls `ensure_initialized()` with `from_qt_backend = false` because we don't
know what backend is being used. Since due to the ordering this is the first
call to `ensure_initialized()`, we'll end up setting the plugin application
attribute.
This patch fixes that by ensuring that the m_window field always comes first,
which is initialized with a call into the run-time library, which in turn
delegates to the backend. That'll be the Qt backend and we'll initialize
the application object correctly.
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.
When the workflow is triggered via workflow_call, the input
is in different variables unfortunately. Try to use the same trick as in
sixtyfps_tool_binary.yaml.
Always build the vs code extension, the regular CI should be the guard in the future and this needs condition somehow doesn’t work (never triggers despite all green)
This requires adding Cargo features to the lsp in order to be able to
make a build that doesn't use the GL backend. In theory --features
sixtyfps-interpreter/backend-qt could be used to opt into Qt, but
there's no way of turning off the gl backend AFAIK - hence the features
in the lsp.
This splits the docs and wasm workflows into shared files, that will be
called (for QA purposes) from ci.yaml as well as from nightly_snapshot
(for publishing).
The viewer build is also triggered by the snapshot workflow.
We can't support it with the interpreter, and the compiler running on wasm
is only used for the interpreter.
And this cause compilation issue because some dependencies enable features
that breaks the build
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).
The objective is to split up the workflows, which requires the existence
of the *new* workflow files in the master branch in order to trigger
test builds in a branch.
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.
