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.
Similar to the issue fixed in commit
de74ae4534, clang appears to assume that
the float literal is a double our object literals and aggregate
initialization to float members (like the level of InkLevel) requires an
explicit cast.
I don't know of a way to determine the type of a struct field by index easily,
so this build fix instead uses C++17 destructuring to initialize the fields by index.
So
InkLevel{ std::get<0>(o), std::get<1>(0) }
(^^ fails when get returns double and
field is float)
becomes
InkLevel s; auto& [f1, f2] = s; f1 = std::get<0>(o); f2 = std:get<1>(o); return s;
We support directly nested layouts, but we did not support indirect
nesting:
GridLayout {
Rectangle {
l2 := GridLayout { ... }
}
}
This patch fixes that by detecting this scenario and merging the layout
info of the element (Rectangle) and the layout inside (l2). This makes
it much easier to create re-usable components that use layouts
themselves and allows placing them in layouts.
Since Doxygen can't seem to just exclude them via command, they are moved
into a private_api namespace and then excluded via Doxygen config:
* *VTable
* make_dyn_node, ItemTreeNode, etc.
* VersionCheck
This does not actually merge so much but it is better than nothing.
I was not able to merge the code from the interpreter because of the life time issues
Instead, pass a reference to the root item when mapping the window,
at which point we can downcast to the new Window item. If we have one,
then we'll read its width/height (for initial values) and install
bindings to keep them up-to-date.
The compiler complains that intptr_t is not the same type as "long long".
The "long long" originates from "pub struct VisitChildrenResult(i64);"
and I suppose the compiler is right for potential 32-bit architectures. So
let's use int64_t as counter-part to i64.
