On Wed, 13 Sep 2023 15:52:43 GMT, Martin Fox <d...@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 03-09-2023 >> 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line > 91: > >> 89: void WindowContextBase::commitIME(gchar *str) { >> 90: if (!im_ctx.on_preedit) { >> 91: jchar key = g_utf8_get_char(str); > > This block is trying to set up calls to View.notifyKey. To get the correct > KeyCode requires information in the original GdkEventKey like the hardware > code and modifier state (for handling Num Lock on the key pad). The simplest > solution is to record a pointer to the original GdkEventKey before calling > `gtk_im_context_filter_keypress` and here pass that pointer to `process_key`. > It will get the KeyCode right and generate the appropriate View.notifyKey > calls. > > (In theory another approach is to ignore the commit and return 'false' from > filterIME so the original GdkEvent isn't filtered. I tried that but it turned > into a mess because I was seeing two key press events for every keystroke. > `gtk_im_context_filter_keypress` filters out the original key press event > without generating a commit. Instead it posts a duplicate event with a > private modifier flag set and the commit signal is sent out when that second > event is passed to `gtk_im_context_filter_keypress`.) I think the correct way is to generate a new gdk event. If I understood correctly, it's what gtk does [internally](https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkimcontextsimple.c). I will experiment with that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1324816395
