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 is done by exposing the ModelNotify to the caller via the new
ModelTracker trait, which has a function that allows "hooking" into the
dirty tracking of the size.
By extension, this also works in JavaScript.
cc #98
We can't call return-if-changed with "builtin:" URL, otherwise cargo
thinks the build script always need to be re-run
Fix the gallery example always being rebuilt because it uses AboutSixtyFPS
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,
};
The GL backend defaults to enabling X11. The default crate depends on
the GL backend but it doesn't specify default-features = false,
therefore x11 is basically always enabled.
In line with commit 1fd8c7236a, this
change makes sure that the defaults are defined in the tree entry
points: The Rust API crate, the interpreter crate and the CMake project
define the defaults. The latter already enabled X11 by default, but the
first two did not.
Don't generate the headers by default in the source directory, put them
into a sub-directory in OUT_DIR instead and convey that location via
links to the C++ test driver.
Make install would still trigger the generated_headers_target CMake
custom command - due to the use of add_dependencies - and that would end
up running cbindgen. That in turn breaks "make install" when it's run in
an environment that doesn't have cargo in PATH (for example when using
"sudo make install").
This patch folds the generation of the C++ header files into the build
of the sixtyfps-cpp crate - via build.rs. By default the headers are
placed in api/sixtyfps-cpp/generated_include but the CMake build
redirects that into the build directory.
Note: Due to the way that corrosion works, cargo is still run when
running "make install", but it's path is absolute and there should not
be any reliance on the PATH environment variable.
The upcoming re-organization of the C++ header generation requires the
use of the CORROSION_ENVIRONMENT_VARIABLES target property, which in
turn requires CMake >= 3.19.
Unfortunately the rtd theme doesn't support the logo url yet in
our setup, so update this svg copy as the original was updated to
remove the space between "Sixty" and "FPS".
Even if SIXTYFPS_BACKEND_GL is set to OFF, we would default to enabling
X11, which translates to enabling the x11 feature, which in turn
implicitly activates the GL backend. In addition, the interpreter Rust
API crate also enables the GL backend in its defeaults.
In order to make it possible to turn off the GL backend, three changes are necessary:
* The default backend no more selects a default :-). Instead the Rust
API crate, Rust interpreter API crate and the CMake project define
the same features and defaults.
* The C++ crate depends on the interpreter without its defaults (which enable GL)
* In CMake the X11 and Wayland features become dependent options, that
are only show in the CMake configure UI if the GL backend is enabled.
This way a GL-disabled build won't also pass --features x11.
This can be reproduced by deleting the last item of the printer queue in the
printer demo.
It is a regression showing up because we now emit the MouseExit event after
the mouse grab as released.
The problem is that we upgrade the weak item, and call geometry() on it.
Calling geometry will re-evaluate the layout cache which will re-evaluate
the model which will result in the component being removed and the cache
entry having less item than expected.
It is ok to simply return 0. for these layout location since the item will
disapear anyway.
Move the sixtyfps::namespace entry into a dedicated C++ integration overview
page. Also duplicate and specialize the instantiation and model bits, which
differ between the compiled code and the interpreter.
Finally, fix the generated C++ docs to not mention that there's a constructor,
instead we generate a constructor function.
The new order is
1. Getting Started
2. C++ / .60 Integration
3. Reference
The second section will host a broader introduction that is currently hiding
in the namespace.
