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

Thiago Milczarek Sayao tsayao at openjdk.org
Mon Sep 18 00:48:16 UTC 2023


On Sun, 17 Sep 2023 00:39:45 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> 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 did change it, but probably need some more work.
> 
> I also discovered that I probably should use the `PANGO_ATTR_*` to set the `IME_ATTR_*` with boundaries.

I did a simple logic that if filtered and commit is sent directly without a preedit it will send the event back to `process_key`. It seems to work but I'm not sure about an unknown complex scenario.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1328177741


More information about the openjfx-dev mailing list