iced
iced copied to clipboard
iced-rs
basic IME supporting
iced ime support was broken due to winit 0.27 update . This PR add event to fit new winit IME event model and introduce new event support for text_input.
https://user-images.githubusercontent.com/48007646/196058439-1359af31-1c13-44d6-8016-100db22f6c64.mp4
Phase 1 tested on (Can we input CJK characters?)
- [x] windows MS-IME
- [x] windows Google IME
- [x] linux ibus x11
- [x] linux ibus wayland
- [x] linux fcitx x11
- [x] linux fcitx wayland
- [ ] macos 11 IME
- [x] macos 12 IME
- [x] macos 13 IME
https://user-images.githubusercontent.com/48007646/196908017-45ea5b4b-c224-4c02-a6ca-fa89fd31f5c1.mp4
Phase 2 tested on(Candidate position is near the TextInput?)
X11 winit candidate window issue https://github.com/rust-windowing/winit/issues/2522
- [x] windows MS-IME
- [x] windows Google IME
- [x] Linux ibus X11(winit issue)
- [x] Linux ibux wayland
- [x] Linux fcitx X11(winit issue)
- [x] Linux fcitx wayland
- [ ] macos 11 IME
- [ ] macos 12 IME
- [ ] macos 13 IME
tasks
- [x] enable winit IME support
- [x] translate winit IME event to iced event
- [x] text_input editing support
- [x] tell IME to put candidate window
we should move IME window to correct position to provide native look and feel where we should implement this logic.
if alacritty works well this should work as well. please test alacritty works well.
On my mac the candidate box is showing but it's in the wrong place (macOS Monterey 12.6, MacBook Pro (16-inch, 2019))
In alacritty it works well. (alacritty 0.11.0)
we need to tell IME candidate window position to winit but I can't find good way.
@hecrj I want to move IME candidate window to correct position but I can't find the way to send window Action from widget. I think we need to extend Widget interface like clipboard implementation. Is there any opinion to this problem.
now candidate window placed near TextInput . this positioning is not best but much better than nothing,
@Cupnfish @someoneinjd please test candidate window position is correct.
Thanks for your hard work. It works in most cases. But when I use the input method for the first time since the application started, the position is wrong, and after that the position is correct.
Alacritty also has this problem, so it might be a winit problem?
I also tested on my surface pro 6 (Arch Linux + Linux 6.0.1 + wayland 1.21.0 + fcitx5 5.0.19 + sway 1.7). And it doesn't have this problem.
Thanks for your hard work. It works in most cases. But when I use the input method for the first time since the application started, the position is wrong, and after that the position is correct.
This is also the case on my laptop. Not only that, switching to another app and then switching back triggers the bug again.
Maybe we need to notify IMEEnabled Event from IME to TextInput . I will try to fix this problem today .
@Cupnfish @someoneinjd please test condidate window is correct position even first time.
I tried but the same error again.
I added some log code to see whether the position was set.
diff --git a/native/src/widget/text_input.rs b/native/src/widget/text_input.rs
index f372b2ba..2ba8d06d 100644
--- a/native/src/widget/text_input.rs
+++ b/native/src/widget/text_input.rs
@@ -758,6 +758,7 @@ where
(text_bounds.x + position.0) as i32,
(text_bounds.y) as i32 + size as i32,
);
+ println!("[IME Enabled] Set IME {:?}", position);
ime.set_ime_position(position.0, position.1);
}
Event::Keyboard(keyboard::Event::IMEPreedit(text)) => {
@@ -802,6 +803,7 @@ where
(text_bounds.x + position.0) as i32,
(text_bounds.y) as i32 + size as i32,
);
+ println!("[IME Preedit] Set IME {:?}", position);
ime.set_ime_position(position.0, position.1);
shell.publish(message);
And here is the output (I typed "你" first and then "好")
Finished dev [unoptimized + debuginfo] target(s) in 0.27s
Running `target/debug/todos`
2022-10-21 09:22:06.499 todos[25370:2729210] TSM AdjustCapsLockLEDForKeyTransitionHandling - _ISSetPhysicalKeyboardCapsLockLED Inhibit
[IME Enabled] Set IME (55, 205)
[IME Preedit] Set IME (55, 205)
[IME Preedit] Set IME (55, 205)
[IME Preedit] Set IME (77, 205)
[IME Preedit] Set IME (77, 205)
[IME Preedit] Set IME (77, 205)
It seems that the position was calculated correctly but set_ime_position didn't work.
if we set IME position when we receive click event maybe we can achieve correct positioning.
@someoneinjd @Cupnfish please test if it works. set_ime_position when TextInput clicked. If this doesn't work we need to talk with alacritty team.
@someoneinjd @Cupnfish please test if it works. set_ime_position when TextInput clicked. If this doesn't work we need to talk with alacritty team.
It still comes up with that problem.
shall we release this PR or not? if you fixed this problem please open PR to my repo.
I find that set_ime_position in IMEEnabled doesn't work, maybe we need to set the candidate box position before receiving this event.
But this may not be easy to achieve, because when I use the Chinese input method to start todos and type, IMEEnabled is the first event received by the update function.
Maybe we can force the user to click the input box before they can type.
Unfocus text_input then type korean, preedit character(expect) inserted in text_input. It can delete manually but isn't deleted automatically.
Used font: NanumGothic.ttf OS: Windows 10
IME handling is very platform dependent issue so feel free to PR to my repo .
@hecrj This PR is very platform issue but no one tried to improving this PR. I think it better to basic support than nothing. So i want to left task for community to improve support.
@zmtq05 here is my repo https://github.com/t18b219k/iced it seems to me connecting to IME is ok . so I want to you to dive to native/src/widget/text_input.rs update function. before you making PR please run CI to build test binary. if you can please install CJK font for easy test.
I resolve my issue by does nothing when receive preedit event and unfocused. but japanese and chinese candidate window still appear when unfocused then input. EDIT: egui(+ eframe) is same.
sorry for bad english.
Thanks for your hard work. It works in most cases. But when I use the input method for the first time since the application started, the position is wrong, and after that the position is correct.
Related X11 bug
https://bugs.freedesktop.org/show_bug.cgi?id=1580
underlining when using IME. Bold line means this section text is converting.
https://user-images.githubusercontent.com/48007646/198844635-dd08f4e4-47b4-4ec2-8a3f-d580096cc5f4.mp4
@zmtq05 Thank you for good idea. My implementation is buggy when we use IME and open many TextInputs. Your idea implemented in my latest patch. https://github.com/t18b219k/iced/commit/fbc9c595c994831e4c18030b4d9d09a2bea3a516
Cursor must be located after the character.
