feat: add openharmony support

[richerfu]

• Tested on all platforms changed
• Added an entry to CHANGELOG.md 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

Add openharmony platform support, now we can build it successfully with XComponent. It doesn't effect any other code, so i think i needn't to add more docs or tests.

And you can find a full example with example. If you want more info, please let me know, thanks !

[kchibisov]

You should also explicitly set that we depend on raw-window-handle 0.6.2, since the build will break otherwise.

[richerfu]

raw-window-handle

Should i update the raw-window-handle version to 0.6.2? Looks not..

[kchibisov]

Should i update the raw-window-handle version to 0.6.2? Looks not..

open harmony was added in 0.6.2, so you should explicitly specify 0.6.2

[richerfu]

Should i update the raw-window-handle version to 0.6.2? Looks not..

open harmony was added in 0.6.2, so you should explicitly specify 0.6.2

Done

[MarijnS95]

Glutin's CI is quite extensive. @richerfu would you be up for adding one or two ohos target triples to our CI with the egl feature, so that we can always build-test this functionality and make sure this target environment is not accidentally broken in the future?

[richerfu]

OpenHarmony currently has no environment to directly run cargo test, and all code testing is forcibly dependent on real machines. So there is no way to do some testing or verification in the CI environment for the time being. According to official news, this capability will be supported as early as Q1 2025.

[MarijnS95]

@richerfu I don't think we need run-time tests, just build-testing (i.e. cargo check/build/clippy) is enough for now to at least guarantee a minimum level of source compatibility. We can incrementally move towards testing on real machines if that possibility is provided.

For example, this works for me:

$ rustup target add x86_64-unknown-linux-ohos
$ cargo clippy --all-features --target x86_64-unknown-linux-ohos -p glutin

And if I make a silly change, like commenting out a Self::Ohos match arm, the compiler/CI could complain that the ohos target no longer even compiles:

$ cargo clippy --all-features --target x86_64-unknown-linux-ohos -p glutin
error[E0004]: non-exhaustive patterns: `api::egl::surface::NativeWindow::Ohos(_)` not covered
   --> glutin/src/api/egl/surface.rs:541:15
    |
541 |         match *self {
    |               ^^^^^ pattern `api::egl::surface::NativeWindow::Ohos(_)` not covered
    |
note: `api::egl::surface::NativeWindow` defined here
   --> glutin/src/api/egl/surface.rs:446:6
    |
446 | enum NativeWindow {
    |      ^^^^^^^^^^^^
...
460 |     Ohos(*mut ffi::c_void),
    |     ---- not covered
    = note: the matched value is of type `api::egl::surface::NativeWindow`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
    |
541 ~         match *self {
542 +             api::egl::surface::NativeWindow::Ohos(_) => todo!(),
543 +         }
    |

For more information about this error, try `rustc --explain E0004`.
error: could not compile `glutin` (lib) due to 1 previous error

(Which may be useful if we edit some code elsewhere or add new match blocks in the future, etc..)

[richerfu]

Ok, i'll try to add some code and upgrade CI config later.