* Move platform-specific documentation to `winit::platform` module
* Document cargo features in crate docs
* Move version requirements to crate-level docs
Given that `ModifiersChanged` is a window event, it means that clients
may track it for each window individually, thus not sending it between
focus changes may result in modifiers getting desynced on the consumer
side.
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`.
While there's a separate event to deliver modifiers for keyboard,
unfortunately, it's not even remotely reflects the modifiers state.
Thus use events along side regular modifier updates to correctly
detect the state. Also, apply the modifiers from the regular
key event by converting their state to xkb modifiers state.
Links: https://github.com/alacritty/alacritty/issues/7549Closes: #3388
We could fail to setup property watcher and fail to start, thus
don't require XSETTINGS to work.
Fixes: df8805c0 (On X11, reload DPI on _XSETTINGS_SETTINGS)
This fixes an issue when setting the position of the window on a new monitor and immediately maximizing it
```rs
window.set_outer_position::<PhysicalPosition<u32>>((2000, 200).into());
window.set_maximized(true);
```
Due to the nature of the event loop, the requested position and maximization state will apply correctly but due to the fact that the new position is a different monitor, a `ScaleFactorChanged` is emitted afterwards to the evenloop and a new size is set while the window is still maximized which results in a window that has `WS_MAXIMZE` window style but doesn't cover the whole monitor.
Given that we merge all the seats, we should consider that window
is not focused once all seats wl_keyboards are no longer present.
We use seats instead of keyboards to track focus to protect against
wl_keyboard::leave not being delivered when removing the seat
(usually it's not the case though).
Fixes: #3376
This also fixes the deadlock when such reload may happen.
Fixes: #3383
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: Kirill Chibisov <contact@kchibisov.com>
Change in state requires a redraw, however drawing when getting
`Occluded` with vsync will block indefinitely, thus the event in
it's current state is rather useless.
To solve this issue winit needs a way to determine whether the user
paused/continued their render loop, so it can commit on their behalf.
This commit also forces redraw when getting configure.
Links: https://github.com/rust-windowing/winit/issues/3442
We use softbuffer as a dev-dependency for rendering into our windows in
examples. However, we do not support a DRM/KMS backend yet, while
softbuffer comes with a DRM/KMS backend by default. This commit removes
the DRM/KMS feature from softbuffer to save some build time during
testing
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
