<i18n dev> <AWT Dev> The input method handling

Sergey Malenkov malenkov at gmail.com
Wed Dec 10 19:06:41 UTC 2014

Thank you for the link, but my changes do not remove ability of typing
some characters. This is about internal representation of key events.
I suggest to do not replace key-typed events with the corresponding
input method events for simple inserting of a single character.

For example, with Oracle JDK Alt-L on German layout generates
key-typed event for '@', but Alt-K generates input event for 'Δ'. Why?
The only difference is that '@' contains 1 byte in UTF8. But Java
characters consist of 2 bytes each, so we should not generate simple
input method events if we can use key-typed events.

Note that Alt-E on English layout generates *complex* input method
event, but my fix does not affect such cases.

Best regards,
Sergey A. Malenkov

On Wed, Dec 10, 2014 at 9:26 PM, Eirik Bakke <ebakke at mit.edu> wrote:
> Passing by--maybe the following piece of NetBeans Platform documentation
> has relevance:
> http://wiki.netbeans.org/DevFaqLogicalKeybindings
> Quote: "There should be no Alt-bound keyboard shortcuts on Macintosh, ever
> - it is used on international keyboards as the compose key (for a long
> time, we didn't know it, but Norwegian and French users could not type }
> or { in NetBeans - kind of limits the usefuless of a Java IDE)."
> I'm on MacOS now, on a US keyboard, and in fact, most alt+key combinations
> do produce valid characters (e.g. asdf=åß Ÿ). On non-US keyboards, these
> combinations might be the only way to produce certain "common" characters
> (e.g. {}, as the NetBeans page mentions).
> I'm not familiar with JDK internals, so my apologies if the observations
> above are not relevant here.
> -- Eirik
> On 12/10/14, 12:56 PM, "Sergey Malenkov" <malenkov at gmail.com> wrote:
>>Hi all,
>>In Oracle JDK the input method handling is slightly different from
>>Apple JDK. And this is a reason of some issues in IntelliJ IDEA. I
>>found out that the insertText method in the following file uses
>>lengthOfBytesUsingEncoding instead of length in characters:
>>This means that almost every Alt+Key combination generates
>>InputMethodEvent instead of pair of KeyEvent for PRESSED and TYPED. It
>>makes impossible to support custom shortcuts for all Alt+Key and
>>Shift+Alt+Key combinations on Mac, what is one of the reasons why
>>users do not want to migrate from Apple JDK to Oracle JDK on Mac.
>>I suggest to apply the following patch to the AWTView.m file:
>>--- a/src/macosx/native/sun/awt/AWTView.m Wed Dec 10 17:20:48 2014 +0400
>>+++ b/src/macosx/native/sun/awt/AWTView.m Wed Dec 10 19:51:56 2014 +0300
>>@@ -889,7 +889,7 @@
>>     // text, or 'text in progress'.  We also need to send the event
>>if we get an insert text out of the blue!
>>     // (i.e., when the user uses the Character palette or Inkwell),
>>or when the string to insert is a complex
>>     // Unicode value.
>>-    NSUInteger utf8Length = [aString
>>+    NSUInteger utf8Length = [aString length];
>>     if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length >
>>1)) {
>>         JNIEnv *env = [ThreadUtilities getJNIEnv];
>>It makes the input method handling  more compatible with Apple JDK and
>>allows us to provide users the same behavior with Oracle JDK.
>>Do you have any objections?
>>Are there some hidden pitfalls?
>>Best regards,
>>Sergey A. Malenkov

More information about the i18n-dev mailing list