A model property such as
property <[Foo]> model: [ ... ];
would create a VecModel in Rust and C++, which in turn can be written to
with an array index expression in .60. If the same .60 code was running
in the interpreter, a Value::Array would be created instead. We don't
support writing into Value::Array by index because we don't have
tracking in place for that, to update dependent bindings.
To fix this inconsistency, this patch changes the interpreter to
allocate a mutable VecModel as well.
Change Model::row_data to return an Option<T> (rust) or std::optional<T> (c++)
Co-authored-by: Olivier Goffart <olivier@woboq.com>
Co-authored-by: Simon Hausmann <hausmann@gmail.com>
The ffi function wrapper need to be changed because in the 2021 edition, when
the capture is moved into the closure, it moves the individual field instead
of the whole wrapper. But we need to move the whole wrapper because the Drop
of the wrapper will delete the C++ closure, and we don't want to call the
closure after it is deleted.
Use the reuse tool to get a better grip on licenses used in sixtyfps.
Fix a couple of licenses along the way.
* Uses creative commons for our own logo (commercial use!)
* Fixes some license information found in README files and documents
them with proper .license files.
* Document Apache/MIT for helper_crates/const-field-offset which matches
what its documentaion site says it uses.
* Add a list of licenses that apply to crates we publish and the tooling
we have.
This patch only adds static information and does not contain any tooling
support.
* Move the C++ elements back into private_api (despite being generated), so that struct_name_to_tokens can generate the right name in re_exports
* When generating the llr_Expression::Struct for the path elements, make sure
that all fields are filled out, to avoid an empty value expression in Expression::Struct
in the Rust generator. Since we don't generate tuples but a named struct, we must provide all fields.
This patch takes care of the lowering of events/coordinates arrays as
path data, which originates from a `commands: ...` string of SVG path
commands.
In order to minimize the path specific code in the generator, the
compile_paths now generates a Vec<Expression> for the events and
coordinates.
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.
