Re: [14] Review Request: 8232200 [macos 10.15] Windows in fullscreen tests jumps around the screen

[Sergey Bylokhov]

I'll check that in the related bug:
https://bugs.openjdk.java.net/browse/JDK-4837228

On 11/1/19 3:56 pm, Philip Race wrote:

OK, +1, although I wonder if we still need to exclude 24bpp in the test.

-phil.

On 11/1/19, 1:54 PM, Sergey Bylokhov wrote:

Yes I have tested this config by our tests, also decide to update the current 
test to cover this use case as well:
http://cr.openjdk.java.net/~serb/8232200/webrev.03

On 10/27/19 7:17 am, Philip Race wrote:

Have you tested this on a system with a 2nd monitor and the fs window being on 
the 2nd monitor ?

-phil.

On 10/26/19, 8:30 PM, Sergey Bylokhov wrote:

Hello.
Please review the fix for JDK 14.

Bug: https://bugs.openjdk.java.net/browse/JDK-8232200
Fix: http://cr.openjdk.java.net/~serb/8232200/webrev.02/

Our code assumes that when the display mode of the screen has changed,
the windows on the screen should not be moved, but on macOS 10.15 these
windows jump around, so we need to set all bounds of the window.

In the fix we will change the bounds of the window in the callback, which
is called when the display mode is actually changed by the application or
by some other reason.

The test is moved from the closed to the open repo.







--
Best regards, Sergey.

Re: [14] Review Request: 8232200 [macos 10.15] Windows in fullscreen tests jumps around the screen

[Philip Race]

OK, +1, although I wonder if we still need to exclude 24bpp in the test.

-phil.

On 11/1/19, 1:54 PM, Sergey Bylokhov wrote:
Yes I have tested this config by our tests, also decide to update the 
current test to cover this use case as well:

http://cr.openjdk.java.net/~serb/8232200/webrev.03

On 10/27/19 7:17 am, Philip Race wrote:
Have you tested this on a system with a 2nd monitor and the fs window 
being on the 2nd monitor ?


-phil.

On 10/26/19, 8:30 PM, Sergey Bylokhov wrote:

Hello.
Please review the fix for JDK 14.

Bug: https://bugs.openjdk.java.net/browse/JDK-8232200
Fix: http://cr.openjdk.java.net/~serb/8232200/webrev.02/

Our code assumes that when the display mode of the screen has changed,
the windows on the screen should not be moved, but on macOS 10.15 these
windows jump around, so we need to set all bounds of the window.

In the fix we will change the bounds of the window in the callback, 
which
is called when the display mode is actually changed by the 
application or

by some other reason.

The test is moved from the closed to the open repo.

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

[Sergey Bylokhov]

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 
.

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







--
Best regards, Sergey.

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

[Sergey Bylokhov]

+1

On 11/1/19 7:41 am, Alexey Ivanov wrote:

Thank you, Dmitry!
The changes look good to me.

On 01/11/2019 13:09, Dmitry Markov wrote:

Hi Alexey,

I have updated the fix. Please find the new version here: 
http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/

Thanks,
Dmitry


On 31 Oct 2019, at 16:27, Alexey Ivanov mailto:alexey.iva...@oracle.com>> wrote:

Hi Dmitry,

437 …by the operating system. …

I'd modify the following text a bit:
To run the test correctly, the default global key shortcut should be disabled. Follow the 
steps above, and then deselect "Turn keyboard access on or off" property which 
is responsible for `CTRL + F1` combination.

Does it sound clearer?
I'd not use backticks on the "Turn keyboard access on or off" because it's not 
something user is typing, nor is it a piece of code. Is the word “property” correct? Does 
“shortcut” or “option” fit better?

I'd recommend adding quotes around the option to look for:
448 in the right-side pane look for "Turn off Windows key hotkeys" and double 
click on it;

Consider adding an empty line before this line
450 Note: restart is required to make the settings take effect.
to make it a separate paragraph in HTML.


Regards,
Alexey



--
Best regards, Sergey.

Re: [14] Review Request: 8232200 [macos 10.15] Windows in fullscreen tests jumps around the screen

[Sergey Bylokhov]

Yes I have tested this config by our tests, also decide to update the current 
test to cover this use case as well:
http://cr.openjdk.java.net/~serb/8232200/webrev.03

On 10/27/19 7:17 am, Philip Race wrote:

Have you tested this on a system with a 2nd monitor and the fs window being on 
the 2nd monitor ?

-phil.

