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.
Fix warning in the rust generated code about unused global.
After constant propagation, some uses of the global disapear, so we should
re-check which globals are really used
The main thing here is that the Component are in different data structure
depending on whether they are sub-component global component or repeated component
Then the properties at are the right place and there will be no more lookup
in the base. The PropertyReference knows how to access which property via which
element and such.
The idea is that it will be easier to lower from this representation than
what we currently do in each language backend.
This commit is still WIP, it is far from finished
The Tab currently doesn't do anything with the focus, but this
serves as a workaround for #798 so that inner widget of a tab can't
keep the focus when they are hidden
cc #798
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;-)
So that inlining don't merge the states
Since we need to apply default property before the states, we also needed
to move that.
But ensure_window can't be moved before the focus stuff that can't be move
before inlining, so set the default property of the Window in the ensure_window
pass
Fixes#752
* fixed typo in image.rs
* unnecessary repeated words in sixtyfps_runtime
* unnecessary repeated words in sixtyfps_compiler
* unnecessary repeated word in docs
* unnecessary repeated words in helper_crates
Opacity, visible and shadows on repeated elements work by replacing the
root element with a new element (opacity, visible clip, etc.) and making
the old one a child.
A tree like this
```
l := VerticalLayout {
for i in 1: Rectangle {
background: green;
opacity: 0.2;
}
}
```
is lowered like so (pseudo):
```
l := VerticalLayout {
for i in 1: Opacity {
opacity <=> r.opacity;
r := Rectangle {
background: green;
opacity: 0.2;
y: layout_cache[i].y;
width: l.width;
height: layout_cache[i].height;
}
}
}
```
and when rendering, it's important that the opacity of the Opacity
element is applied on the item renderer before rendering the Rectangle
r.
The Opacity element has no width/height because the default geometry
pass won't apply that to children of a layout.
Without a geometry, the item rendere will not call render() (no
intersection with the current clip), and thus the opacity is not
applied.
The shadow lowering pass handles this correctly, by moving the geometry
property bindings to the new root and letting the default geometry pass
apply 100% defaults (in the above "r" is not a layout child).
This patch moves this logic into the common
inject_element_as_repeated_element, so that we end up with a lowering
like this (after the default geometry pass):
```
l := VerticalLayout {
for i in 1: op := Opacity {
opacity <=> r.opacity;
width: l.width;
height: layout_cache[i].height;
y: layout_cache[i].y;
r := Rectangle {
background: green;
opacity: 0.2;
width: op.width;
height: op.height;
}
}
}
```
The opacity on a rectangle should be applied before the shadow, so that it has
a visible effect.
This is a partial fix for #714 but needs also #725 to be entirely visually correct.
On Windows 10, the creation of symlinks by normal users requires
enabling the developer mode, which may or may not be acceptable in
corporate environments with restricted IT setups.
We introduced the symlinks for the shared special key codes mapping,
which instead this patch places into a shared sixtyfps-common crate.
This change the current item, but doesn't scroll the view yet to
make sure it is visible. We are missing the ability to know the
position of the visible item to be able to do that
Share the code that defines the key with a macro over all the backends using
a symlink.
This is a symlink rather than exposing the macro directly since we add this
module in every backend, and each backend re-declares the macro to handle
the part that it needs. This needs to be a symlink because it will also be shared
with the compiler that does not depends on sixtyfps-corelib
