On Thu, 3 Oct 2024 14:23:24 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`. >> >> [Screencast from 17-09-2023 >> 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base > due to a merge or a rebase. The pull request now contains 105 commits: > > - Remove idea file > - Fix the case when IME filters key_press (Polish ALT Gr + C) > - Merge branch 'master' into new_ime > - Fix for Polish AltGR combinations > - Remove negative checks > - Revert idea file > - Remove unused import > - Fix review points > - Merge branch 'master' into new_ime > - Merge branch 'refs/heads/master' into new_ime > - ... and 95 more: https://git.openjdk.org/jfx/compare/5428f267...e56588ba I'm still tracking this down but it looks like the "commit" signal is being triggered asynchronously. We are not processing an event when it arrives. Inside `on_commit` you can call `ctx->get_events_count()` and it will return 0. This count is maintained by the EventsCounterHelper over in GlassApplication.cpp and should be 1. It gets weirder. For those of you who are not familiar with the wonders of the Gtk API: normally the IME filter does nothing with the original key event except post a copy of it with a special state flag set. It will trigger IME signals when the copy is processed. Normally we would expect "commit" to arrive while processing the copy but here it's arriving asynchronously after processing the original event. Or this is all a fever dream and I'm misdiagnosing what's going on. But when "commit" arrives the event count is definitely 0 and that is so, so wrong. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2395619395
