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

[Prasanta Sadhukhan]

HI Phil,

I have cached the keyboard layout and used that (tested with US and 
Japanese input sources)

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

Regards
Prasanta
On 30-Sep-19 6:55 AM, Philip Race wrote:
> Hi,
>
>
> On 9/25/19, 10:30 PM, Prasanta Sadhukhan wrote:
>>
>> Hi Phil,
>>
>> On 25-Sep-19 9:27 PM, Philip Race wrote:
>>> Prasanta,
>>>
>>> Can you please add your evaluation to the bug. Last comment from you 
>>> in there is
>>> "it's still not reproducible for me" which seems unlikely if you 
>>> have a proposed fix.
>>>
>> I have added the evaluation in JBS.
>>> Actually I am having some trouble understanding what you wrote below.
>>> Questions in line.
>>>
>>> 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) "
>
> OK So if you select Japanese and scroll down far enough in the panel 
> to the right
> there is a combo box menu with two options which control what code 
> point is generated
> by the key marked with the Yen.
> According to David a Japanese keyboard has no \ key but programmers 
> need that
> and the Romaji single with Yen is actually not that widely used ...
> So us not generating the \ by ignoring that setting is a real problem.
>
>
> > Proposed fix is to see if keyboard layout is Japanese (kotoeri) and \
> > codePoint is "\" then take it as complex codepoint and generate IME,
>
> I am not sure if that would be considered hacky but it does seem to work.
> The system selection is honoured in the test with your build.
>
> Do we really have to query the keyboard type on every character inserted ?
>
> Is there some level we can cache this ? Or is that an unsolvable 
> problem if there are 2 keyboards ?
>
> Also since you do this :
> + unichar codePoint = [useString characterAtIndex:0]; why can't we use 
> the retrieved value here :- + ((utf8Length > 1) && [self 
> isCodePointInUnicodeBlockNeedingIMEvent:[useString 
> characterAtIndex:0]]) ||
> ?
>
> -phil.
>>>
>>> "Japanese -> "Â¥" key generates"
>>>
>>> What are you trying to say here with that -> ? Is that another level 
>>> of setting or do
>>> you mean after setting to Japanese and typing some key still 
>>> generates backslash ?
>>> Why does it say ¥" ? That isn't a key, is it ?
>>>
>> "Change Settings -> Keyboard -> Input Sources -> Japanese -> "Â¥" key 
>> generates -> \ (Backslash) " is system setting you can set from 
>> "System Preferences". I guess David Buck demoed this setting to you.
>>>
>>>> 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
>>>
>>> Umm  .. "still interprets it as Yen" ? Isn't that what you wanted to 
>>> happen ?
>>>
>> No, it should honour the system preference setting for "Japanese -> 
>> "Â¥" key generates". If it is "\", it should be "\", if it is "yen", 
>> it should be "yen". Without the fix, it was always "yen" irrespective 
>> of the above setting.
>>>>
>>>> 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.
>>>
>>> I am not sure I can parse this correctly
>>>
>>> "fact when" ? is where I start to get lost.
>>> Can you restate it ?
>>>
>> When NSTextInputClient.insertText() method is called with "\" 
>> codePoint with japanese as input source
>> insertText() checks whether this 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,
>>>
>>> Why ? Is backslash special ?
>>
>> Actually, for japanese input source in US keybord layout, backslash 
>> can have different connotation. It can be interpreted as backslash or 
>> yen depending on system setting.
>>
>> Regards
>>
>> Prasanta
>>
>>>
>>> -phil.
>>>>
>>>> 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
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190930/25e42308/attachment-0001.html>