RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor

[Thiago Milczarek Sayao]

On Wed, 13 Sep 2023 15:52:43 GMT, Martin Fox <duke at 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