feat: support openharmony platform

[richerfu]

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality

This is a re-implenment for OpenHarmony based with #4117 and main branch.I try to add basic implenment at first. And then i can add more documents and examples to explain the methods and codes.

[kchibisov]

Can be maintained out of tree at the current state of things.

[kchibisov]

Though, we'd have to do something with NativeKeyCode, I guess, but that's a minor thing.

[richerfu]

Can be maintained out of tree at the current state of things.

Seems that we need to add some patch codes for winit-core and winit crates. Is it possible for us to merge this PR into main branch?

[kchibisov]

The only issue is with winit-core, that's what I've highlighted, the winit itself is not required to be patched for it to be run, since you can run EventLoop directly. Though, I wouldn't mind extending EventLoop to allow gluing other event loops into it.

[richerfu]

The only issue is with winit-core, that's what I've highlighted, the winit itself is not required to be patched for it to be run, since you can run EventLoop directly. Though, I wouldn't mind extending EventLoop to allow gluing other event loops into it.

Got it. If the code can be merged into the main branch, it will feel more natural for our compatibility with the community's capabilities and for the users. We hope it can be merged into the mainline as much as possible. Thank you :)

[kchibisov]

It's more of the question how those should be dealt with and to not block development and also who should take care of it when people can not update/review changes to their backends. There's no difference other than you'd need to enable it manually.

I also plan to remove redox along the way, since it's a niche platform as well and if users want to target it they can pull the corresponding crate it and enable it.

Mostly a resource management and a reason why the current design evolved that way, so other people can use winit, but not depend on upstream backends that much, specifically for cases like yours, etc. We also don't have resources to deal with all the backends possible, etc, etc.

[richerfu]

I see and how about to do this?

1. Split winit-ohos to indent repo.
2. Add some patch codes to winit-core.
3. Add some feature flags for winit that we can enable for ohos.

[kchibisov]

We may also reference your crate in winit but make it live in ohos-rs and keep the integration here minimal and also don't directly expose .

[richerfu]

We may also reference your crate in winit but make it live in ohos-rs and keep the integration here minimal and also don't directly expose .

Got it, i'll do it. Thanks a lot

[richerfu]

Seems that we depend on winit-core crate version if we split winit-ohos to indent crate and publish it. When will we publish the winit-core to crate-io. @kchibisov

[kchibisov]

I hope soon-ish, but no ETA...