[9] Review request for 8166683: On macOS (Mac OS X) getting a ScreenMenuBar when not running "com.apple.laf.AquaLookAndFeel"

[Alexander Zvegintsev]

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8166683

This fix adds support for ScreenMenuBar for L's other than Aqua.

With this fix it is enabled by default if apple.laf.useScreenMenuBar 
property is true.


This behavior can be disabled by setting 
apple.laf.disableForcedScreenMenuBar property to true.


--
Thanks,
Alexander.

Re: Review Request For 8160766: [TEST_BUG] java/awt/Focus/DisposedWindow

[Sergey Bylokhov]

Hi, Ambarish
It seems that the different version was pushed:
http://hg.openjdk.java.net/jdk9/client/jdk/rev/88faebbdbf9b
The html file still present in ws, and caused a warning from jtreg, 
because two tests(in .java and .html files) have the same name.


On 27.10.16 18:21, Ambarish Rapte wrote:

Hi All,



Please review this test bug fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8160766



This is small fix to add waitForIdle & delay. Webrev.00
is for reference of minimal changes.

Webrev with minimum changes for review:
http://cr.openjdk.java.net/~arapte/8160766/webrev.00/



This is an applet based, so would be removing the applet.

Final Webrev without applet:
http://cr.openjdk.java.net/~arapte/8160766/webrev.01/



Regards,

Ambarish






--
Best regards, Sergey.

Re: Fix for JDK-8169043 : The task bar icon color is not blue

[Sergey Bylokhov]

Looks fine.

On 09.11.16 14:36, Ajit Ghaisas wrote:

Hi,

Request you to review a test fix.

Bug :   https://bugs.openjdk.java.net/browse/JDK-8169043
Fix : http://cr.openjdk.java.net/~aghaisas/8169043/webrev.0/

Changes are :
1) Test is made to be run on Windows only.
2) Pass/Fail status was not reported correctly. It has been corrected now.

Regards,
Ajit




--
Best regards, Sergey.

Fix for JDK-8169043 : The task bar icon color is not blue

[Ajit Ghaisas]

Hi,

Request you to review a test fix.

Bug :   https://bugs.openjdk.java.net/browse/JDK-8169043
Fix : http://cr.openjdk.java.net/~aghaisas/8169043/webrev.0/

Changes are :
1) Test is made to be run on Windows only.
2) Pass/Fail status was not reported correctly. It has been corrected now.

Regards,
Ajit

Re: [9] Review request for 8169355: Diacritics input works incorrectly on Windows if Spanish (Latin American) keyboard layout is used

[Semyon Sadetsky]

Looks good.

--Semyon


On 09.11.2016 13:36, dmitry markov wrote:

Hello,

Could you review a fix for jdk9, please?

bug: https://bugs.openjdk.java.net/browse/JDK-8169355
webrev: http://cr.openjdk.java.net/~dmarkov/8169355/webrev.00/

Problem description:
The new mechanism of dead keys detection and processing was introduced 
by JDK-8139189 . It 
uses MapVirtualKey() function to detect dead key combination. Also an 
output of MapVirtualKey() invocation is used as a value which is send 
with Java's KEY_PRESSED/KEY_RELEASED events. However if the mechanism, 
(i.e. WindowsKeyToJavaChar() function inside awtComponent.cpp) is 
called from the Java layer via JNI right after a keyboard layout has 
been changed, MapVirtualKey() returns a character value related to the 
previous keyboard layout.


Fix:
The function WindowsKeyToJavaChar() has to take into account the 
current keyboard layout, (i.e. MapVirtualKey() should be replaced with 
MapVirtualKeyEx()).


Note: the corresponding regression tests, (e.g. 
java/awt/InputMethods/DiacriticsTest/DiacriticsTest.html) passed on 
the build with fix.


Thanks,
Dmitry 

[9] Review request for 8169355: Diacritics input works incorrectly on Windows if Spanish (Latin American) keyboard layout is used

[dmitry markov]

Hello,

Could you review a fix for jdk9, please?

bug: https://bugs.openjdk.java.net/browse/JDK-8169355
webrev: http://cr.openjdk.java.net/~dmarkov/8169355/webrev.00/

Problem description:
The new mechanism of dead keys detection and processing was introduced 
by JDK-8139189 . It 
uses MapVirtualKey() function to detect dead key combination. Also an 
output of MapVirtualKey() invocation is used as a value which is send 
with Java's KEY_PRESSED/KEY_RELEASED events. However if the mechanism, 
(i.e. WindowsKeyToJavaChar() function inside awtComponent.cpp) is called 
from the Java layer via JNI right after a keyboard layout has been 
changed, MapVirtualKey() returns a character value related to the 
previous keyboard layout.


Fix:
The function WindowsKeyToJavaChar() has to take into account the current 
keyboard layout, (i.e. MapVirtualKey() should be replaced with 
MapVirtualKeyEx()).


Note: the corresponding regression tests, (e.g. 
java/awt/InputMethods/DiacriticsTest/DiacriticsTest.html) passed on the 
build with fix.


Thanks,
Dmitry