On Sun, 14 May 2023 22:17:30 GMT, Thiago Milczarek Sayao <tsa...@openjdk.org> wrote:
>> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative >> positioning on `InputMethodRequest`. > > Dead keys should work now, but not sure I covered them all. @tsayao You should expand your test app to show TYPED KeyEvents or use the KeyEventViewer app I just attached to the original bug report. Then run it against an unmodified JFX build on Linux and see what events go by. If you have a Mac that's even better, the sequence of events between Mac and Linux should be very similar. As I said in my earlier note you already had dead keys working just fine. Just treat them like any other IM event. And they don't generate PRESSED KeyEvents on Linux, that only happens on Windows. It's the non-dead letter keys that are the problem. If you fire up one of the test apps and immediately press the X key you should see this sequence of events on all platforms: 1. PRESSED KeyEvent with KeyCode.X 2. TYPED KeyEvent with the text "x". 3. RELEASED KeyEvent with KeyCode.X Your code is generating this sequence: 1. InputMethodEvent with commit text "x" 2. PRESSED KeyEvent with KeyCode.X 3. RELEASED KeyEvent with KeyCode.X Each of these characters is coming in as a `commit` signal without a `preedit-changed` signal before it. These commits shouldn't be sent to `jViewNotifyInputMethod`. You need to detect this case and a) ignore the commit and b) return `false` from `filterIME` so the event is handled by `process_key` instead. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1547040959
