v0.6.0

[notgull]

• Breaking: Raw pointer handles now use NonNull where appropriate, to avoid null pointer dereferences.
• Breaking: Renamed empty methods to new, and take parameters in most of those, to better match normal Rust semantics.
• Breaking: HasRaw(Display/Window)Handle::raw_(display/window)_handle returns a result indicating if fetching the window handle failed (Make raw_*_handle return a result #122).
• Breaking: Remove the Active/ActiveHandle types from the public API (Remove Active from the API #126).
• Breaking: Remove AppKitWindowHandle::ns_window and UiKitWindowHandle::ui_window since they can be retrieved from the view (Remove window handles from Apple handles #129).
• Breaking: Remove Copy derive from RawWindowHandle and WindowHandle (Remove Copy for RawWindowHandle/WindowHandle #140).
• Implement PartialEq, Eq and Hash for WindowHandle too. (Make sure traits are uniform across WindowHandle and DisplayHandle #128)
• Implement the relevant traits for &mut T where T: <trait>. (Incorrect changelog PR number #130)
• Add web handles for wasm-bindgen v0.2. They are locked behind the wasm-bindgen-0-2 feature. (Add wasm-bindgen v0.2 handles for web_sys::HtmlCanvasElement and web_sys::OffscreenCanvas #134)
• Deprecate the raw window/display handle traits. They will be removed at the next stable release. (Excise the HasRaw*Handle traits #139)

[kchibisov]

We'd likely need an update downstream, so we can sort of migrate the ecosystem, or at least offer the raw-window-handle v0.6 inside the winit as an option to simplify migrations.

[notgull]

We'd likely need an update downstream, so we can sort of migrate the ecosystem, or at least offer the raw-window-handle v0.6 inside the winit as an option to simplify migrations.

Do you mean something like rust-windowing/winit#2943? I've made similar PRs for Glutin and Softbuffer.

[kchibisov]

Yes, but I also meant to say, that we should offer raw-window-handle based on the features in winit. I know that we have patches around, but the thing is, that they still need review and work. And I also know that we can expose raw-window-handle v0.6 without adding all of its features, so the ecosystem could start slowly moving forward.

[kchibisov]

But I wasn't paying close attention to what actually will be included and what the scope will be in the next release, so it's up to @Lokathor , I guess.

[Lokathor]

Honestly I haven't looked closely at any of this in a while. I was mostly letting @notgull take the lead, and just providing a point of occasional double checking.

Just offhand, I'm not sure we need to update the outside world too much before we do a release. It seems okay to release 0.6 when it's ready and then if winit, wgpu, etc don't all update to the latest immediately it's not the end of the world. Basically we're providing a "protocol" of sorts, and then they're using the protocol to communicate with each other.

This might be too simple a view, so we could do stronger coordination with other crates if you think it's necessary @kchibisov .

[kchibisov]

I don't think we need strong coordination. I'm just saying that if it's time to release, we should probably do it. Winit will support both v0.5 and v0.6 under features anyway, to simplify the migration process. And winit doesn't even need safe handles to be supported right away.

I've came here only because the winit release will be relatively soon and I'd like to get reviewing patches wrt raw-window-handle.

[notgull]

I've updated the CHANGELOG here to describe the set of changes included in this new version more accurately.

Before merging and releasing I think we should ping stakeholders in raw-window-handle, just to give them the heads up that something is changing.

• winit: @kchibisov, @madsmtm, @daxpedda
• glutin: @kchibisov, @MarijnS95
• wgpu: @cwfitzgerald, @grovesNL
• softbuffer: @ids1024
• glazier: @xStrom
• ndk: @rib
• smithay-client-toolkit: @i509VCB
• rust-sdl2: @Cobrand

Like @Lokathor said above, I don't think ACKs from everyone are necessary, but we should wait at least a week to let people know that this is coming.

[daxpedda]

Thanks for pinging @notgull!
LGTM!

[xStrom]

I can update glazier basically as soon as this is released. 👍

[Lokathor]

I'll continue to wait for others to have a look and merge/release next week if objections haven't come up since then.

[notgull]

@Lokathor Its been more than a week, I think we're good to release.

[Lokathor]

Roger. I'll get to this after work.

[MarijnS95]

ndk should probably be on me instead of @rib (and glutin solely on @kchibisov). I left the country right as this was asked, but in the end the upgrade for the ndk appears to be rather trivial:

rust-mobile/ndk#434

I like the new lifetime since our NativeWindow struct is also appropriately lifetimed with a Drop implementation (and refcounted by Android on .clone()).