Remove the `application` infix from `register_application_font`, to
reduce the changes that it might be interpreted to be a function that
also changes the default font in all text elements.
Have a function first called before the children, and then the main function
called after the children if they did not accept the event. This will allow
processing the Flickable gesture properly
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.
Remove the pos parameter to the render functions and instead let
the item renderer apply the transformation on the rendere (femtovg
canvas or QPainter).
So `draw_*` functions in the backend now always operate in item local
coordinates.
I'm getting tired of copy & pasting temporarily the same wasm bindgen
snippet and then deleting it again,
or loosing time by accidentally using eprintln! when debugging a wasm
issue.
Don't use the item's rendering cache to determine the image size, as
that's soley for rendering. The Qt backend doesn't use the item cache
and the GL backend neither after this change. Instead both backends have
a cache for decoded images.
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.
There are two problems that this patch fixes:
* It may happen that the image is not loaded yet, which means
we need to wait with the colorization effect instead of colorizing
the dummy (1x1) texture.
* It may happen that we transition from a regular image to one
that has a valid colorization brush, in which case we need to
invalidate the graphics item cache.
Use only specific lyon packages instead of pulling all of them in.
This slightly speeds up compilation as well as for example lyon_tesselation
doesn't need to be compiled anymore.
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,
}
```
This allows filling glyphs with gradients. However femtovg
appears to apply the start/end position per-glyph
instead of globally - resulting in a different result than Qt.
