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.
This allows implementing another sliding puzzle theme feature, the
boldness of the tile number text in the simple theme when the tile is in
the correct position. For the other themes the weight is constant and
it's bold.
More cleanup to follow later: unify the font handle and FontCacheKey
handling, improve the API to allow for the use of symbolic constants
(normal, bold, etc.) instead of the CSS number values.
Group all fields we need to determine a physical font into one FontRequest
structure and use that throughout.
That way adding more fields will require less changes.
To make adding of more font related properties easier in the future, and
to simplify the text code a little, define a HasFont trait and implement
it for Pin<&Text|&TextInput> so that we can more easily get an Rc<Font>.
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.
Draw rounded rectangles using a distance function. This removes the need
to use lyon to tesselate the rounded corners and as a bonus it gives
anti-aliased borders.
Similar to the mouse_grabber, we use a VisitChildrenResult field to
track the focus item within a component. Unlike the mouse grabber
however, it is set/cleared using dedicated focus events.
The key event now routes the key event directly to the focus item.
The focus can be requested via set_focus_item on a window, which the
TextItem does.
In the future the TextInput will request focus on mouse click,for
example.
Pass the outer-most component through to ItemVTable's input_event.
For the purpose of disambiguating this component from any nested
component instantiated by a repeater or so, it's called the
app_component.
The ComponentVTable takes a reference to a ComponentRefPin instead of a
ComponentRefPin by value, as the vtable macro gets confused otherwise
and thinks it's a self argument.
