Wayland:
I found the calloop abstraction a little awkward to work with while I was
trying to understand why there was surprising workaround code in the wayland
backend for manually dispatching pending events.
Investigating this further it looks like there may currently be several issues
with the calloop WaylandSource (with how prepare_read is used and with (not)
flushing writes before polling)
Considering the current minimal needs for polling in all winit backends I do
personally tend to think it would be simpler to just own the responsibility for
polling more directly, so the logic for wayland-client `prepare_read` wouldn't
be in a separate crate (and in this current situation would also be easier to fix)
I've tried to maintain the status quo with calloop + workarounds.
X11:
I found that the recent changes (4ac2006cbc) to port the X11 backend
from mio to calloop lost the ability to check for pending events before
needing to poll/dispatch. (The `has_pending` state being queried
before dispatching() was based on state that was filled in during
dispatching)
As part of the rebase this re-introduces the PeekableReceiver and
WakeSender which are small utilities on top of
`std::sync::mpsc::channel()`. This adds a calloop `PingSource`
so we can use a `Ping` as a generic event loop waker.
For taking into account false positive wake ups the X11 source now
tracks when the file descriptor is readable so after we poll via
calloop we can then specifically check if there are new X11 events
or pending redraw/user events when deciding whether to skip the
event loop iteration.
Unfortunately this isn't a total removal, for two reasons:
- We still need "libc" for the Xlib XIM implementation, for locales.
- BSD requires libc to check for main-threadedness.
First one we can likely resolve in the near future, not so sure about
the second one without using some weird pthreads trick.
The utils in this module should help the users to activate the windows
they create, as well as manage activation tokens environment variables.
The API is essential for Wayland in the first place, since some
compositors may decide initial focus of the window based on whether
the activation token was during the window creation.
Fixes#2279.
Co-authored-by: John Nunley <jtnunley01@gmail.com>
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.
Instead of a single `bool` indicating that a key press has occured and
no key has been released since then, we store the scancode of the last
pressed key (if it is a key that repeats when held). This fixes a bug
where pressing a new key while one is already held down will be flagged
as a repeat even though it is obviously not a repeat.
The change to xinput2 completely disabled IME support, thus we've got
a dead keys reporting, because nothing was eating the key events
anymore, however that's not what we really need, given that not
working IME makes it impossible for some users to type.
The proper solution is to not use Xlib at all for that and rely on
xcb and its tooling around the XIM and text compose stuff, so
we'll have full control over what is getting sent to the XIM/IC or not.
Fixes#2888.
Add named variants for physical back and forward keys which could
be found on some mice. The macOS bits may not work on all the
hardware given that apple doesn't directly support such a thing.
Co-authored-by: daxpedda <daxpedda@gmail.com>
The use of `Filter` was confusing so it was removed inverting the
behavior of the enum and methods using it.
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
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.
* 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>
This adds `Window::set_window_level` to control the preferred
z level of the window.
Co-authored-by: Markus Siglreithmaier <m.siglreith@gmail.com>
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
Co-authored-by: Mads Marquart <mads@marquart.dk>
* Only build, but don't run tests in MSRV CI
Since the MSRV of development dependencies can easily be bumped without it affecting the MSRV of the published version of `winit`
* Run clippy on stable Rust instead of MSRV Rust
clippy inspects the `rust-version` field, and only suggests changes that conform to that.
To be more consistent with mobile platforms this updates the Windows,
macOS, Wayland, X11 and Web backends to all emit a Resumed event
immediately after the initial `NewEvents(StartCause::Init)` event.
The documentation for Suspended and Resumed has also been updated
to provide general recommendations for how to handle Suspended and
Resumed events in portable applications as well as providing
Android and iOS specific details.
This consistency makes it possible to write applications that lazily
initialize their graphics state when the application resumes without
any platform-specific knowledge. Previously, applications that wanted
to run on Android and other systems would have to maintain two,
mutually-exclusive, initialization paths.
Note: This patch does nothing to guarantee that Suspended events will
be delivered. It's still reasonable to say that most OSs without a
formal lifecycle for applications will simply never "suspend" your
application. There are currently no known portability issues caused
by not delivering `Suspended` events consistently and technically
it's not possible to guarantee the delivery of `Suspended` events if
the OS doesn't define an application lifecycle. (app can always be
terminated without any kind of clean up notification on most
non-mobile OSs)
Fixes#2185.
Co-authored-by: Marijn Suijten <marijns95@gmail.com>
Co-authored-by: Markus Røyset <maroider@protonmail.com>
