-
Notifications
You must be signed in to change notification settings - Fork 928
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update to new raw-window-handle strategy #3126
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Web is LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for following up on this @notgull!
macOS and iOS impl approved, have opened some discussion on the API though that I would like to see resolved.
/// Returns a [`raw_window_handle::RawDisplayHandle`] used by the [`EventLoop`] that | ||
/// created a window. | ||
/// | ||
/// [`EventLoop`]: crate::event_loop::EventLoop |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: This documentation is also relevant for v0.6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean, that this should also be added to the implementation of HasDisplayHandle
for v0.6
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you expect
instead of doing unchecked
? I'd rather not have more unsafe and have an actual assert that it got a Null
for whatever reason.
It'll basically never happen, but the cost of checking null
in a function you rarely call is non-existent.
may I ask which |
if let Some(native_window) = self.app.native_window().as_ref() { | ||
let handle = rwh_06::AndroidNdkWindowHandle::new(native_window.ptr().cast()); | ||
Ok(rwh_06::RawWindowHandle::AndroidNdk(handle)) | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm implementing this in the NDK, as part of version bumps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in rust-mobile/ndk#434.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May I ask what that means? Does anything has to do be done here or can this be marked as resolved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that once I publish ndk 0.8.0
, winit
should upgrade to it (it's on -beta.0
now) and reuse the traits provided there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this block this PR? I think that this should be merged in its current state and then we can upgrade to the latest ndk
later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not and I can patch this when submitting the final ndk
bump inside winit
.
} | ||
|
||
#[cfg(feature = "rwh_06")] | ||
pub fn raw_window_handle_rwh_06(&self) -> Result<rwh_06::RawWindowHandle, rwh_06::HandleError> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question while implementing the ndk
portion for this: implementing the Has**RAW**WindowHandle
trait is deprecated and there are blanket implementations when HasWindowHandle
is implemented. Should this function also return a non-raw handle (in terms of that implementation when it is released)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered this, but it would add an additional unsafe { WIndowHandle::borrow_raw }
call for each backend. I could go either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. At least for Android I'm willing to have that unsafe { borrow_raw() }
inside the ndk
with appropriate // SAFETY
docs, so you could call through to that. But it'd have to be consistent across all the backends...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you consider whether or not the safe borrow handles should be implemented by winit
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the time being it leads to a lot more unsafe
throughout the codebase. So I think that we shouldn't for now.
…0.5) Following [the same strategy in winit], move `raw-window-handle 0.5` behind a `rwh_05` feature and add `raw-window-handle 0.6` behind a corresponding `rwh_06` feature. Implement the new non-raw trait and **lifetimed** type for `0.6` (where `raw-window-handle` provides blanket implementations to coerce/convert back to `Raw*` types). [the same strategy in winit]: rust-windowing/winit#3126
…0.5) Following [the same strategy in winit], move `raw-window-handle 0.5` behind a `rwh_05` feature and add `raw-window-handle 0.6` behind a corresponding `rwh_06` feature. Implement the new non-raw trait and **lifetimed** type for `0.6` (where `raw-window-handle` provides blanket implementations to coerce/convert back to `Raw*` types). [the same strategy in winit]: rust-windowing/winit#3126
…0.5) Following [the same strategy in winit], move `raw-window-handle 0.5` behind a `rwh_05` feature and add `raw-window-handle 0.6` behind a corresponding `rwh_06` feature. Implement the new non-raw trait and **lifetimed** type for `0.6` (where `raw-window-handle` provides blanket implementations to coerce/convert back to `Raw*` types). [the same strategy in winit]: rust-windowing/winit#3126
…aintain 0.5) Following [the same strategy in winit], move `raw-window-handle 0.5` behind a `rwh_05` feature and add `raw-window-handle 0.4` and the newly released `raw-window-handle 0.6` behind a corresponding `rwh04`/`rwh_06` feature. The new **non-raw** trait and **lifetimed** type since `0.6` have been implemented instead, as `raw-window-handle` provides blanket implementations to coerce/convert back to `Raw*` types. [the same strategy in winit]: rust-windowing/winit#3126
…aintain 0.5) Following [the same strategy in winit], move `raw-window-handle 0.5` behind a `rwh_05` feature and add `raw-window-handle 0.4` and the newly released `raw-window-handle 0.6` behind a corresponding `rwh04`/`rwh_06` feature. The new **non-raw** trait and **lifetimed** type since `0.6` have been implemented instead, as `raw-window-handle` provides blanket implementations to coerce/convert back to `Raw*` types. [the same strategy in winit]: rust-windowing/winit#3126
…aintain 0.5) Following [the same strategy in winit], move `raw-window-handle 0.5` behind a `rwh_05` feature and add `raw-window-handle 0.4` and the newly released `raw-window-handle 0.6` behind a corresponding `rwh04`/`rwh_06` feature. The new **non-raw** trait and **lifetimed** type since `0.6` have been implemented instead, as `raw-window-handle` provides blanket implementations to coerce/convert back to `Raw*` types. [the same strategy in winit]: rust-windowing/winit#3126
…aintain 0.5) (#434) Following [the same strategy in winit], move `raw-window-handle 0.5` behind a `rwh_05` feature and add `raw-window-handle 0.4` and the newly released `raw-window-handle 0.6` behind a corresponding `rwh04`/`rwh_06` feature. The new **non-raw** trait and **lifetimed** type since `0.6` have been implemented instead, as `raw-window-handle` provides blanket implementations to coerce/convert back to `Raw*` types. [the same strategy in winit]: rust-windowing/winit#3126
101905c
to
bd80244
Compare
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
Co-Authored-By: TornaxO7 <tornax@proton.me> Signed-off-by: John Nunley <dev@notgull.net>
bd80244
to
2933b0a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving the android changes, but still have a question about borrowed handles.
This allows using accesskit with current versions of wgpu. Winit has a similar system to widden its support. See rust-windowing/winit#3126
This allows using accesskit with current versions of wgpu. Winit has a similar system to widden its support. See rust-windowing/winit#3126
CHANGELOG.md
if knowledge of this change could be valuable to usersEssentially a combination of #3075 and #2943. This PR adds explicit support for
raw-window-handle
v0.6 through therwh_06
feature, which is enabled by default. It also adds optional support forraw-window-handle
v0.5 andraw-window-handle
v0.4, which is exposed through features that are not exposed by default.This also adds a lifetime to
WindowAttributes
.