* Add TraceGuard to make tracing simpler
* Add SharedStateMutexGuard to make tracing simpler
* Add trace_scope macro
* Add missing let binding in trace_scope!
* 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)
* examples: Fix unused `Result` that must be used when initializing console_log
* examples: Fix unused imports
* Fix unread name field warning in linux x11 ime InputMethod struct
* Fix unread name field warning in linux x11 Device struct
* Ignore unread field warning in macos/ios MonitorHandle struct
* ci: Add `--deny warnings` to `RUSTFLAGS`
* 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>
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.
* Fix X11 memory leak and remove mio-misc
I also fixed a couple of clippy lints.
Fixes#1984
* Send the redraw event before waking up the main event
* Use .map instead of a match, and remove comments saved by git
* Remove unnecessary pub keywords on `WakeSender` in x11/mod.rs
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.
The inability to set the cursor using any of the named cursor files
likely indicates an error in the system on which we are running.
'WinitPointer::set_cursor' also does not have any way of returning an
error so just log the error to assist users in diagnosing the problem.
Fixes: #1988.
* Enable to show text when IME is active
* Remove unnecessary variable
* Enable to use IME
* fmt
* Remove println! for debug
* Fix handling of utf-8 string
* clear_marked_text should be rust function, not member function
* Store state information in ViewState
* Remove unnecessary function
* format
* Remove mut
* format
* Remove duplicate marked text
* Remove unused `is_preediting` field
Co-authored-by: Artúr Kovács <kovacs.artur.barnabas@gmail.com>
* Remove window subclassing
* Always call `DefWindowProcW` when we don't process a message
* Improve window initialization
Note that the error path in `init` is kind of cursed at the moment.
* Rename `ThreadMsgTargetCallbackData` to `ThreadMsgTargetData`
* Simplify window initialization
* Fix compilation on 32-bit targets
* Simplify the creation of the event target window
* Use `.clone()` rather than `Rc::clone()`
* Use concrete types for args to `SetWindowLongPtrW`
On 32-bit targets, `SetWindowLongPtrW` is an alias to `SetWindowLongW`,
which returns `LONG` (`i32`) rather than `LONG_PTR` (`isisze`).
* Minor comment adjustments
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.
* Drop the event callback before exiting
* Update the changelog
* Apply suggestion from review
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* Apply review suggestions
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* Remove support for `stdweb`
* Expunge `stdweb`; make `web-sys` the default
* Mark this change as a breaking change
* Re-insert accidental removal of space
* Use the correct cargo feature syntax
* Re-add some `cfg` attributes
* Remove `web-sys` feature from CI
* Require setting the activation policy on the event loop
* Run cargo fmt
* Update changelog
* Fixes and tweaks from review
* Correct comment in app_state.rs
Co-authored-by: Mads Marquart <mads@marquart.dk>
* MacOS: Only activate after the application has finished launching
This fixes the main menu not responding until you refocus, at least from what I can tell - though we might have to do something similar to https://github.com/linebender/druid/pull/994 to fix it fully?
* MacOS: Remove activation hack
* Stop unnecessarily calling `makeKeyWindow` on initially hidden windows
You can't make hidden windows the key window
* Add new, simpler activation hack
For activating multiple windows created before the application finished launching
* feat: added MacOS menu
* fix: ran fmt
* extracted function into variable
* idiomatic formatting
* Set the default menu only during app startup
* Don't set the activation policy in the menu init
Co-authored-by: Artur Kovacs <kovacs.artur.barnabas@gmail.com>
This is called internally by NSApplication.run, and is not something we should call - I couldn't find the reasoning behind this being there in the first place, git blame reveals c38110cac from 2014, so probably a piece of legacy code.
Removing this fixes creating new windows when you have assigned a main menu to the application.
We allow to have RunLoop running only on the main thread. Which means if
we call Window::request_redraw() from other the thread then we have to
wait until some other event arrives on the main thread. That situation
is even worse when we have ControlFlow set to the `Wait` mode then user
will not ever render anything.
* Fix for #1850
* Update changelog
* Fix for compilation warnings
* Apply suggestions from code review
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* Improve code quality
* Change Arc<Mutex> to Rc<RefCell>
* Panicking in the user callback is now well defined
* Address feedback
* Fix nightly warning
* The panic info is now not a global.
* Apply suggestions from code review
Co-authored-by: Francesca Lovebloom <francesca@brainiumstudios.com>
* Address feedback
Co-authored-by: Markus Røyset <maroider@protonmail.com>
Co-authored-by: Francesca Lovebloom <francesca@brainiumstudios.com>
* Restore the ability to have fully transparent windows on Windows
Besides its original purpose, commit 6343059b "Fix Windows transparency
behavior to support fully-opaque regions (#1621)" also included some
changes considered cleanups, one of them was:
* Remove the `CreateRectRgn` call, since we want the entire window's region to
have blur behind it, and `DwnEnableBlurBehindWindow` does that by default.
But the original code actually disabled the blur effect for the whole
window by creating an empty region for it, because that allows for the
window to be truely fully transparent. With the blur effect in place,
the areas meant to be transparent either blur the things behind it
(until Windows 8) or are darkened (since Windows 8). This also means
that on Windows 8 and newer, the resulting colors are darker than
intended in translucent areas when the blur effect is enabled.
This restores the behaviour from winit <0.24 and fixes#1814.
Arguably, one might want to expose the ability to control the blur
region, but that is outside the scope of this commit.
* Remove useless WS_EX_LAYERED from transparent windows on Windows
`WS_EX_LAYERED` is not supposed to be used in combination with
`CS_OWNDC`. In winit, as it is currently used, `WS_EX_LAYERED` actually
has no effect at all. The only relevant call is to
`SetLayeredWindowAttributes`, which is required to make the window
visible at all with `WS_EX_LAYERED` set, but is called with full
opacity, i.e. there's no transparency involved at all.
The actual transparency is already achieved by using
`DwmEnableBlurBehindWindow`, so `WS_EX_LAYERED` and the call to
`SetLayeredWindowAttributes` can both be removed.
* Add DeviceEvent::MouseMove on web platform to support pointer lock
* Update changelog
* Add support for stdweb too
* Add mouse_delta to stdweb
* Remove reference to pointer lock
* Link CGDisplayCreateUUIDFromDisplayID through ColorSync instead of CoreGraphics
* Conditionally link through ColorSync only if WINIT_LINK_COLORSYNC is set
to true
* Document new macos env var in README
Following the changes in [1] this bumps ndk and ndk-glue to 0.3 and uses
the new constants. The minor version has been bumped to prevent
applications from running an older winit (without #1826) with a newer
ndk/ndk-glue that does not pass this `ident` through the `data` pointer
anymore.
[1]: https://github.com/rust-windowing/android-ndk-rs/pull/112
The issue was caused by calling SetCapture on a window which already
had the capture. The WM_CAPTURECHANGED handler assumed that it would
only run if the capture was lost, but that wasn't the case. This made
the handler to try to lock the window state mutex while it was already
locked.
The issue was introduced in #1797 (932cbe4).
ndk-glue currently sets both the `ident` field and user-data pointer to
`0` or `1` for the event pipe and input queue respectively, to tell
these sources apart. While it works to reinterpret this `data` pointer
as integer identifier it shouldn't be abused for that, in particular
when one may wish to provide extra information with an event in the
future; then the `data` field is used as pointer (or abused as abstract
value) for that.
This commit forwards "unknown" Wayland mouse buttons downstream via
'MouseButton::Other'. Possible values for those could be found in
<linux/input-event-codes.h>.
Also, since Wayland just forwards buttons from the kernel, which are
'u16', we must adjust 'MouseButton::Other' to take 'u16' instead of
'u8'.
This commit introduces a cross platform way to request a user attention
to the window via a 'request_user_attention' method on a Window struct.
This method is inspired by macOS's 'request_user_attention' method and
thus reuses its signature and semantics to some extent.
* Fix WindowEvent::ReceivedCharacter on web
The event was never sent to the application because of the unconditional
preventDefault() call on keydown.
Fixes#1741
* Don't scroll when pressing space on a focused canvas
After reaching keypress, we should prevent further propagation.
Relates to #1741
Building window with 'set_min_inner_size' was setting 'max_inner_size'
under the hood, thus completely disabling window resize, since
the window isn't resizeable on Wayland when its minimum size
is equal to its maximum size.
