Hi, Prasanta.

Are you sure that setInputMethod(where we initialize kbdLayout) will always 
executed before insertText(where we use kbdLayout)?

On 10/24/19 5:47 pm, Prasanta Sadhukhan wrote:
I could find from various sources that this API belongs to Carbon framework which has 
been deprecated so all its documentation has been taken down, but this belongs to 
Text Input Source API which has still not been deprecated par se. But, we could find 
an alternative more publicly available Appkit framework API to do the same thing, 
NSTextInputContext.selectedKeyboardInputSource 
<https://developer.apple.com/documentation/appkit/nstextinputcontext/1533970-selectedkeyboardinputsource?language=objc>.

http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.3/

Modified webrev to use the above API and also to catch the notification if 
selected text input source changes. With this, it works the same.

Regards

Prasanta

On 09-Oct-19 3:24 PM, Prasanta Sadhukhan wrote:
Hi Sergey,

On 02-Oct-19 1:35 AM, Sergey Bylokhov wrote:
Hi, Prasanta.

I did not find any documentation for TISGetInputSourceProperty, does it public 
API?
But I found a list of related crashes in some applications because the 
TISGetInputSourceProperty may return NULL.

Can you please double check that the previous fixes which touches these lines 
of code still works:
JDK-8148555, JDK-8132503, JDK-8180370

I could not find any documentation too but it seems to be the only way to get 
the current keyboard layout in mac, as I could get from search. As the fix has 
been tested in multiple systems, I do not see any problem.

I have added a null check to initialize keyboard layout to US if 
TISGetInputSourceProperty is null, so that the default US keyboard will work.

http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.2/

I have also checked the above fixes which still works.

Regards
Prasanta
On 9/25/19 4:18 am, Prasanta Sadhukhan wrote:
Hi All,

Please review a fix for an issue where it is seen that Java apps ignore system 
settings regarding handling yen key.

If we use mac keyboard layout to use Japanese input source and "Change Settings -> Keyboard -> Input 
Sources -> Japanese -> "Â¥" key generates -> \ (Backslash) "
and Change Input method to Romaji and press "yen" symbol in Japanese keyboard or 
"option+y" key combination in US keyboard
Java app still interprets it as "yen" in JTextField

Issue seems to happen due to fact when NSTextInputClient.insertText() method is called, 
even though "\" codePoint is passed,

but insertText() has a check for codePoint is complex or not, so in this case, it is not 
complex, InputMethodEvent is not generated and no "\" is inserted in JTextField.

Proposed fix is to see if keyboard layout is Japanese (kotoeri) and codePoint is 
"\" then take it as complex codepoint and generate IME,

so that whatever system setting is set for "yen" symbol, it is correctly 
interpreted and inputted in CInputMethod.insertText() method, to be seen in JTextField.

The fix has been tested in US keyboard and Japanese keyboard.

Bug: https://bugs.openjdk.java.net/browse/JDK-8214578

webrev: http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.0/

Regards
Prasanta





--
Best regards, Sergey.

Reply via email to