Similar to the other window item properties and also similar to how the
Qt backend handles this, fetch the background color in
apply_window_properties().
If the root item is a Window, then we use the default-font-* properties as the basis
for all unspecified font properties in text rendering.
This patch centralizes the code for retrieving that in the runtime window.
If this becomes a performance bottleneck, then we could cache it in a
box-pinned property in the run-time window.
When the window is mapped, the scale factor is brought up-to-date. Only
after that we can receive a resize event or a window scale factor
changed event.
- Have the cursor at the right place when clicking on end of line
- make sure not to render new lines if there are some when in single-line mode
- Enter should make a new line
Remove the internal name again and pick the first exported one when
assigning ids. This avoids internal names showing up in code completion
or the internal types leaking into generated code.
When exporting an global multiple times under different names, make sure
that they alias in the generated code.
As a consequence, the compiler maintains the original unique name and in
Rust and C++ makes only the exported names public. In the interpreter
the internal name is theoretically still accessible from the outside.
since there is only one function in it, just put that function in the Window
then there is no need to heap alocate a dyn FontMetrics just to call this function.
In preparation of having mutiple-lines TextInput, we will need to give more
data to this function so it no longer belong in FontMetrics
Also remove the unused FontMetric::line_height()
Under these windowing systems, we receive a QString text from Qt that
contains a terminal control character (like \u{3} for ctrl+c). We
decided to supply the character for the key (for example 'c' for Ctrl+C)
to the application, so activate the conversion from the key code when
control characters are present.
With winit, we receive first a key down input event with the virtual key
code (for example C for Ctrl+C), followed by a ReceivedCharacter event
with a terminal control character. We choose to ignore that and instead
take the previously received key code and try to use that instead.
Fixes#441
Move the sixtyfps::namespace entry into a dedicated C++ integration overview
page. Also duplicate and specialize the instantiation and model bits, which
differ between the compiled code and the interpreter.
Finally, fix the generated C++ docs to not mention that there's a constructor,
instead we generate a constructor function.
The new order is
1. Getting Started
2. C++ / .60 Integration
3. Reference
The second section will host a broader introduction that is currently hiding
in the namespace.
That's the more typical use-case to also deal with name spaces, where
this is done at import time.
The modified test case tries to ensure that this also works.
