Add OpenHarmony support #4117
Draft
Add OpenHarmony support #4117
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GNOME doesn't list that there's a _NONE_ style at all, but it still works if you use it.
This is needed when passing and getting token from the IPC to activate the window.
This no longer exposes `CGDisplayCreateUUIDFromDisplayID` and instead uses `CFUUID` to avoid a leak. Monitor comparisons should also be more stable now.
When all we'll be doing is setting a new preedit, the preedit doesn't have to be explicitly cleared first. This change is perhaps debatable. The direct reason for this is to make it easier to work around quirks/bugs: in Masonry we've found IBus appears to resend the IME preedit in response to `Window::set_ime_cursor_area` (`zwp_text_input_v3::set_cursor_rectangle`). Because currently the preedit is first cleared, a new IME cursor area is sent, which again causes IBus to resend the preedit. This can loop for a while. The Wayland protocol is mechanically quite prescriptive, it says for zwp_text_input_v3:event:done. > 1. Replace existing preedit string with the cursor. > 2. Delete requested surrounding text. > 3. Insert commit string with the cursor at its end. > 4. Calculate surrounding text to send. > 5. Insert new preedit text in cursor position. > 6. Place cursor inside preedit text. Winit currently doesn't do surrounding text, so 2. and 4. can be ignored. In Winit's IME model, without a commit, sending just the `Ime::Preedit` event without explicitly clearing is arguably still equivalent to doing 1., 5., and 6.
Let's just not forward events to the IME once the user requested that it should be disabled, though, still try to change its state explicitly. Fixes rust-windowing#4082.
The serial was not unique, thus leading to issues and replay being triggered for normal input. Track modifiers based on they keycodes instead, since it's more unique. Links: alacritty/alacritty#8461
Fixes rust-windowing#4074. Fixes rust-windowing#3816.
|
Here is a list to test with winit patch:
Not all should be test which costs too many times. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a draft PR we add OpenHarmony support with winit for v0.30.x. For now, i run it with
glutin-winitsuccessfully, but we need more example to test it.I'm trying to test it with wgpu,egui so on. If it's confirmed that there are no issues, I'll convert it into an official PR. In the meantime, code reviews can also be conducted to improve the code quality. Thanks :)
#4081
changelogmodule if knowledge of this change could be valuable to users