* make `EventLoopWindowTarget` independent of UserEvent type
the `EventLoopWindowTarget` is needed for window creation. conceptually,
only `EventLoop` and `EventLoopProxy` need to be parameterized, and all
other parts of the backend should be agnostic about the user event type,
parallel to how `Event<T>` is parameterized, but `WindowEvent` is not.
this change removes the dependency on the type of user events from the
`EventLoopWindowTarget` for the Windows backend, but keep a phantom data
to keep the API intact. to achieve this, I moved the `Receiver` end of
the mpsc channel from `ThreadMsgTargetData` into `EventLoop` itself, so
the `UserEvent` is only passed between `EventLoop` and `EventLoopProxy`,
all other part of the backend just use unit type as a placeholder for
user events.
it's similar to the macos backend where an erased `EventHandler` trait
object is used so all component except `EventLoop` and `EventLoopProxy`
need to be parameterized. however `EventLoop` of the Windows backend
already use an `Box<dyn FnMut>` to wrap the user provided event handler
callback, so no need for an dedicated trait object, I just modified the
wrapper to replace the placeholder user event with real value pulled
from the channel. I find this is the approach which need minimum change
to be made to existing code. but it does the job and could serve as a
starting point to future Windows backend re-works.
* fix CI clippy failure.
* make UserEventPlaceholder a new type instead of alias
* invariance is maintained by top-level EventLoopWindowTarget<T>
this field is transitional and her to keep API compatibility only.
the correct variance and such is already ensured by the top-level
`EventLoopWindowTarget`, just use `PhantomData<T>` here.
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>
When calling `Window::request_redraw` from the `RedrawRequested`
handler the `RedrawWindow` won't result in `WM_PAINT` being delivered
due since user callback is run before `DefWindowProcW` is called.
Track whether the user called `Window::request_redraw` and ask for
`RedrawWindow` after running the said function during `WM_PAINT`
handling.
Fixes#3150.
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.
Add a method to request a system menu. The implementation
is provided only on Windows for now.
Co-authored-by: daxpedda <daxpedda@gmail.com>
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
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.
A surprising amount of work was required to enable these extensions
on Windows.
I had originally assumed that pump_events was going to be very similar
to run except would use PeekMessageW instead of GetMessageW to avoid
blocking the external loop but I found the Windows backend broke
several assumptions I had.
Overall I think these changes can hopefully be considered a quite a
significant simplification (I think it's a net deletion of a fair amount
of code) and I think it also helps bring it into slightly closer alignment
with other backends too
Key changes:
- I have removed the `wait_thread` that was a fairly fiddly way of handling
`ControlFlow::WaitUntil` timeouts in favor of using `SetTimer` which works
with the same messages picked up by `GetMessage` and `PeekMessage`.
- I have removed the ordering guarantees between `MainEventsCleared`,
`RedrawRequested` and `RedrawEventsCleared` events due to the complexity in
maintaining this artificial ordering, which is already not supported
consistently across backends anyway (in particular this ordering already
isn't compatible with how MacOS / iOS work).
- `RedrawRequested` events are now directly dispatched via `WM_PAINT` messages
- comparable to how `RedrawRequested` is dispatched via `drawRect` in the
MacOS backend.
- I have re-worked how `NewEvents`, `MainEventsCleared`, and `RedrawEventsCleared`
get dispatched to be more in line with the MacOS backend and also more in line
with how we have recently discussed defining them for all platforms.
`NewEvents` is conceptually delivered when the event loop "wakes up" and
`MainEventsCleared` gets dispatched when the event loop is about to ask the
OS to wait for new events.
This is a more portable model, and is already how these events work in the
MacOS backend.
`RedrawEventsCleared` are just delivered after `MainEventsCleared` but this
event no longer has a useful meaning.
Probably the most controversial thing here is that this "breaks" the ordering
rules for redraw event handling, but since my changes interacted with how the
order is maintained I was very reluctant to figure out how to continue
maintaining something that we have recently been discussing changing:
https://github.com/rust-windowing/winit/issues/2640.
Additionally, since the MacOS backend already doesn't strictly maintain this
order it's somewhat academic to see this as a breakage if Winit applications
can't really rely on it already.
This updates the documentation for `request_redraw()` to reflect that we
no longer guarantee that `RedrawRequested` events must be dispatched
after `MainEventsCleared`.
Some systems could resize the window immediately and we'd rather
inform the users right away if that was the case, so they could
create e.g. EGLSurface without waiting for resize, which is really
important for Wayland.
Fixes#2868.
Overhaul the keyboard API in winit to mimic the W3C specification
to achieve better crossplatform parity. The `KeyboardInput` event
is now uses `KeyEvent` which consists of:
- `physical_key` - a cross platform way to refer to scancodes;
- `logical_key` - keysym value, which shows your key respecting the
layout;
- `text` - the text produced by this keypress;
- `location` - the location of the key on the keyboard;
- `repeat` - whether the key was produced by the repeat.
And also a `platform_specific` field which encapsulates extra
information on desktop platforms, like key without modifiers
and text with all modifiers.
The `Modifiers` were also slightly reworked as in, the information
whether the left or right modifier is pressed is now also exposed
on platforms where it could be queried reliably. The support was
also added for the web and orbital platforms finishing the API
change.
This change made the `OptionAsAlt` API on macOS redundant thus it
was removed all together.
Co-authored-by: Artúr Kovács <kovacs.artur.barnabas@gmail.com>
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
Co-authored-by: daxpedda <daxpedda@gmail.com>
Fixes: #2631.
Fixes: #2055.
Fixes: #2032.
Fixes: #1904.
Fixes: #1810.
Fixes: #1700.
Fixes: #1443.
Fixes: #1343.
Fixes: #1208.
Fixes: #1151.
Fixes: #812.
Fixes: #600.
Fixes: #361.
Fixes: #343.
Makes WindowAttributes public and adds window_attributes() getter to
WindowBuilder.
In version 0.27, the WindowAttributes struct was made private, but this
removed the ability to introspect the default WindowBuilder values.
When other application minimized the winit window the
minimize state was going out of sync. This commit fixes
it by polling the state in `set_minimized`.
* fix clippy lints on Windows
* fix lints on other platforms
* a couple more
* again
* don't know what's goging on anymore
* fix examples
* comon
* how about now?
* this is getting annoying
* hmmm
* explicitly set a type
* 😢
* don't cast on x64 targets
* apply code review requests
* fix attributes on expressions
* fix ios
* On macOS, add `WindowBuilderExtMacOS::with_parent_window`
* Replace Parent with Option<Id<NSWindow, Shared>>
* Add addChildWindow method on NSWindow instead
* Update with_parent_window to be unsafe fn
* Add unified `with_parent_window`
* Remove `WindowBuilderExtUnix::with_parent`
* Remove `WindowBuilderExtWindows::with_parent_window`
* Clean up CI warnings
* Update CHANGELOG.md
It's `WindowBuilderExtX11` rather than `WindowBuilderExtUnix`
* Rename parent to owner
* Make with_parent_window unsafe and update its doc
* Add another way to get window on mac
* Add more documentations
* Add match arm and panic on invalid varients
* Add Xcb arm
* Update child_window example to make it safer and work in i686
* Remove duplicate entry in CHANGELOG.md
* Propogate error instead of expect
* Replace unreachable to panic
* Add platform note to X11
Co-authored-by: Wu Yu Wei <wusyong9104@gmail.com>
* On Windows and macOS, add API to enable/disable window controls
* fix build
* missing import
* use `WindowButtons` flags
* rename to `[set_]enabled_buttons`
* add example, fix windows impl for minimize
* macOS: Fix button enabling close/minimize while disabling maximized
* Update src/platform_impl/windows/window.rs
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
* compose the flags on a sep line, use `bool::then`
Co-authored-by: Mads Marquart <mads@marquart.dk>
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