On 10/26/19, 8:30 PM, Sergey Bylokhov wrote:

Hello.
Please review the fix for JDK 14.

Bug: https://bugs.openjdk.java.net/browse/JDK-8232200
Fix: http://cr.openjdk.java.net/~serb/8232200/webrev.02/

Our code assumes that when the display mode of the screen has changed,
the windows on the screen should not be moved, but on macOS 10.15 these
windows jump around, so we need to set all bounds of the window.

In the fix we will change the bounds of the window in the callback, which
is called when the display mode is actually changed by the application or
by some other reason.

The test is moved from the closed to the open repo.




--
Best regards, Sergey.

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

[Alexey Ivanov]

Thank you, Dmitry!
The changes look good to me.

On 01/11/2019 13:09, Dmitry Markov wrote:

Hi Alexey,

I have updated the fix. Please find the new version here: 
http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/


Thanks,
Dmitry

On 31 Oct 2019, at 16:27, Alexey Ivanov > wrote:


Hi Dmitry,

437 …by the operating system. …

I'd modify the following text a bit:
To run the test correctly, the default global key shortcut should be 
disabled. Follow the steps above, and then deselect "Turn keyboard 
access on or off" property which is responsible for `CTRL + F1` 
combination.


Does it sound clearer?
I'd not use backticks on the "Turn keyboard access on or off" because 
it's not something user is typing, nor is it a piece of code. Is the 
word “property” correct? Does “shortcut” or “option” fit better?


I'd recommend adding quotes around the option to look for:
448 in the right-side pane look for "Turn off Windows key hotkeys" 
and double click on it;


Consider adding an empty line before this line
450 Note: restart is required to make the settings take effect.
to make it a separate paragraph in HTML.


Regards,
Alexey

--
Regards,
Alexey

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

[Dmitry Markov]

Hi Alexey,

I have updated the fix. Please find the new version here: 
http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/ 


Thanks,
Dmitry

> On 31 Oct 2019, at 16:27, Alexey Ivanov  wrote:
> 
> Hi Dmitry,
> 
> 437 …by the operating system. …
> 
> I'd modify the following text a bit:
> To run the test correctly, the default global key shortcut should be 
> disabled. Follow the steps above, and then deselect "Turn keyboard access on 
> or off" property which is responsible for `CTRL + F1` combination.
> 
> Does it sound clearer?
> I'd not use backticks on the "Turn keyboard access on or off" because it's 
> not something user is typing, nor is it a piece of code. Is the word 
> “property” correct? Does “shortcut” or “option” fit better?
> 
> I'd recommend adding quotes around the option to look for:
> 448 in the right-side pane look for "Turn off Windows key hotkeys" and double 
> click on it;
> 
> Consider adding an empty line before this line
> 450 Note: restart is required to make the settings take effect.
> to make it a separate paragraph in HTML.
> 
> 
> Regards,
> Alexey
> 
> On 31/10/2019 10:56, Dmitry Markov wrote:
>> Hi Alexey,
>> 
>> I have updated the fix based on your recommendation. The new version is 
>> located at: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.02/
>> Also please find my answers inline.
>> 
>> Thanks,
>> Dmitry
>> 
>>> On 29 Oct 2019, at 19:29, Alexey Ivanov >> > wrote:
>>> 
>>> Hi Dmitry,
>>> 
>>> Shall we drop hyphen in the header: “Client UI Tests”?
>>> 
>>> I think there should be no definite article in this sentence: “use -the- 
>>> key sequences”.
>>> 
>>> “…Turn off Windowss key hotkeys…”, there's an extra ‘s’ in Windows.
>>> 
>>> ”Note: restart is required to make the settings take effect.”
>>> Just to confirm: is signing out and signing in not enough?
>> According to Microsoft site: restart is required but I guess signing out/in 
>> should work too. Unfortunately I do not have Windows on hand to check it out.
>> 
>>> 
>>> I'd use backticks for gpedit markup: “Type `gpedit` in the Search…”
>>> 
>>> 
>>> Does it make sense to move the example into macOS section? Then the steps 
>>> to disable the shortcut can be reduced to the required option only. The 
>>> steps themselves should not be listed as code, i.e. no backticks.
>>> 
>>> (For my understanding, "Turn keyboard access on or off" turns off only one 
>>> specific shortcut, i.e. Ctrl+F1?)
>> Yes, that’s right. I have added clarification to the doc.
>> 
>>> 
>>> 
>>> Regards,
>>> Alexey