* Move platform-specific documentation to `winit::platform` module
* Document cargo features in crate docs
* Move version requirements to crate-level docs
Replace the `CustomCursorBuilder` with the `CustomCursorSource` and
perform the loading of the cursor via the
`EventLoop::create_custom_cursor` instead of passing it to the builder
itself.
This follows the `EventLoop::create_window` API.
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.
Mainly fix typos in comments, but also some minor code changes:
* Rename `apply_on_poiner` to `apply_on_pointer`.
* Rename `ImeState::Commited` to `ImeState::Committed`
* Correct `cfg_attr` usage: `wayland_platfrom` -> `wayland_platform`.
This let statement swapped the two names, resulting in incorrect
behavior since commit d7ec899d. That commit did not actually introduce
the swap, but the previous code swapped it again before setting the
WM_CLASS property, so no issue was ever observed.
It also brings the documentation in line with the implementation since the
parent commit, and with the ICCCM standard, which states the following
about the WM_CLASS property [1]:
The two strings, respectively, are:
* A string that names the particular instance of the application [...]
* A string that names the general class of applications [...]
[1] https://www.x.org/releases/current/doc/xorg-docs/icccm/icccm.html#WM_CLASS_Property
* 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
* Refactor winit-specific cursor logic out of appkit module
* Add relevant AppKit features that we depend on
* Use icrate's NSImageRep and NSBitmapImageRep
* Use icrate's NSImage
* Use icrate's NSCursor
* Use icrate's NSAppearance
* Use icrate's NSScreen
* Use icrate's NSButton
* Use icrate's NSAppKitVersionNumber
* Use icrate's NSTextInputContext
* Use icrate's NSColor
* Use icrate's NSEvent
* Use icrate's NSMenu and NSMenuItem
* Use icrate's NSPasteboard
* Use icrate's NSResponder
* Use icrate's NSTextInputClient
* Use icrate's NSView
There seems to be many PRs relating to this issue, but they don't include all
platforms and for some reason lost steam. This PR again tries to make this
feature happen, and does it for all desktop platforms (x11, wayland, macos,
windows, web).
I think the best user of this feature and the reason I'm doing this is Bevy and
game engines in general. There non laggy hardware cursors with custom images are
very important. Game devs also like their PNGs so supporting platform native
cursor files is not that important, but I guess could be added too.
Co-authored-by: daxpedda <daxpedda@gmail.com>
Co-authored-by: Mads Marquart <mads@marquart.dk>
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
Split `Key` into clear categories, like `Named`, `Dead`, Character`, `Unidentified`
removing the `#[non_exhaustive]` from the `Key` itself.
Similar action was done for the `KeyCode`.
Fixes: #2995
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
Window builder is always accessed by winit on the thread event loop
is on, thus it's safe to mark the data it gets as `Send + Sync`.
Each unsafe object is marked individually as `Send + Sync` instead
of just implementing `Send` and `Sync` for the whole builder.
They are safe, since they use the rust `std::env` stuff. Making them
safe lets downstream to determine that `std::env` is used and not the
`libc` env manipulation routines, which are unsafe.
* macOS & iOS: Refactor EventWrapper
* macOS & iOS: Make EventLoopWindowTarget independent of the user event
* iOS: Use MainThreadMarker instead of marking functions unsafe
* Make iOS thread safe
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.
At the moment, the with_x11_visual function takes a pointer and
immediately dereferences it to get the visual info inside. As it is safe
to pass a null pointer to this function, it is unsound. This commit
replaces the pointer parameter with a visual ID, and then uses that ID
to look up the actual visual under
the X11 setup. As this is what was already practically happening before,
this change shouldn't cause any performance downgrades.
This is a breaking change, but it's done in the name of soundness so it
should be okay. It should be trivial for end users to accommodate it,
as it's just a matter of getting the visual ID from the pointer to the
visual before passing it in.
Signed-off-by: John Nunley <dev@notgull.net>
Nothing changed from the user point of view, other than they should
use the `raw-window-handle`, which is objectively better, given that
it reduces the amount of `cfg` guards in downstream code.
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.
