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

[Philip Race]

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/20190929/15e8f05a/attachment.html>