<AWT Dev> [14] RFR JDK-8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings

[Prasanta Sadhukhan]

Hi Sergey,

Yes, logically input method source needs to be set first before user can 
insert text. Practically, also I have tested and found that to be the 
case. If we change from "US" keyboard to "Romaji" or change system settings

"Change Settings -> Keyboard -> Input Sources -> Japanese -> "Â¥" key 
generates -> \ (Backslash) "

and try to input text in textfield, setInputMethod will be called first 
before insertText.

Regards
Prasanta
On 02-Nov-19 2:39 AM, Sergey Bylokhov wrote:
> 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
>>>>>
>>>>
>>>>
>
>