+1
-phil
On 11/6/19, 2:37 PM, Sergey Bylokhov wrote:
Looks fine.
On 11/5/19 10:39 pm, Prasanta Sadhukhan wrote:
Hi Sergey,
Yes, logically input method source needs to be set first before user
can insert text. Practically, also I have tested and found that to be
the case. If we change from "US" keyboard to "Romaji" or change
system settings
"Change Settings -> Keyboard -> Input Sources -> Japanese -> "Â¥" key
generates -> \ (Backslash) "
and try to input text in textfield, setInputMethod will be called
first before insertText.
Regards
Prasanta
On 02-Nov-19 2:39 AM, Sergey Bylokhov wrote:
Hi, Prasanta.
Are you sure that setInputMethod(where we initialize kbdLayout) will
always executed before insertText(where we use kbdLayout)?
On 10/24/19 5:47 pm, Prasanta Sadhukhan wrote:
I could find from various sources that this API belongs to Carbon
framework which has been deprecated so all its documentation has
been taken down, but this belongs to Text Input Source API which
has still not been deprecated par se. But, we could find an
alternative more publicly available Appkit framework API to do the
same thing, NSTextInputContext.selectedKeyboardInputSource
<https://developer.apple.com/documentation/appkit/nstextinputcontext/1533970-selectedkeyboardinputsource?language=objc>.
http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.3/
Modified webrev to use the above API and also to catch the
notification if selected text input source changes. With this, it
works the same.
Regards
Prasanta
On 09-Oct-19 3:24 PM, Prasanta Sadhukhan wrote:
Hi Sergey,
On 02-Oct-19 1:35 AM, Sergey Bylokhov wrote:
Hi, Prasanta.
I did not find any documentation for TISGetInputSourceProperty,
does it public API?
But I found a list of related crashes in some applications
because the TISGetInputSourceProperty may return NULL.
Can you please double check that the previous fixes which touches
these lines of code still works:
JDK-8148555, JDK-8132503, JDK-8180370
I could not find any documentation too but it seems to be the only
way to get the current keyboard layout in mac, as I could get from
search. As the fix has been tested in multiple systems, I do not
see any problem.
I have added a null check to initialize keyboard layout to US if
TISGetInputSourceProperty is null, so that the default US keyboard
will work.
http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.2/
I have also checked the above fixes which still works.
Regards
Prasanta
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) "
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
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.
Proposed fix is to see if keyboard layout is Japanese (kotoeri)
and codePoint is "\" then take it as complex codepoint and
generate IME,
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
