-
Notifications
You must be signed in to change notification settings - Fork 111
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
ndk/native_window: Implement HasWindowHandle
for 0.4 and 0.6 (and maintain 0.5)
#434
Conversation
@kchibisov perhaps you also want to take a look at this PR in conjunction with rust-windowing/winit#3126? |
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.
In winit we kept the raw-window-handle
v0.4
, which is missing here. It would be nice to have it as well?
@kchibisov we never had it so I don't really feel like it adds any value unless there are compelling reasons to? Perhaps to keep the implementations in |
In addition, what do folks think about having any of these features in the |
@MarijnS95 yes, just for consistency reasons. But I don't care that much if it's fine with you.
Whatever you prefer as a library writer. You could suggest updating to 0.6.0 if you do breaking changes anyway. |
HasWindowHandle
for 0.6 (and maintain 0.5)HasWindowHandle
for 0.4 and 0.6 (and maintain 0.5)
@kchibisov added. I'll think about the default features for a bit... |
…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
The `ndk` crate enables `raw-window-handle 0.6` by default (because of rust-mobile/ndk#434 (comment)) which might not be used by consumers of the `android-activity` crate at all, or might (still) be a mismatching version. Even if the `rwh_0x` features are additive, figuring that out leads to cryptic errors and it is best to turn off these defaults completely and leave it to the user to turn it back on in their own `[dependencies]` section if desired.
The `ndk` crate enables `raw-window-handle 0.6` by default (because of rust-mobile/ndk#434 (comment)) which might not be used by consumers of the `android-activity` crate at all, or might (still) be a mismatching version. Even if the `rwh_0x` features are additive, figuring that out leads to cryptic errors and it is best to turn off these defaults completely and leave it to the user to turn it back on in their own `[dependencies]` section if desired.
We decided to add `rwh_06` to the `default` list of features in the `ndk` to [nudge users to upgrade], but this forces `winit` to always (transitively) include `raw-window-handle 0.6` even if the user has set a different `rwh_xx` feature on the `winit` crate. `winit` already forwards the respective `rwh_xx` feaure to the `ndk` crate anyway, so this default should just be turned off. At the time of writing this is the only `default` feature of the `ndk`. [nudge users to upgrade]: rust-mobile/ndk#434 (comment)
We decided to add `rwh_06` to the `default` list of features in the `ndk` to [nudge users to upgrade], but this forces `winit` to always (transitively) include `raw-window-handle 0.6` even if the user has set a different `rwh_xx` feature on the `winit` crate. `winit` already forwards the respective `rwh_xx` feaure to the `ndk` crate anyway, so this default should just be turned off. At the time of writing this is the only `default` feature of the `ndk`. Links: rust-mobile/ndk#434 (comment)
We decided to add `rwh_06` to the `default` list of features in the `ndk` to [nudge users to upgrade], but this forces `winit` to always (transitively) include `raw-window-handle 0.6` even if the user has set a different `rwh_xx` feature on the `winit` crate. `winit` already forwards the respective `rwh_xx` feaure to the `ndk` crate anyway, so this default should just be turned off. At the time of writing this is the only `default` feature of the `ndk`. Links: rust-mobile/ndk#434 (comment)
We decided to add `rwh_06` to the `default` list of features in the `ndk` to [nudge users to upgrade], but this forces `winit` to always (transitively) include `raw-window-handle 0.6` even if the user has set a different `rwh_xx` feature on the `winit` crate. `winit` already forwards the respective `rwh_xx` feaure to the `ndk` crate anyway, so this default should just be turned off. At the time of writing this is the only `default` feature of the `ndk`. Links: rust-mobile/ndk#434 (comment)
Following the same strategy in winit, move
raw-window-handle 0.5
behind arwh_05
feature and addraw-window-handle 0.4
and the newly releasedraw-window-handle 0.6
behind a correspondingrwh04
/rwh_06
feature. The new non-raw trait and lifetimed type since0.6
have been implemented instead, asraw-window-handle
provides blanket implementations to coerce/convert back toRaw*
types.