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.
While visit_items/visit_internal allows an isize index (because of -1 to indicate the root),
the callback should always take a valid item index, thus usize.
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.
Move the layout constraint tracker into the window where we can apply
the constraints right before drawing, instead of doing that from within
the event loop. This allows to remove the component parameter from the
run function.
In the rendering backend we cache glyphs indexed by the *actual* font
used. The key is a font_kit::handle::Handle, which can be either a Path
or a Memory buffer. We eventually load the font into memory, so we get
a font_kit::font::Font and pass that around. When the time comes to get
a key for the hash, we create a new handle from font_kit::font::Font via
handle(), which no more has its path and always creates a memory handle,
causing us to always compute a hash over the font in memory
(*facepalm*). So let's keep the original handle around as font_kit
produces a Handle::Path, which is much faster to hash.
