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

Phil Race philip.race at oracle.com
Mon Sep 30 15:55:02 UTC 2019


If you mean you tested toggling between the two, with the same AWT 
window open
and it correctly picked up the changes, then I am fine with this (+1).

-phil.

On 9/29/19 11:47 PM, Prasanta Sadhukhan wrote:
>
> 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/2a3aa356/attachment.html>


More information about the awt-dev mailing list