Ah, makes sense. Thanks for the explanation. -- Eirik
On 12/10/14, 2:06 PM, "Sergey Malenkov" <malen...@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 <eba...@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" <malen...@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
