The problem is that the backend is using the `meta_property_listener` to know
if the layout must be updated, but the C++ code would not register a dependency
NOTE about the test: The test doesn't really test that it works because
the test backend don't have a meta_property_listener and apply the layout
inconditionally in sixtyfps_send_mouse_click
This is just a starting point, to be turned into a real Transform
element later, along with syntactic sugar to turn rotation, etc. into a
transform matrix in the generated output.
In the nightly it appears that `no_mangle` is now considered "unsafe",
so we need to allow that in the ffi modules. For the layout code this
patch also creates that ffi module with prefixed function names, like in
the other modules and only allows unsafe in there.
Allow converting a brush to a color. In the case of a gradient, the color of the first stop is returned.
For the C++ generator this requires adding the extra case of explicitly
calling the `Brush(const Color &)` constructor, despite it being implicit,
in order to generate the correct code when we have IR that casts twice:
```
Expression::Cast {
from: Expression::Cast {
from: Expression::Cast {
from: Expression::NumberLiteral(...),
to: Type::Color,
}
to: Type::Brush,
},
to: Type::Color,
}
```
A few changes were required:
* `LinearGradient(LinearGradient)` as enum variant unfortunately
won't compile because the cbindgen generated constructor
function (`LinearGradient()`) will try to also instantiate the
variant type inside (`LinearGradient`) and that won't find the type
but the function itself and error out. So the inner type is now
called `LinearGradientBrush`.
* The same name dance was required for `Color`, where the enum variant
instead is called `SolidColor`
* `BrushInner` was removed in favor of just `Brush`. The nicer Rust
API will be the public variant, and for cbindgen we can just put
the generated enum into an internal namespace, like we do for
Resource for example
* A `NoBrush` variant was added. Maybe that name could be improved?
This intends to provide a configurable rectangular "drop shadow". The
API is modeled after CSS/HTML5 Canvas where the element can be "bound"
to an existing rectangular shape (geometry and radius), the offset can
be used to place the shadow and color and blur configure the shadow.
The shadow's color fades into transparent.
TODO (in subsequent changes):
* Documentation
* Qt implementation
This allows creating multiple windows for example, and it will allow for
showing windows in those tests that require a mapped window.
As a bonus, the run() function on generated components is not consuming
anymore.
Instead of determining the focus item through item tree traversal and
pointer comparison and storing the intermediate indices in the
components in the tree, remember the focus item by a pair of
VWeak<ComponentVTable, Dyn> and item_index: usize.
This speeds up determining the focus item as well as delivering events,
which can now be done directly after retrieving an ItemRef with
get_item_ref.
This also fixes the duplicate line edit focus in the 7gui cells
test case.
This is in preparation for allowing the run-time / items to clone VRc's
of the component.
ComponentVTable functions like visit_children_item contine to take a
ComponentRefPin as "self" parameter type, as a VRc would not be
supported by rust right now. That means the implementation then uses
self_weak to obtain a strong self-reference.
Centralize the self_weak setup to be emitted only once, in the create()
function. create() is now always emitted and equipped with a parent
parameter, for non-root components. This allows slightly simplifying the
generic repeater code.
