Add a simple `ApplicationHandler` trait since winit is moving towards
trait based API. Add `run_app` group of APIs to accept `&mut impl
ApplicationHandler` deprecating the old `run` APIs.
Part-of: https://github.com/rust-windowing/winit/issues/3432
Creating window when event loop is not running generally doesn't work,
since a bunch of events and sync OS requests can't be processed. This
is also an issue on e.g. Android, since window can't be created outside
event loop easily.
Thus deprecate the window creation when event loop is not running,
as well as other resource creation to running event loop.
Given that all the examples use the bad pattern of creating the window
when event loop is not running and also most example existence is
questionable, since they show single thing and the majority of their
code is window/event loop initialization, they wore merged into
a single example 'window.rs' example that showcases very simple
application using winit.
Fixes#3399.
Lifetimes don't work nicely when dealing with multithreaded environments
in the current design of the existing winit's event handling model, so
remove it in favor of `InnerSizeWriter` fences passed to client, so they
could try to update the size.
Fixes#1387.
The idea that redraw events are dispatched with a specific ordering
that makes it possible to specifically report when we have finished
dispatching redraw events isn't portable and the way in which we
dispatched RedrawEventsCleared was inconsistent across backends.
More generally speaking, there is no inherent relationship between
redrawing and event loop iterations. An event loop may wake up at any
frequency depending on what sources of input events are being listened
to but redrawing is generally throttled and in some way synchronized
with the display frequency.
Similarly there's no inherent relationship between a single event loop
iteration and the dispatching of any specific kind of "main" event.
An event loop wakes up when there are events to read (e.g. input
events or responses from a display server / compositor) and goes back
to waiting when there's nothing else to read.
There isn't really a special kind of "main" event that is dispatched
in order with respect to other events.
What we can do more portably is emit an event when the event loop
is about to block and wait for new events.
In practice this is very similar to how MainEventsCleared was
implemented except it wasn't the very last event previously since
redraw events could be dispatched afterwards.
The main backend where we don't strictly know when we're going to
wait for events is Web (since the real event loop is internal to
the browser). For now we emulate AboutToWait on Web similar to how
MainEventsCleared was dispatched.
In practice most applications almost certainly shouldn't care about
AboutToWait because the frequency of event loop iterations is
essentially arbitrary and usually irrelevant.
Considering the possibility of re-running an event loop via run_ondemand
then it's more correct to say that the loop is about to exit without
assuming it's going to be destroyed.
* fix clippy lints on Windows
* fix lints on other platforms
* a couple more
* again
* don't know what's goging on anymore
* fix examples
* comon
* how about now?
* this is getting annoying
* hmmm
* explicitly set a type
* 😢
* don't cast on x64 targets
* apply code review requests
* fix attributes on expressions
* fix ios
* Only build, but don't run tests in MSRV CI
Since the MSRV of development dependencies can easily be bumped without it affecting the MSRV of the published version of `winit`
* Run clippy on stable Rust instead of MSRV Rust
clippy inspects the `rust-version` field, and only suggests changes that conform to that.
To be more consistent with mobile platforms this updates the Windows,
macOS, Wayland, X11 and Web backends to all emit a Resumed event
immediately after the initial `NewEvents(StartCause::Init)` event.
The documentation for Suspended and Resumed has also been updated
to provide general recommendations for how to handle Suspended and
Resumed events in portable applications as well as providing
Android and iOS specific details.
This consistency makes it possible to write applications that lazily
initialize their graphics state when the application resumes without
any platform-specific knowledge. Previously, applications that wanted
to run on Android and other systems would have to maintain two,
mutually-exclusive, initialization paths.
Note: This patch does nothing to guarantee that Suspended events will
be delivered. It's still reasonable to say that most OSs without a
formal lifecycle for applications will simply never "suspend" your
application. There are currently no known portability issues caused
by not delivering `Suspended` events consistently and technically
it's not possible to guarantee the delivery of `Suspended` events if
the OS doesn't define an application lifecycle. (app can always be
terminated without any kind of clean up notification on most
non-mobile OSs)
Fixes#2185.
Co-authored-by: Marijn Suijten <marijns95@gmail.com>
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* Add exit code to control flow and impl on linux
* Fix examples to have an exit code
* Fix doc examples to use an exit code
* Improve documentation wording on the exit code
* Add exit code example
* Add exit code on windows
* Change i32 as exit code to u8
This avoids nasty surprises with negative numbers on some unix-alikes
due to two's complement.
* Fix android usages of ControlFlow::Exit
* Fix ios usages of ControlFlow::Exit
* Fix web usages of ControlFlow::Exit
* Add macos exit code
* Add changelog note
* Document exit code on display server disconnection
* Revert "Change i32 as exit code to u8"
This reverts commit f88fba0253b45de6a2ac0c3cbcf01f50503c9396.
* Change Exit to ExitWithCode and make an Exit const
* Revert "Add exit code example"
This reverts commit fbd3d03de9c2d7516c7a63da489c99f498b710df.
* Revert "Fix doc examples to use an exit code"
This reverts commit daabcdf9ef9e16acad715c094ae442529e39fcbc.
* Revert "Fix examples to have an exit code"
This reverts commit 0df486896b8d106acf65ba83c45cc88d60d228e1.
* Fix unix-alike to use ExitWithCode instead of Exit
* Fix windows to use ExitWithCode rather than Exit
* Silence warning about non-uppercase Exit const
* Refactor exit code handling
* Fix macos Exit usage and recover original semantic
* Fix ios to use ExitWithCode instead of Exit
* Update documentation to reflect ExitWithCode
* Fix web to use ExitWithCode when needed, not Exit
* Fix android to use ExitWithCode, not Exit
* Apply documenation nits
* Apply even more documentation nits
* Move change in CHANGELOG.md under "Unreleased"
* Try to use OS error code as exit code on wayland
* web: Allow event to be queued from inside the EventLoop handler
The Runner is behind a RefCell, which is mutably borrowed when the event
handler is being called. To queue events, `send_events` needs to check
`is_closed()` and the `is_busy` flag, but it cannot be done since the
RefCell is already locked. This commit changes the conditions to work
without needing a successful borrow.
* web: Emit WindowEvent::Resized on Window::set_inner_size
* Update changelog
* web-sys: Impl. event listeners removal for canvas
* web-sys: Impl. media query listeners cleanup
* web: Emit WindowEvent::Destroyed after Window is dropped
* web-sys: Fix unload event closure being dropped early
* web: Impl. cleanup on ControlFlow::Exit
- Drops the Runner, which causes the event handler closure to be
dropped.
- (web-sys only:) Remove event listeners from DOM.
* web: Do not remove canvas from DOM when dropping Window
The canvas was inserted by the user, so it should be up to the user
whether the canvas should be removed.
* Update changelog
* Change web backend `event_handler` to without 'static lifetime
* Refactor web runner and fix ControlFlow::Exit not being sticky
* Impl. scaling change event for web-sys backend
* Improve `dpi` docs regarding the web backend
* Add changes to changelog
* Update features.md
* Use requestAnimationFrame for polling wasm
* Implement `requestAnimationFrame` for stdweb
Co-authored-by: Ryan G <ryanisaacg@users.noreply.github.com>
The current implementation of the event loop runner has some significant
problems. It can't handle multiple events being emitted at once (for
example, when a keyboard event causes a key input, a text input, and a
modifier change.) It's also relatively easy to introduce bugs for the
different possible control flow states.
The new model separates intentionally emitting a NewEvents (poll
completed, wait completed, init) and emitting a normal event, as well as
providing a method for emitting multiple events in a single call.
