<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