The scale factor being sent when the only monitor is disconnected and
reconnected is hard coded to 1.0. That may work by chance, if that's the
scale factor in use currently, but it does not work in the general case.
As a result, clients may end up with wrongly scaled or laid out window
contents after reconnect, as was reported over in
https://github.com/alacritty/alacritty/issues/5703, for example.
The problem was introduced by change 125ee0b, which caused an additional
ScaleFactorChanged event to be sent on monitor reconnect, but got the
scale factor wrong when the only monitor is disconnected and
reconnected.
This change fixes the problem by using the current monitor's scale
factor in this case. The event is still being sent as intended by
125ee0b.
Fixes#2123.
* Use NSView's inputContext instead of creating our own
This means that `set_ime_position` now properly invalidates the character coordinates.
* Make `set_ime_position` robust against moving windows
If you try to use `EventLoop::run_return` API in a way that you do on
demand polling of events it won't actually poll, since in such strategy
the `ControlFlow::Exit` is sent right before Wayland backend starts to
poll.
This was observed with smithay compositor Anvil which was doing this
particular thing leading to GNOME thinking that app isn't responding,
due to connection not being polled.
This commit adds an `EventLoopBuilder` struct to simplify event loop
customization and providing options to it upon creation. It also
deprecates the use of `EventLoop::with_user_event` in favor of the same
method on new builder, and replaces old platforms specific extension
traits with the new ones on the `EventLoopBuilder`.
* Update changelog guidelines to prevent conflicts from blocking PRs
As per consensus in https://github.com/rust-windowing/winit/issues/2135
* Add note about whitespace in changelog
* Add note about maintainer creating new tag
* 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
See also https://github.com/rust-windowing/winit/pull/1626.
The `cocoa` crate links to AppKit, which made the symbol `CGDisplayCreateUUIDFromDisplayID` from ApplicationServices/ColorSync (which AppKit uses internally) available to us on macOS 10.8 to 10.13.
However, this does not work on macOS 10.7 (where AppKit does not link to ColorSync internally). Instead of relying on this, we should just link to ApplicationServices directly.
* Add cursor grab
* Update feature matrix, changelog and platform information
* Add proper error propagation
* Remove "expect" from fallible code
code would crash if handling pointer capture outside of winit on
every mouse click
we swallow the error since we could not think of a case where this
would fail in a way that would want to handle that it fails
* Remove unnecessary implementation comment
Co-authored-by: Will Crichton <wcrichto@cs.stanford.edu>
Maybe the transparent setting in WM_NCCREATE on Windows 11 will cause a block when calling DwmEnableBlureBehindWindow and will crash. Puts them into WM_CREATE and it works.
This reverts commit 8afeb910bd.
Reverting because this change made Pinyin input unusable
(only latin characters showed even after selecting the
desired Chinese character)
* In MacOS, only disable menu bar in exclusive fullscreen
* Save and restore fullscreen options in set_fullscreen
* Don't always cache presentation options when entering exclusive fullscreen
This commit caches presentation options when entering exclusive fullscreen
only if we're coming from borderless fullscreen.
Then, when transitioning from exclusive -> borderless, if no cached presentation
options are present, then the default borderless options are applied.
This fixes the menu bar being unavailable when taking the following path:
[not fullscreen] -> [exclusive fullscreen] -> [borderless fullscreen].
Without this commit, the presentation options from [not fullscreen] were being
cached and then applied to [borderless fullscreen].
* Restore the window level when switching to exclusive fullscreen
The hack of using `CGShieldingWindowLevel() + 1` in borderless fullscreen needs
to be undone when switching from [borderless] -> [exclusive] fullscreen,
otherwise there are menu bar glitches when following a path through
[borderless] -> [exclusive] -> [borderless] modes.
Now, this might appear to conflict with the 'always on top' feature which uses
the 'floating window' level, but this feature appears to be broken anyway when
entering and exiting fullscreen with an always-on-top window. So, rather than
introducing logic to attempt to restore to the 'floating' level here, I think
it's better to do the simple thing for now and then introduce logic for
always-on-top windows when fixing the overall fullscreen behaviour.
* Update the changelog
Co-authored-by: Ehden Sinai <ehdens@gmail.com>
Co-authored-by: Francesca Lovebloom <francesca@brainiumstudios.com>
* macOS: Ignore all events while in the callback
Previously all native dialogs, such as [rfd](https://github.com/PolyMeilex/rfd), would cause the event loop (event_loop.run) to freeze.
* Update changelog
* spelling
* Fix merge mistake
* Add link to issue in the code
Co-authored-by: Poly <marynczak.bartlomiej@gmail.com>
While winit was always using dlopen for opening system libs, it
provides a way now to disable dlopen feature helping with linking
on some targets.
Fixes#2037.
Some video drivers could set display metrics to odd values, which can result in
extra large scale factors (e.g. winit is sending 720 for 5k screen on nvidia
binary drivers), so let's just drop them to prevent clients from using them.
The value 20 was picked, because the DPR for 8k @ 5 inch is ~18.36.
Fixes#1983.
When disconnect the only monitor, scale factor is reset to 1.0. We need
to set it back when the monitor is reconnected.
We previously assume current window must be on an existing monitor, but
that's not true in case of reconnecting the only one monitor.
This commit also drops 'Theme' trait with its support types
in favor of 'FallbackFrame' meaning that winit will use some
predefined frame for the time being, since porting 'ConceptFrame'
will require adding font rendering librarires right into winit,
which is not desired.
Fixes#1889.
Fixes#1488.
`is_key_down` was only set to true when `insertText` was called.
Therefore `is_key_down` was actually meant to store whether the most
recently pressed key generated an `insertText` event, at which, winit
produces a `ReceivedCharacter`. The issue is that `insertText` is *not*
called for "key repeat", but winit wants to send `ReceivedCharacter`
events for "key repeat" too. To solve this, the `is_key_down` variable
was then checked in the `key_down` function to determine whether it was
valid to produce repeated `ReceivedCharacter` events during "key
repeat". However this check is not needed since `ReceivedCharacter` must
always be called if the key event has a non-empty `characters` property.
Furthermore `is_key_down` didn't actually store whether the previously
pressed character had an `insertText` event, because it was incorrectly
set to false on every "key up". This meant that if two keys were pressed
consecutively and then the first was released, then `is_key_down` was
set to false even if the most recent keypress did actually produce an
`insertText`.
Update changelog.
