The event loop roughly loops like this:
loop {
update_timers_and_animations();
render();
sleep_or_dispatch_events();
}
sleep_or_dispatch_events() will wake up when we receive a queued callback from invoke_from_event_loop, and we would
run the callback right away. If that callback sets animated properties, the start time for animations would be incorrect, as we haven't called update_timers_and_animations() yet.
So instead, let's keep track of any received callbacks per sleep cycle, update the animation tick, and then invoke the callbacks.
We call set_fullscreen(None) on startup for windows that aren't fullscreen (normally), and winit compiled for the web unconditionally calls canvas.exitFullscreen(), which
may produces warnings about exitFullscreen()
being called when not in fullscreen mode.
We want the previewer to become interactive, so we need to pass on the
document versions so we can detect the editor, lsp and previewer going
out of sync.
Add helper functions into a new `element_catalog` module that extract
information on components used in a piece of Slint code on the LSP side
of the LSP.
Eventually this information will be passed on to the Preview side and
can then be used there to show available components.
When a component declares an init callback as well as the element that
instantiates it, the init callback of the container would not
get invoked if the container was inlined:
```
component InlinedContainer {
init => { ... } // not invoked
@children // force inlining
}
component UseSite {
InlinedContainer {
init => { ... }
}
}
```
That's because the inlining happens very early, before the init
callbacks are collected into the init code. And during inlining that
would be treated like a property binding and the "binding" at the
element site overrides the one at the component site.
One natural approach would be to move the init code collection to an
earlier place before inlining, but that isn't possible because the
boundaries of the compiler components (Rc<Component>) aren't set
up yet (repeated component extraction phase happens much later).
An alternative would be to re-introduce the init callback code in
ElementRc and place it in there at *::from_node() time.
This patch chooses to solve this at the inlining time: When we're in the
first phase of the inlining (the optional one), do what
with the init binding what collect_init_code would do later: Move it
straight into the init_code of the component we're inlining into.
Fixes#4317
We trigger update_timers_and_animations() every time the event loop wakes up.
If there's a real animation in the UI going on, that'll also trigger a
request_redraw() call and all will be well.
But when the only source of animation is set_has_active_animations() from
RenderingMetricsCollector, then we might end up in a situation where the event
loop is woken up before the rendered frame is on the screen, which means we
invoke update_timers_and_animations(), but we won't render because the
previous frame isn't shown yet. When it is shown and our presentation callback
is invoked, has_active_animations() is false again.
So instead, remember if we need to re-render once after rendering()
and use that to decide if we need to re-render in the presentation callback.
Change the double-click implementation to send after two click events
were sent first.
This gets rid of the wait when a double-click handler is installed
before delivering the click.
Move the set_fullscreen function added to the WindowAdapter trait in 779aff0b39
to be a function in WindowProperties instead.
That way it'll be easier in the future to extend this with other window states without
having to modify or break the WindowAdapter trait API.
Try installing the Android API level 30 without sudo, as
that appears to sometimes fail with
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
Amends 2efd2bc3c8
I get warnings about unused members using the nightly compiler, one for
each member in all structs that derive the `FieldOffsets` macro. That is
a lot.
This fixes that as well as the one occurrence of that same warning in
unrelated code.