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.
* changed description of window scale factor in Events
* Update src/dpi.rs
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* Fix intra-doc link
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* 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.
This patch removes an unneeded workaround for transparent windows on the
Windows platform. In addition, it simplifies a couple of related API calls:
* Remove the `CreateRectRgn` call, since we want the entire window's region to
have blur behind it, and `DwnEnableBlurBehindWindow` does that by default.
* Remove the `color_key` for `SetLayeredWindowAttributes`, since it's not used
(we're not passing `winuser::LWA_COLORKEY` to the flags).
The initial media query that's used to watch for device pixel ratio
changes should match. Unfortunately it doesn't with Safari and the
corresponding assertion fails. This is because resolution is not a
supported support property for queries. As a workaround, this patch
extends the query to optionally match for the webkit specific DPR
property directly.
This fixes#1734
* Update SCTK to 0.11.0
Updates smithay-client-toolkit to 0.11.0. The major highlight
of that updated, is update of wayland-rs to 0.27.0. Switching
to wayland-cursor, instead of using libwayland-cursor. It
also fixes the following bugs:
- Disabled repeat rate not being handled.
- Decoration buttons not working after tty switch.
- Scaling not being applied on output reenable.
- Crash when `XCURSOR_SIZE` is `0`.
- Pointer getting created in some cases without pointer capability.
- On kwin, fix space between window and decorations on startup.
- Incorrect size event when entering fullscreen when using
client side decorations.
- Client side decorations not being hided properly in fullscreen.
- Size tracking between fullscreen/tiled state changes.
- Repeat rate triggering multiple times from slow callback handler.
- Resizable attribute not being applied properly on startup.
- Not working IME
Besides those fixes it also adds a bunch of missing virtual key codes,
implements proper cursor grabbing, adds right click on decorations
to open application menu, disabled maximize button for non-resizeable
window, and fall back for cursor icon to similar ones, if the requested
is missing.
It also adds new methods to a `Theme` trait, such as:
- `title_font(&self) -> Option<(String, f32)>` - The font for a title.
- `title_color(&self, window_active: bool) -> [u8; 4]` - The color of
the text in the title.
Fixes#1680.
Fixes#1678.
Fixes#1676.
Fixes#1646.
Fixes#1614.
Fixes#1601.
Fixes#1533.
Fixes#1509.
Fixes#952.
Fixes#947.
This changes 'Fullscreen::Borderless' enum variant from
'Fullscreen::Borderless(MonitorHandle)' to
'Fullscreen::Borderless(Option<MonitorHandle>)'. Providing
'None' to it will result in picking the current monitor.
* web: Allow event to be queued from inside the EventLoop handler
The Runner is behind a RefCell, which is mutably borrowed when the event
handler is being called. To queue events, `send_events` needs to check
`is_closed()` and the `is_busy` flag, but it cannot be done since the
RefCell is already locked. This commit changes the conditions to work
without needing a successful borrow.
* web: Emit WindowEvent::Resized on Window::set_inner_size
* Update changelog
* web-sys: Impl. event listeners removal for canvas
* web-sys: Impl. media query listeners cleanup
* web: Emit WindowEvent::Destroyed after Window is dropped
* web-sys: Fix unload event closure being dropped early
* web: Impl. cleanup on ControlFlow::Exit
- Drops the Runner, which causes the event handler closure to be
dropped.
- (web-sys only:) Remove event listeners from DOM.
* web: Do not remove canvas from DOM when dropping Window
The canvas was inserted by the user, so it should be up to the user
whether the canvas should be removed.
* Update changelog
This commit is a follow up to a2db4c0a32
to make it clear which virtual key codes are located on numeric pad.
It also adds Asterisk and Plus virtual key codes.
Certain platforms like Wayland don't have a concept of
primary Monitor in particular. To indicate that
'primary_monitor' will return 'None' as well as in cases
where the primary monitor can't be detected.
Fixes#1683.
On certain platforms window couldn't be on any monitor
resulting in failures of 'current_monitor' function.
Such issue was happening on Wayland, since the window
isn't on any monitor, unless the user has drawn something into it.
Returning 'Option<MonitorHandle>' will give an ability to
handle such situations gracefully by properly indicating that
there's no current monitor.
Fixes#793.
In winit the swipe from left to right on touchpad should
generate positive horizontal delta change, however on
macOS it was the other way around without
natural scrolling.
This commit inverses the horizontal scrolling delta
in 'MouseScrollDelta' events to match other platforms.
Fixes#1695.
* Change web backend `event_handler` to without 'static lifetime
* Refactor web runner and fix ControlFlow::Exit not being sticky
* Impl. scaling change event for web-sys backend
* Improve `dpi` docs regarding the web backend
* Add changes to changelog
* Update features.md
On all platforms other than Linux/X11, the Subtract key was uniformly
used only for the Numpad. To make this cross-platform compatible, the
`-` key will now map to `Minus` on X11 instead of `Subtract`.
Since people have been confused about the difference between `Minus` and
`Subtract` in the past, the `Subtract` key has also been renamed to
`NumpadSubtract`. This is a breaking change that might be annoying to
downstream since there's no direct improvement, but it should help new
users in the future. Alternatively this could just be documented, rather
than explicitly mentioning the Numpad in the name.
* Impl. mouse capturing for web-sys with PointerEvent
* Impl. mouse capturing for web-sys with MouseEvent by manual tracking
* Reorganize web-sys backend mouse and pointer handling code
* Impl. mouse capturing for stdweb with PointerEvent
* Add mouse capturing for web target to changelog
The `_lwp_self` function cannot be used to reliably determine the main
thread, see
https://github.com/alacritty/alacritty/issues/2631#issuecomment-676723289.
It might always be equal to the PID, but it's certainly not always 1
when the thread is the main thread.
However, Rust's built in `Thread::id` and `Thread::name` function will
always return `ThreadId(1)` and `Some("main")`. Since converting the
thread's ID to a number is not supported on stable Rust, checking that
the thread is labeled `Some("main")` seems like the most reliable
option. It should also be a good fallback in general.
PhysicalSize is recorded as canvas.size, whereas LogicalSize is stored
as canvas.style.size.
The previous cursor behavior on stdweb clobbered all style - thus losing
the LogicalSize.
This resolves various problems with the documentation about platform
support on the Window struct.
It also completely removes pointless runtime errors in favor of
consistent no-ops on all platforms that do not support a certain
features.
* macos: Support click-dragging out of a window
* macos: Use NSEvent::pressedMouseButtons for click-dragging
* macos: Click-dragging: Move pressedMouseButtons inside
* Fix for fullscreen with run_return on mac
* Cleanup
* Removed a comment
* fmt
* This doesn't break exiting run_return anymore
* Now you can also transition from code
* Fmt & cleanup
* Now using a atomic instead of a static bool
* reinserted a line
* Fmt
* Added support for dialogs and child windows
* Cargo fmt
* Dialogs are now being shutdown properly
* Cargo fmt
* Update CHANGELOG.md
* Report mouse motion before click
This fixes an issue on macOS where a mouse click would be generated,
without ever getting a mouse motion to the position before the click.
This leads to the application thinking the mouse click occurred at a
position other than the actual mouse location.
This happens due to mouse motion above the window not automatically
giving focus to the window, unless it is actually clicked, making it
possible to move the window without motion events.
Fixes#942.
* Add additional mouse motion events
Co-authored-by: Ryan Goldstein <ryan@ryanisaacg.com>
* Use requestAnimationFrame for polling wasm
* Implement `requestAnimationFrame` for stdweb
Co-authored-by: Ryan G <ryanisaacg@users.noreply.github.com>
This reverts commit 9daa0738a9.
This commit introduced other bug #1453 with likely much more common bindings,
so reverting it for now.
Fixes#1453.
Co-authored-by: Osspial <osspial@gmail.com>
* On Windows, fix request_redraw() related panics
These panics were introduced by 6a330a2894
Fixes https://github.com/rust-windowing/winit/issues/1391
Fixes https://github.com/rust-windowing/winit/issues/1400
Fixes https://github.com/rust-windowing/winit/issues/1466
Probably fixes other related issues
See https://github.com/rust-windowing/winit/issues/1429
* On Windows, replace all calls to UpdateWindow by calls to InvalidateRgn
This avoids directly sending a WM_PAINT message,
which might cause buffering of RedrawRequested events.
We don't want to buffer RedrawRequested events because:
- we wan't to handle RedrawRequested during processing of WM_PAINT messages
- state transitionning is broken when handling buffered RedrawRequested events
Fixes https://github.com/rust-windowing/winit/issues/1469
* On Windows, panic if we are trying to buffer a RedrawRequested event
* On Windows, move modal loop jumpstart to set_modal_loop() method
This fixes a panic.
Note that the WM_PAINT event is now sent to the modal_redraw_method
which is more correct and avoids an unecessary redraw of the window.
Relates to but does does not fix https://github.com/rust-windowing/winit/issues/1484
* On Window, filter by paint messages when draining paint messages
This seems to prevent PeekMessage from dispatching unrelated sent messages
* Change recently added panic/assert calls with warn calls
This makes the code less panicky...
And actually, winit's Windoww callbacks should not panic
because the panic will unwind into Windows code.
It is currently undefined behavior to unwind from Rust code into foreign code.
See https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
* add comments to clarify WM_PAINT handling in non modal loop
* made redraw_events_cleared more explicit and more comments
* Remove assertions from Windows dark mode code
In general, winit should never assert on anything unless it means that
it is impossible to continue the execution of the program. There are
several assertions in the Windows dark mode code where this is not the
case.
Based on surface level inspection, all existing assertions could be
easily replaced with just simple conditional checks, allowing the
execution of the program to proceed with sane default values.
Fixes#1458.
* Add changelog entry
* Format code
* Pass dark mode by mutable reference
* Format code
* Return bool instead of mutable reference
* Fix dark mode success reply
Co-Authored-By: daxpedda <daxpedda@gmail.com>
* Fix dark mode success reply
* Replace magic integers with constants
Co-authored-by: daxpedda <daxpedda@gmail.com>
* Move `ModifiersChanged` variant to `WindowEvent`
* macos: Fix flags_changed for ModifiersChanged variant move
I haven't look too deep at what this does internally, but at least
cargo-check is fully happy now. :)
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* macos: Fire a ModifiersChanged event on window_did_resign_key
From debugging, I determined that macOS' emission of a flagsChanged
around window switching is inconsistent. It is fair to assume, I think,
that when the user switches windows, they do not expect their former
modifiers state to remain effective; so I think it's best to clear that
state by sending a ModifiersChanged(ModifiersState::empty()).
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* windows: Fix build
I don't know enough about the code to implement the fix as it is done on
this branch, but this commit at least fixes the build.
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* windows: Send ModifiersChanged(ModifiersState::empty) on KILLFOCUS
Very similar to the changes made in [1], as focus is lost, send an event
to the window indicating that the modifiers have been released.
It's unclear to me (without a Windows device to test this on) whether
this is necessary, but it certainly ensures that unfocused windows will
have at least received this event, which is an improvement.
[1]: f79f21641a31da3e4039d41be89047cdcc6028f7
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* macos: Add a hook to update stale modifiers
Sometimes, `ViewState` and `event` might have different values for their
stored `modifiers` flags. These are internally stored as a bitmask in
the latter and an enum in the former.
We can check to see if they differ, and if they do, automatically
dispatch an event to update consumers of modifier state as well as the
stored `state.modifiers`. That's what the hook does.
This hook is then called in the key_down, mouse_entered, mouse_exited,
mouse_click, scroll_wheel, and pressure_change_with_event callbacks,
which each will contain updated modifiers.
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* Only call event_mods once when determining whether to update state
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* flags_changed: Memoize window_id collection
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* window_did_resign_key: Remove synthetic ModifiersChanged event
We no longer need to emit this event, since we are checking the state of
our modifiers before emitting most other events.
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* mouse_motion: Add a call to update_potentially_stale_modifiers
Now, cover all events (that I can think of, at least) where stale
modifiers might affect how user programs behave. Effectively, every
human-interface event (keypress, mouse click, keydown, etc.) will cause
a ModifiersChanged event to be fired if something has changed.
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* key_up: Add a call to update_potentially_stale_modifiers
We also want to make sure modifiers state is synchronized here, too.
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* mouse_motion: Remove update_potentially_stale_modifiers invocation
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* Retry CI
* ViewState: Promote visibility of modifiers to the macos impl
This is so that we can interact with the ViewState directly from the
WindowDelegate.
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* window_delegate: Synthetically set modifiers state to empty on resignKey
This logic is implemented similarly on other platforms, so we wish to
regain parity here. Originally this behavior was implemented to always
fire an event with ModifiersState::empty(), but that was not the best as
it was not necessarily correct and could be a duplicate event.
This solution is perhaps the most elegant possible to implement the
desired behavior of sending a synthetic empty modifiers event when a
window loses focus, trading some safety for interoperation between the
NSWindowDelegate and the NSView (as the objc runtime must now be
consulted in order to acquire access to the ViewState which is "owned"
by the NSView).
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
* Check for modifiers change in window events
* Fix modifier changed on macOS
Since the `mouse_entered` function was generating a mouse motion, which
updates the modifier state, a modifiers changed event was incorrectly
generated.
The updating of the modifier state has also been changed to make sure it
consistently happens before events that have a modifier state attached
to it, without happening on any other event.
This of course means that no `CursorMoved` event is generated anymore
when the user enters the window without it being focused, however I'd
say that is consistent with how winit should behave.
* Fix unused variable warning
* Move changelog entry into `Unreleased` section
Co-authored-by: Freya Gentz <zegentzy@protonmail.com>
Co-authored-by: Kristofer Rye <kristofer.rye@gmail.com>
Co-authored-by: Christian Duerr <contact@christianduerr.com>
