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.
Add support for built-in property aliases and rename `color` to
`background` - in preparation for it also changing to type brush.
Right now the alias is silent, a deprecation and overall change
will come in a subsequent change.
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
Fold CharacterInput into KeyPressed/KeyReleased and store the "key" as a string.
Also, instead of exposing the KeyCode we're encoding special characters
into the string.
For all other items the default is the empty size.
This also required three fixes for the HTML image loading:
* The upload_pending property value was inverted, it needs to start
out as true (pending yes) and be set to false when it finished
loading (not pending anymore)
* Mark the upload_pending property as dirty before scheduling the
redraw, in case it's sync
* Pass the item rendering cache to the image_size function to ensure
that the Rc<CachedImage> is not only weak inside the image_cache
of the GLRendererData but also strong on the item.
This means going back to an immutable renderer reference and interior
mutability for the canvas and the gpu cache. This is because while
traversing the item tree for rendering we may end up destroying
other items due to the lazyness of the models.
This is the start of a different rendering abstraction, the result of a
separate discussion.
The objective is to provide a better backend encapsulation, that will
make it easier to implement other backends and let the backend decide
what to cache and what not. This is done by passing the struct with the
Property<> fields directly to the backend, so that it can decide what
the cache and what to use every time.
