The previous approach of calling send_event on a timer has the disadvantage
or re-entering the event loop for every queued event. Any requested redraw
after one of those events will end up actually drawing, even if that frame could be
replaced by the next event's redraw without being shown to the user.
winit also doesn't expose publicly its web Runner send_events method that would
allow us to queue the events outside and pass them all together.
We can however queue the events inside winit by putting the event loop in
ControlFlow::Poll mode so that winit batches them itself.
This has the side effect of processing and painting those events using
requestAnimationFrame.
To achieve this we take advantage of winit processing send_event calls
synchronously, possibly while on a native event handler, by entering the
event loop just to send WakeEventLoopWorkaround, set the event loop in
Poll mode, exit, and call send_events again with our event which then
ends up being queue in the web event loop's Runner until the next animation
frame where all queued events are processed and redrawn together.
Otherwise the timing code might think at the time of an event (eg key press)
that the starting point of an animation that starts in this event is
earlier in time than it really is. Causing the animation to appear as it
had started earlier or literaly be finished before it starts.
Fixes#1255
Changing the constraint doesn't work on non-rezsizable window.
So first set the window as resizeable, then change the constraints, then
maybe remove the resizable flag
The situation differs depending if the widget show the virtual keyboard or not:
For widget that don't show the virtual keyboard, we rely on the winit events,
but for some reason we don't recieve WindowEvent::ModifiersChanged events with
wasm. Since the event handling in winit is about to be rewriten, I did not
bother reporting the bug upstream, but just work around by using the deprecated
API. So that way shift + tab will no longer be understood as just tab.
For widget using the virtual keyboard, then the event handling is in
wasm_input_helper.rs. There is a couple of issues:
- We must map shift+tab to backtab.
- We need to prevent the default events to trigger, so that tab and other
shortcuts don't take effect on the browser. Winit already inhibit these
events so we must do the same otherwise tab and shift+tab would change the
html focus.
- By luck, tab used to give the focus back to the canvas before (see previous
point) and that's why it worked. But now that we don't do that anymore,
hiding the virtual keyboard should actually re-focus the canvas
- That will cause the focus event to be intercepted by winit, and will cause
recursions and borrow error, so we make sure that we do not recurse when
getting the focus event
Commit c85e1b6d25 added a workaround for a
winit issue, which has been fixed upstream. Until a new release is
available, let's patch in winit from a branch that has the fix
cherry-picked.
This way we don't have to remember to remove the workaround with the
next update and this has been verified on the device.
I only tested on X11 plasma, and there this doesn't have any effect,
But this might be needed because i removed it a few commit ago in another
function.
I think the reason it is there is that it allow changing from a fixed size
to a custom size
When a second canvas is visible, only animations in the first canvas
resulted in updates and visible animation. An animation in the second
canvas wouldn't result in repaints.
When we start an animation, we request a redraw on all windows and
return with `ControlFlow::Poll` to winit.
Winit then schedules an animation frame request, and in the callback the
redraw request events are delivered. For the first window we call
`update_animations()`, a new tick is detected (different than the
previous one) and animated properties are dirty and yield new windows.
Then right away we get called again with a redraw request for the second
window. update_animations() determines that the instant::now() is the
same, and has_animations() returns false. So at the end of the event
handler we return fail to return `Poll` and therefore no animation frame
request is created, which means the animations just stop.
Fix this by calling update_animations() only once, when all input events
have been processed and the redraw events are up for delivery next.
This is visible in the preview canvases in the documentation, if a
canvas other than the first has animations.
cc #215
Handle Input event from the input directly instead of going through winit
for the TextInput.
Note that this doesn't handle the composition event well, so the text is
only considered written when it is accepted
When "combining" information from winit's ReceiveCharacter and
KeyboardInput events, then do not create a second KeyPress event
when the KeyboardInput contained a control character.
This makes us not send duplicate events for `Tab`, but leaves the
handling for e.g. `Ctrl-C` unchanged.
The README.md contains the warning that used to be in lib.rs.
Add README.md files to all internal crates
... pointing to the official public crate to use instead.
Rename internal crates
fixup: README files
fixup rename
