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

[Martin Fox]

On Sat, 6 May 2023 23:11:21 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> I see that this PR changes the behavior of dead keys. You may be aware of this but I thought I would write this up for others to review.
>> 
>> In the past when the user pressed a dead key they got no feedback until they pressed the next key at which point the final character would appear. With this PR when the user presses a dead key they get a preview of the diacritic which looks the same as previewing text from an IME.
>> 
>> This is a change from the old JavaFX behavior but not necessarily a bug. In fact it matches the new behavior of Ubuntu. I'm not sure when they made the switch but in Ubuntu 18 there was no diacritic preview and in Ubuntu 22 there is. It also matches the way the Mac works.
>> 
>> At the API level this changes the event stream. In the past the dead key only generated an incorrectly encoded RELEASED KeyEvent. The fully composed character was then delivered as the commit string in an InputMethodEvent. With this PR the (sort of bogus) RELEASED KeyEvent goes away and is replaced by an InputMethodEvent that delivers the preview diacritic in the compose string.
>> 
>> One minor detail: after entering a dead key the cursor moves to a point before the preview diacritic instead of after it. That looks like a bug and doesn't match the way other parts of Ubuntu behave.
>
> @beldenfox I'm getting the bogus KEY_RELEASED event you mentioned. It's weird because tbe dead key produces a KEY_RELEASED but not a KEY_PRESS. 
> 
> Edit:
> 
> bool WindowContextBase::im_filter_keypress(GdkEventKey *event) {
>     return gtk_im_context_filter_keypress(im_ctx.ctx, event);
> }
> 
> 
> 
> This is why. I will check, but I think dead keys should either produce both KEY_PRESS and KEY_RELEASED or none.
> 
> I have attached a simple test app on [JDK-8305418](https://bugs.openjdk.org/browse/JDK-8305418)
> 
> On Windows (using the test app mentioned) I get when typing é:
> 
> Pressed: ´
> Pressed: e
> Released: e
> 
> 
> 
> I think it should have a Released event with ´, shouldn't it?
> 
> Also Windows does not deliver the `InputMethodEvent.INPUT_METHOD_TEXT_CHANGED` event.

@tsayao The bogus RELEASED event happens on every platform after an InputMethodEvent that commits. I suppose the key press event is swallowed by the IM context which then commits the text and exits the compose state. Then the release event arrives and is processed as a standard KeyEvent.

On Windows dead keys are handled entirely using KeyEvents, no InputMethodEvents involved. The final character is delivered as the text in a TYPED KeyEvent.

Your new code is handling dead keys just fine, the event sequence matches the way the Mac works and is compatible with the way the previous Linux code worked.

But with this PR I'm not seeing any KeyEvents as I type regular text. If you're typing, say, Spanish most characters (other than dead keys) should generate PRESSED and TYPED KeyEvents. Your code delivers every character in an InputMethodEvent commit event. This needs to be fixed, the system relies on PRESSED events to trigger accelerators.

I did a little Googling and I think this is just the way the Gtk IM works; all text is delivered in a commit signal. I think you need to track whether the IM is in pre-edit mode or not to distinguish which commits should turn into KeyEvents and which should remain as InputMethodEvents. There are signals for tracking pre-edit mode but I haven't tested them out.

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

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1537593602