<AWT Dev>  RFR JDK-8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings
prasanta.sadhukhan at oracle.com
Mon Sep 30 06:47:55 UTC 2019
I have cached the keyboard layout and used that (tested with US and
Japanese input sources)
On 30-Sep-19 6:55 AM, Philip Race wrote:
> On 9/25/19, 10:30 PM, Prasanta Sadhukhan wrote:
>> Hi Phil,
>> On 25-Sep-19 9:27 PM, Philip Race wrote:
>>> 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
> characterAtIndex:0]]) ||
>>> "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.
>>>> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the awt-dev