Update to new raw-window-handle strategy#3126
Conversation
| /// 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.
Nit: This documentation is also relevant for v0.6
There was a problem hiding this comment.
you mean, that this should also be added to the implementation of HasDisplayHandle for v0.6?
kchibisov
left a comment
There was a problem hiding this comment.
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.
I'm implementing this in the NDK, as part of version bumps.
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.
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.
Did you consider whether or not the safe borrow handles should be implemented by winit?
There was a problem hiding this comment.
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 <[email protected]>
Signed-off-by: John Nunley <[email protected]>
Signed-off-by: John Nunley <[email protected]>
Signed-off-by: John Nunley <[email protected]>
Signed-off-by: John Nunley <[email protected]>
Signed-off-by: John Nunley <[email protected]>
Signed-off-by: John Nunley <[email protected]>
Signed-off-by: John Nunley <[email protected]>
Signed-off-by: John Nunley <[email protected]>
Signed-off-by: John Nunley <[email protected]>
Signed-off-by: John Nunley <[email protected]>
Co-Authored-By: TornaxO7 <[email protected]> Signed-off-by: John Nunley <[email protected]>
bd80244 to
2933b0a
Compare
MarijnS95
left a comment
There was a problem hiding this comment.
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.mdif knowledge of this change could be valuable to usersEssentially a combination of #3075 and #2943. This PR adds explicit support for
raw-window-handlev0.6 through therwh_06feature, which is enabled by default. It also adds optional support forraw-window-handlev0.5 andraw-window-handlev0.4, which is exposed through features that are not exposed by default.This also adds a lifetime to
WindowAttributes.