Use the system's mechanisms for pumping events, namely
`nextEventMatchingMask:untilDate:inMode:dequeue:`. This still has a few
problems as detailed in the documentation for `pump_app_events` (which
is why we switched away from it all the way back in Winit v0.20), but it
doesn't have nearly as many problems as the current implementation does.
This allows the user more control over how they pass their application state
to Winit, and will hopefully allow `Drop` implementations on the application
handler to work in the future on all platforms.
Let the users wake up the event loop and then they could poll their
user sources.
Co-authored-by: Mads Marquart <mads@marquart.dk>
Co-authored-by: daxpedda <daxpedda@gmail.com>
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.
* Use icrate's window structs and enums
* Properly implement protocols
* Use icrate's NSWindow
We were previously using undocumented methods on `NSWindowTabGroup`
* Use icrate's NSApplication
And clean up some doc comments regarding NSApplication
Inner panics could make it hard to trouble shoot the issues and for some
users it's not desirable.
The inner panics were left only when they are used to `assert!` during
development.
This reverts commit 9f91bc413fe20618bd7090829832bb074aab15c3 which
reverted the original patch which was merged without a proper review.
Fixes: #500.
Inner panics could make it hard to trouble shoot the issues and for some
users ints not desirable.
The inner panics were left only when they are used to `assert!` during
development.
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.
This renames all internal implementations of pump_events_with_timeout
to pump_events and makes them public.
Since all platforms that support pump_events support timeouts there's
no need to have a separate API.
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`
The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.
The notable use cases we have are:
1. Applications want to be able to implement their own external
event loop and call some Winit API to poll / pump events, once
per iteration of their own loop, without blocking the outer,
external loop. Addressing #2706
2. Applications want to be able to re-run separate instantiations
of some Winit-based GUI and want to allow the event loop to exit with
a status, and then later be able to run the loop again for a new
instantiation of their GUI. Addressing #2431
It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`
The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android
These extensions aren't compatible with Web or iOS though.
Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)
Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`
For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.
This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
