<AWT Dev> The input method handling

[Eirik Bakke]

Ah, makes sense. Thanks for the explanation.

-- Eirik

On 12/10/14, 2:06 PM, "Sergey Malenkov" <malenkov at gmail.com> wrote:

>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:
>>>
>>>http://hg.openjdk.java.net/jdk9/dev/jdk/file/e5b66323ae45/src/java.deskt
>>>op
>>>/macosx/native/libawt_lwawt/awt/AWTView.m
>>>
>>>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
>>>lengthOfBytesUsingEncoding:NSUTF8StringEncoding];
>>>+    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
>>>JetBrains