From alexey.ivanov at oracle.com  Tue Mar  1 10:51:32 2016
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 1 Mar 2016 13:51:32 +0300
Subject: <Swing Dev> [9] Review Request: 8147994 [macosx] JScrollPane
 jitters up/down during trackpad scrolling on MacOS/Aqua
In-Reply-To: <56D46070.2080808@oracle.com>
References: <56C20C60.6050204@oracle.com> <56D41C62.3090005@oracle.com>
	<56D46070.2080808@oracle.com>
Message-ID: <56D57434.1030007@oracle.com>

Hi Sergey,

On 29.02.2016 18:14, Sergey Bylokhov wrote:
> On 29.02.16 13:24, Alexey Ivanov wrote:
>> Hi Sergey,
>>
>> The fix looks good.
>>
>> Could you please make the frame disappear when the test completes?
>
> Yes, the new version:
> http://cr.openjdk.java.net/~serb/8147994/webrev.02

Looks good.
Thanks a lot!

--
Alexey

>
>
>>
>> Regards,
>> Alexey
>>
>> On 15.02.2016 20:35, Sergey Bylokhov wrote:
>>> Hello.
>>>
>>> Please review the fix for jdk9. It will be backported to jdk8.
>>>
>>> This fix is a rework of the fix for JDK-8033000:
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c2acbd0292f3
>>> https://bugs.openjdk.java.net/browse/JDK-8033000
>>>
>>> After the fix for JDK-8033000 all our L&F have the next wheel logic:
>>>   1 If shift is not pressed and vertical scroll bar is visible it
>>> should be scrolled.
>>>   2 If vertical scroll-bar is invisible then we should scroll
>>> horizontal scroll bar if possible.
>>>   3 If shift is pressed and horizontal scroll-bar is visible it should
>>> be scrolled, but if it is not visible then we should try vertical
>>> scroll-bar.
>>>
>>> Note that the step 3 was added in the JDK-8033000. This caused an
>>> issue which previously was reproduced in Aqua L&F only. When the user
>>> uses diagonal scroll(top+right) and the application has only vertical
>>> scroll-bar, then we try to scroll in opposite directions:
>>> - the top move generates the scroll down.
>>> - scroll to the right generate the wheel+shift, and since the
>>> horizontal scroll-bar is not visible-> scroll up is executed.
>>>
>>> In the fix the logic of step 3 is changed:
>>>   3 If shift is pressed and horizontal scroll-bar is visible it should
>>> be scrolled, otherwise do nothing.
>>>
>>> Testcase for JDK-8033000 is updated.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147994
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8147994/webrev.01
>>>
>>
>
>



From alexander.potochkin at oracle.com  Wed Mar  2 14:20:36 2016
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Wed, 2 Mar 2016 17:20:36 +0300
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
 minimal heigh of JTabbedPane with more tabs
In-Reply-To: <4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
Message-ID: <56D6F6B4.808@oracle.com>

Hello Avik

Let me make it clear I don't approve the proposed fix
and ask you to do additional evaluation.

Every LookAndFeel is different and it doesn't make much sense
to compare Metal LaF with AquaLaf.

The AquaLaf mimics the native MacOS controls and therefore look quite 
different from any other Lafs.

The bug you are fixing has the following subject
"Incorrect minimal heigh of JTabbedPane with more tabs"

Could you please fix exactly the problem with the minimal heights,
without changing the UI delegate class.

Thanks
alexp

> Gentle reminder. Please review this fix.
>
>> On 26-Feb-2016, at 10:39 am, Avik Niyogi <avik.niyogi at oracle.com 
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> The issue is with setting of TabbedPane*Scroll*Layout() for the 
>> option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>  and *not* TabbedPaneLayout() as which is the default.
>>
>> The minimum size fixes itself because the *ScrollLayout* check fails 
>> in *setTabLayoutPolicy*() for the pane. So the issue is with the call 
>> to set layout manager.
>> There are only two configurations that the *JTabbedPane* can exist in 
>> of which *SCROLL_TAB_LAYOUT* is one of them.
>>
>> Fixing the minimum size in *AquaTabbedPaneUI* will fix it for 
>> *TabbedPaneLayout*() only which is the *WRAP_TAB_LAYOUT*.
>>
>> Also, I have checked other implementations such as for *Metal* and 
>> *Motif* and *they have similar code for doing this process*.
>> Hence, with in-depth analysis, this fix has no other impact apart 
>> from this fix.
>>
>> In case the impact caused by this change has caused some definitive 
>> regressions, please mention them so they can be addressed. Thank you.
>>
>> With Regards,
>> Avik Niyogi
>>
>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin 
>>> <alexander.potochkin at oracle.com 
>>> <mailto:alexander.potochkin at oracle.com>> wrote:
>>>
>>> Hello Avik
>>>
>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific 
>>> for the AquaTabbedPaneUI.
>>> I don't think setting the layout manager from the base class is the 
>>> right solution here.
>>>
>>> If there is a problem with minimum size it should be fixed inside 
>>> the AquaTabbedPaneUI
>>>
>>> Thanks
>>> alexp
>>>
>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>> Hi All,
>>>>
>>>> Kindly review the bug fix for JDK 9.
>>>>
>>>> *Bug:*
>>>> https://bugs.openjdk.java.net/browse/JDK-8137169
>>>>
>>>> *Webrev:*
>>>>
>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>
>>>>
>>>> *Issue:*
>>>> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height 
>>>> causes incremental return of values.
>>>>
>>>> *Cause:*
>>>> The impact was caused by a major broken code within 
>>>> AquaTabbedPaneUI.java for createLayoutManager()
>>>>
>>>> *Fix:*
>>>> Major linking calls to super class fix done within 
>>>> createLayoutManager().
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160302/5dbe3b7d/attachment.html>

From alexander.potochkin at oracle.com  Wed Mar  2 14:54:12 2016
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Wed, 2 Mar 2016 17:54:12 +0300
Subject: <Swing Dev> [9] Review Request: 8147994 [macosx] JScrollPane
 jitters up/down during trackpad scrolling on MacOS/Aqua
In-Reply-To: <56D46070.2080808@oracle.com>
References: <56C20C60.6050204@oracle.com> <56D41C62.3090005@oracle.com>
	<56D46070.2080808@oracle.com>
Message-ID: <56D6FE94.2030900@oracle.com>

Hello Sergey

The fix looks good.
Please commit it to the repo soon!

Thanks a lot
alexp


On 2/29/2016 18:14, Sergey Bylokhov wrote:
> On 29.02.16 13:24, Alexey Ivanov wrote:
>> Hi Sergey,
>>
>> The fix looks good.
>>
>> Could you please make the frame disappear when the test completes?
>
> Yes, the new version:
> http://cr.openjdk.java.net/~serb/8147994/webrev.02
>
>>
>> Regards,
>> Alexey
>>
>> On 15.02.2016 20:35, Sergey Bylokhov wrote:
>>> Hello.
>>>
>>> Please review the fix for jdk9. It will be backported to jdk8.
>>>
>>> This fix is a rework of the fix for JDK-8033000:
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c2acbd0292f3
>>> https://bugs.openjdk.java.net/browse/JDK-8033000
>>>
>>> After the fix for JDK-8033000 all our L&F have the next wheel logic:
>>>   1 If shift is not pressed and vertical scroll bar is visible it
>>> should be scrolled.
>>>   2 If vertical scroll-bar is invisible then we should scroll
>>> horizontal scroll bar if possible.
>>>   3 If shift is pressed and horizontal scroll-bar is visible it should
>>> be scrolled, but if it is not visible then we should try vertical
>>> scroll-bar.
>>>
>>> Note that the step 3 was added in the JDK-8033000. This caused an
>>> issue which previously was reproduced in Aqua L&F only. When the user
>>> uses diagonal scroll(top+right) and the application has only vertical
>>> scroll-bar, then we try to scroll in opposite directions:
>>> - the top move generates the scroll down.
>>> - scroll to the right generate the wheel+shift, and since the
>>> horizontal scroll-bar is not visible-> scroll up is executed.
>>>
>>> In the fix the logic of step 3 is changed:
>>>   3 If shift is pressed and horizontal scroll-bar is visible it should
>>> be scrolled, otherwise do nothing.
>>>
>>> Testcase for JDK-8033000 is updated.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147994
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8147994/webrev.01
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Fri Mar  4 17:18:31 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 4 Mar 2016 20:18:31 +0300
Subject: <Swing Dev> [9] Review Request: 8151288 Generation of property
 files for gtk l&f can be skipped on win/osx
Message-ID: <56D9C367.4060606@oracle.com>

Hello,
Please review the small fix for jdk9.
  In the fix for JDK-8075277 [1] we removed gtk l&f on osx, but its 
property files still generates (but actually are not used during the build).
"PROP_SRC_DIRS" is a list of folders where the property files should be 
searched.

[1] https://bugs.openjdk.java.net/browse/JDK-8075277

Bug: https://bugs.openjdk.java.net/browse/JDK-8151288
Webrev can be found at: http://cr.openjdk.java.net/~serb/8151288/webrev.00

-- 
Best regards, Sergey.


From erik.joelsson at oracle.com  Fri Mar  4 18:03:18 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 4 Mar 2016 19:03:18 +0100
Subject: <Swing Dev> [9] Review Request: 8151288 Generation of property
 files for gtk l&f can be skipped on win/osx
In-Reply-To: <56D9C367.4060606@oracle.com>
References: <56D9C367.4060606@oracle.com>
Message-ID: <56D9CDE6.90609@oracle.com>

Looks ok.

/Erik

On 2016-03-04 18:18, Sergey Bylokhov wrote:
> Hello,
> Please review the small fix for jdk9.
>  In the fix for JDK-8075277 [1] we removed gtk l&f on osx, but its 
> property files still generates (but actually are not used during the 
> build).
> "PROP_SRC_DIRS" is a list of folders where the property files should 
> be searched.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8075277
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151288
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8151288/webrev.00
>



From semyon.sadetsky at oracle.com  Sat Mar  5 21:14:35 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Sun, 6 Mar 2016 00:14:35 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
Message-ID: <56DB4C3B.1060902@oracle.com>

Hello,

Please review fix for JDK9:

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

The fix contains GTK3 based implementation for Swing GTK LnF, AWT 
FileChooser for Linux and AWT Robot for Linux.
Also the new system property is added to request specific GTK version 
swing.gtk.version.

--Semyon


From avik.niyogi at oracle.com  Tue Mar  8 05:10:50 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 8 Mar 2016 10:40:50 +0530
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
	javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java
	fails with GTK LnF
Message-ID: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>

Hi All,

Kindly review the bug fix for JDK 9.

Bug:

https://bugs.openjdk.java.net/browse/JDK-8151282 <https://bugs.openjdk.java.net/browse/JDK-8151282>

Webrev:

http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/>

Issue:
The test case failed for GTK LAF.

Cause:
The test case was meant to be Mac specific and was missing a jtreg parameter

Fix:
Minor change to test case with @requires tag added to set the fix.

With Regards,
Avik Niyogi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160308/0772d786/attachment.html>

From avik.niyogi at oracle.com  Tue Mar  8 16:09:58 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 8 Mar 2016 21:39:58 +0530
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
	exception was raised entering Emoji into JTextArea
Message-ID: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>

Hi All,

Kindly review the bug fix for JDK 9.

Bug:

https://bugs.openjdk.java.net/browse/JDK-8148555 <https://bugs.openjdk.java.net/browse/JDK-8148555>

Webrev:

http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/>

Issue:
Emoji selection in Character Viewer was causing exception in JNI

Cause:
Emojis are considered to be of different class type (namely, NSConcreteMutableAttributedString) from NSString which other characters are because of a surrogate pair for them.

Fix:
Major changes done for condition of emojis in JNI. Albeit rendering is not yet supported, they will appear as blank ?Missing font? notation.
Also, added debug point in case of issue with glyph arrises.

With Regards,
Avik Niyogi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160308/5f6c8671/attachment.html>

From avik.niyogi at oracle.com  Tue Mar  8 16:21:34 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 8 Mar 2016 21:51:34 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <56D6F6B4.808@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
Message-ID: <01520179-6464-44E8-AC4A-95A53F044063@oracle.com>

Hi All,

Please review code changes done as with inputs provided.
http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/>

Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
In the new fix as provided, references to base class layout manager is removed in current solution.

With Regards,
Avik Niyogi

> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin <alexander.potochkin at oracle.com> wrote:
> 
> Hello Avik
> 
> Let me make it clear I don't approve the proposed fix
> and ask you to do additional evaluation.
> 
> Every LookAndFeel is different and it doesn't make much sense
> to compare Metal LaF with AquaLaf.
> 
> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
> 
> The bug you are fixing has the following subject 
> "Incorrect minimal heigh of JTabbedPane with more tabs"
> 
> Could you please fix exactly the problem with the minimal heights,
> without changing the UI delegate class.
> 
> Thanks
> alexp
> 
>> Gentle reminder. Please review this fix.
>> 
>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>> 
>>> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>  and not TabbedPaneLayout() as which is the default.
>>> 
>>> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
>>> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>>> 
>>> Fixing the minimum size in AquaTabbedPaneUI will fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>> 
>>> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
>>> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>>> 
>>> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>> 
>>>> Hello Avik
>>>> 
>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
>>>> I don't think setting the layout manager from the base class is the right solution here.
>>>> 
>>>> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
>>>> 
>>>> Thanks
>>>> alexp
>>>> 
>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the bug fix for JDK 9.
>>>>> 
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>>>> 
>>>>> Webrev:
>>>>> 
>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>
>>>>> 
>>>>> Issue:
>>>>> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>>>>> 
>>>>> Cause:
>>>>> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>>>>> 
>>>>> Fix:
>>>>> Major linking calls to super class fix done within createLayoutManager().
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160308/01dd94aa/attachment.html>

From rajeev.chamyal at oracle.com  Wed Mar  9 04:44:58 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 09 Mar 2016 10:14:58 +0530
Subject: <Swing Dev> Review request for JDK-8145896 JInternalFrame
 setMaximum before adding to desktop throws null pointer exception
In-Reply-To: <9f2eba3e-a1e2-400a-b251-d7769e403349@default>
References: <e9072916-7d94-4d7d-b90b-d79741458bd3@default>	<567AAC2C.4060203@oracle.com>	<55a23711-f731-458d-a4f9-c88718db88d8@default>	<5683F273.2000808@oracle.com>	<6c9af273-8385-4b40-8e11-83d1e0d8212f@default>
	<9f2eba3e-a1e2-400a-b251-d7769e403349@default>
Message-ID: <56DFAA4A.7060208@oracle.com>

Hello Sergey,

Could you please review the updated webrev.
http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/

Regards,
Rajeev Chamyal


On 11-01-2016 15:27, Rajeev Chamyal wrote:
> Hello Sergey,
>
> Could you please review the updated webrev.
> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Rajeev Chamyal
> Sent: 02 January 2016 11:46
> To: Sergey Bylokhov; swing-dev at openjdk.java.net
> Subject: RE: Review request for JDK-8145896 JInternalFrame setMaximum before adding to desktop throws null pointer exception
>
> Hello Sergey,
>
> Thanks for review I have updated webrev.
> There was one more issue with fix to fix it , I have updated BasicInternalFrameUI.java and added it to webrev.
> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 30 December 2015 20:34
> To: Rajeev Chamyal; Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8145896 JInternalFrame setMaximum before adding to desktop throws null pointer exception
>
> Hi, Rajeev.
> A few notes:
> - The "Rectangle desktopBounds = f.getParent().getBounds();" can reuse the new "c" variable.
> - Is the "JDesktopPane d = f.getDesktopPane();" is necessary? It seems that it is not used after the null check.
>
> On 30/12/15 10:30, Rajeev Chamyal wrote:
>> Hello All,
>>
>> I need one more review for this webrev.
>>
>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/
>> <http://cr.openjdk.java.net/%7Erchamyal/8145896/webrev.00/>
>>
>> Regards,
>>
>> Rajeev Chamyal
>>
>> *From:*Alexander Scherbatiy
>> *Sent:* 23 December 2015 19:44
>> *To:* Rajeev Chamyal
>> *Cc:* Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>> *Subject:* Re: Review request for JDK-8145896 JInternalFrame
>> setMaximum before adding to desktop throws null pointer exception
>>
>>
>>     The fix looks good to me.
>>
>>     Thanks,
>>     Alexandr.
>>
>> On 12/21/2015 3:09 PM, Rajeev Chamyal wrote:
>>
>>      Hello All,
>>
>>      Please review the following fix for Jdk9:
>>
>>      Bug: https://bugs.openjdk.java.net/browse/JDK-8145896
>>
>>      Webrev:http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/
>>      <http://cr.openjdk.java.net/%7Erchamyal/8145896/webrev.00/>
>>
>>      Issue: JInternalFrame setMaximum before adding to desktop throws
>>      null pointer exception
>>
>>      Cause: Null checks for parent and Desktop pane are missing
>>
>>      Fix: Added null checks for parent and desktop pane.
>>
>>      Verified the fix on windows,Ubuntu and Mac with all supported LAF.
>>
>>      Regards,
>>
>>      Rajeev Chamyal
>>
>
> --
> Best regards, Sergey.



From prem.balakrishnan at oracle.com  Wed Mar  9 06:59:11 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Tue, 8 Mar 2016 22:59:11 -0800 (PST)
Subject: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong
 background color with Win7+WindowsLnf
Message-ID: <ab4bee47-326c-407b-bf95-f6d546af6edf@default>

Hi,

Please review fix for JDK9,

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

Webrev: http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.00/

  

Issue:

JDesktopPane - Wrong background color with Win7+WindowsLnf

 

Cause:

Desktop.background property set to "win.desktop.backgroundColor"

 

Fix:

Changed Desktop.background property  to "win.mdi.backgroundColor"

 

 

Regards,
Prem

 

 

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160308/763b3da4/attachment.html>

From semyon.sadetsky at oracle.com  Wed Mar  9 08:19:16 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 9 Mar 2016 11:19:16 +0300
Subject: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong
 background color with Win7+WindowsLnf
In-Reply-To: <ab4bee47-326c-407b-bf95-f6d546af6edf@default>
References: <ab4bee47-326c-407b-bf95-f6d546af6edf@default>
Message-ID: <56DFDC84.8090406@oracle.com>

Hi Prem,

The fix looks good.
One remark to the test: it should not fail on platforms other than 
Windows but just skip testing and pass.

--Semyon

On 3/9/2016 9:59 AM, Prem Balakrishnan wrote:
>
> Hi*,*
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-7012008**
>
> *Webrev:*http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/7012008/webrev.00/>
>
> *Issue:*
>
> JDesktopPane - Wrong background color with Win7+WindowsLnf
>
> *Cause:*
>
> Desktop.background property set to "win.desktop.backgroundColor"
>
> *Fix:*
>
> Changed Desktop.background property  to "win.mdi.backgroundColor"
>
> Regards,
> Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160309/fbd5e998/attachment.html>

From rajeev.chamyal at oracle.com  Wed Mar  9 09:18:53 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 9 Mar 2016 01:18:53 -0800 (PST)
Subject: <Swing Dev> [9] Review request for JDK-8150225
 api/javax_swing/text/AbstractWriter/index_indent failed
Message-ID: <d57da090-134d-4840-87d5-fbfc73027061@default>

Hello All,

 

Please review the following fix for Jdk9:

 

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

Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/ http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/

 

Issue : JCK conformance test failed due to fix for bug JDK-7104635

 

Fix: Reverted the fix for JDK-7104635 and added a new method in HTMLWriter.java to check if P tag is within Pre tag.

Decrement indentation is skipped if P tag is with a Pre tag.

 

Regards,

Rajeev Chamyal

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160309/cc555ab5/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Mar  9 10:00:28 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 9 Mar 2016 13:00:28 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56DB4C3B.1060902@oracle.com>
References: <56DB4C3B.1060902@oracle.com>
Message-ID: <56DFF43C.8040708@oracle.com>

Hi, Semyon.
A few initial questions. Please confirm that the changes were build 
successfully on all platforms via jprt. I assume that jck passed after 
the fix.

On 06.03.16 0:14, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>
> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
> FileChooser for Linux and AWT Robot for Linux.
> Also the new system property is added to request specific GTK version
> swing.gtk.version.
>
> --Semyon


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Mar  9 10:23:59 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 9 Mar 2016 13:23:59 +0300
Subject: <Swing Dev> [9] Review request for JDK-8150225
 api/javax_swing/text/AbstractWriter/index_indent failed
In-Reply-To: <d57da090-134d-4840-87d5-fbfc73027061@default>
References: <d57da090-134d-4840-87d5-fbfc73027061@default>
Message-ID: <56DFF9BF.6080205@oracle.com>

Hi, Rajeev.
Please confirm that there are no new issues in the jck after this fix.

On 09.03.16 12:18, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225
>
> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/
> <http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/>
>
> Issue : JCK conformance test failed due to fix for bug JDK-7104635
>
> Fix: Reverted the fix for JDK-7104635 and added a new method in
> HTMLWriter.java to check if P tag is within Pre tag.
>
> Decrement indentation is skipped if P tag is with a Pre tag.
>
> Regards,
>
> Rajeev Chamyal
>


-- 
Best regards, Sergey.


From alexey.ivanov at oracle.com  Wed Mar  9 10:28:11 2016
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 9 Mar 2016 13:28:11 +0300
Subject: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong
 background color with Win7+WindowsLnf
In-Reply-To: <ab4bee47-326c-407b-bf95-f6d546af6edf@default>
References: <ab4bee47-326c-407b-bf95-f6d546af6edf@default>
Message-ID: <56DFFABB.7080901@oracle.com>

Hi Prem,

The fix itself looks good.
Yet I have some questions to the test.

Could you please place the comment with @test tag and other before the 
class declaration rather than before imports?
Could you place asterisk in front of each line in this comment block? It 
will look consistent with Java style doc comments and other tests.

Do you really need to create UI?
Wouldn't it be enough to create JDesktopPane and check its background 
color? I believe it will significantly simplify the test.

I think converting Color to ColorUIResource is unnecessary here. 
ColorUIResource is Color decorated with UIResource interface: 
Color.equals method does not take this distinction into account.

In main(), you can create and initialize the LaF array in one go.

In executeTest(), you should dispose mainFrame on EDT rather than on 
main thread. I'd recommend using finally block in run() to dispose 
mainFrame: it will handle both success and failure.

Additionally, you access variables from different threads. The way the 
code is written now does not guarantee memory consistency between the 
different threads, thus the test could fail or pass sporadically.

And I agree with Semyon, the test should fail on other platforms, you 
should just skip the test.


Regards,
Alexey

On 09.03.2016 9:59, Prem Balakrishnan wrote:
>
> Hi*,*
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-7012008**
>
> *Webrev:*http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/7012008/webrev.00/>
>
> *Issue:*
>
> JDesktopPane - Wrong background color with Win7+WindowsLnf
>
> *Cause:*
>
> Desktop.background property set to "win.desktop.backgroundColor"
>
> *Fix:*
>
> Changed Desktop.background property  to "win.mdi.backgroundColor"
>
> Regards,
> Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160309/feb8e39f/attachment.html>

From rajeev.chamyal at oracle.com  Wed Mar  9 10:28:14 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 9 Mar 2016 02:28:14 -0800 (PST)
Subject: <Swing Dev> [9] Review request for JDK-8150225
 api/javax_swing/text/AbstractWriter/index_indent failed
In-Reply-To: <56DFF9BF.6080205@oracle.com>
References: <d57da090-134d-4840-87d5-fbfc73027061@default>
	<56DFF9BF.6080205@oracle.com>
Message-ID: <195b6aa5-1959-467e-826b-ce98377e392a@default>

Hello Sergey,

I have run JCK tests for HTMLWriter and AbstractWriter with this fix and all passed.

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov 
Sent: 09 March 2016 15:54
To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed

Hi, Rajeev.
Please confirm that there are no new issues in the jck after this fix.

On 09.03.16 12:18, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225
>
> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/
> <http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/>
>
> Issue : JCK conformance test failed due to fix for bug JDK-7104635
>
> Fix: Reverted the fix for JDK-7104635 and added a new method in 
> HTMLWriter.java to check if P tag is within Pre tag.
>
> Decrement indentation is skipped if P tag is with a Pre tag.
>
> Regards,
>
> Rajeev Chamyal
>


--
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Wed Mar  9 12:30:47 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 9 Mar 2016 16:30:47 +0400
Subject: <Swing Dev> [9] Review request for 8151303 [macosx] [hidpi]
 JButton's low-res. icon is visible when clicking on it
Message-ID: <56E01777.1030202@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8151303
   webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00

   The AquaUtils does not take into account MultiResolutionImage for 
selected/disabled/lightened images generation.
   The fix also leaves the MultiResolutionCachedImage check because the 
base system icon size can be differ from the requested painted size.

   Thanks,
   Alexandr.


From Sergey.Bylokhov at oracle.com  Wed Mar  9 12:58:15 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 9 Mar 2016 15:58:15 +0300
Subject: <Swing Dev> [9] Review request for 8151303 [macosx] [hidpi]
 JButton's low-res. icon is visible when clicking on it
In-Reply-To: <56E01777.1030202@oracle.com>
References: <56E01777.1030202@oracle.com>
Message-ID: <56E01DE7.9040103@oracle.com>

Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to 
support this functionality? It seems that the number of usage of this 
check "image instanceof MultiResolutionImage" will grow over time.
I think that at least our own API should support MultiResolutionImage 
w/o such checks, otherwise the user will need to do the same.

cc 2d-dev

On 09.03.16 15:30, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>    bug: https://bugs.openjdk.java.net/browse/JDK-8151303
>    webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00
>
>    The AquaUtils does not take into account MultiResolutionImage for
> selected/disabled/lightened images generation.
>    The fix also leaves the MultiResolutionCachedImage check because the
> base system icon size can be differ from the requested painted size.
>
>    Thanks,
>    Alexandr.


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Mar  9 13:27:17 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 9 Mar 2016 16:27:17 +0300
Subject: <Swing Dev> Review request for JDK-8145896 JInternalFrame
 setMaximum before adding to desktop throws null pointer exception
In-Reply-To: <56DFAA4A.7060208@oracle.com>
References: <e9072916-7d94-4d7d-b90b-d79741458bd3@default>
	<567AAC2C.4060203@oracle.com>
	<55a23711-f731-458d-a4f9-c88718db88d8@default>
	<5683F273.2000808@oracle.com>
	<6c9af273-8385-4b40-8e11-83d1e0d8212f@default>
	<9f2eba3e-a1e2-400a-b251-d7769e403349@default>
	<56DFAA4A.7060208@oracle.com>
Message-ID: <56E024B5.3020009@oracle.com>

Hi, Rajeev.
The fix looks fine, but the test should be updated. JFrame is created on 
non-EDT thread. It is unclear what l&f we should test(some 
specific,all,default?).
This also can be simplified:
70         if (testFailed) {
   71             dispose();
   72             throw new RuntimeException("Test Failed");
   73         }
   74         dispose();

On 09.03.16 7:44, Rajeev Chamyal wrote:
> Hello Sergey,
>
> Could you please review the updated webrev.
> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>
> Regards,
> Rajeev Chamyal
>
>
> On 11-01-2016 15:27, Rajeev Chamyal wrote:
>> Hello Sergey,
>>
>> Could you please review the updated webrev.
>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Rajeev Chamyal
>> Sent: 02 January 2016 11:46
>> To: Sergey Bylokhov; swing-dev at openjdk.java.net
>> Subject: RE: Review request for JDK-8145896 JInternalFrame setMaximum
>> before adding to desktop throws null pointer exception
>>
>> Hello Sergey,
>>
>> Thanks for review I have updated webrev.
>> There was one more issue with fix to fix it , I have updated
>> BasicInternalFrameUI.java and added it to webrev.
>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: 30 December 2015 20:34
>> To: Rajeev Chamyal; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>> Subject: Re: Review request for JDK-8145896 JInternalFrame setMaximum
>> before adding to desktop throws null pointer exception
>>
>> Hi, Rajeev.
>> A few notes:
>> - The "Rectangle desktopBounds = f.getParent().getBounds();" can reuse
>> the new "c" variable.
>> - Is the "JDesktopPane d = f.getDesktopPane();" is necessary? It seems
>> that it is not used after the null check.
>>
>> On 30/12/15 10:30, Rajeev Chamyal wrote:
>>> Hello All,
>>>
>>> I need one more review for this webrev.
>>>
>>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/
>>> <http://cr.openjdk.java.net/%7Erchamyal/8145896/webrev.00/>
>>>
>>> Regards,
>>>
>>> Rajeev Chamyal
>>>
>>> *From:*Alexander Scherbatiy
>>> *Sent:* 23 December 2015 19:44
>>> *To:* Rajeev Chamyal
>>> *Cc:* Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>>> *Subject:* Re: Review request for JDK-8145896 JInternalFrame
>>> setMaximum before adding to desktop throws null pointer exception
>>>
>>>
>>>     The fix looks good to me.
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>> On 12/21/2015 3:09 PM, Rajeev Chamyal wrote:
>>>
>>>      Hello All,
>>>
>>>      Please review the following fix for Jdk9:
>>>
>>>      Bug: https://bugs.openjdk.java.net/browse/JDK-8145896
>>>
>>>      Webrev:http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/
>>>      <http://cr.openjdk.java.net/%7Erchamyal/8145896/webrev.00/>
>>>
>>>      Issue: JInternalFrame setMaximum before adding to desktop throws
>>>      null pointer exception
>>>
>>>      Cause: Null checks for parent and Desktop pane are missing
>>>
>>>      Fix: Added null checks for parent and desktop pane.
>>>
>>>      Verified the fix on windows,Ubuntu and Mac with all supported LAF.
>>>
>>>      Regards,
>>>
>>>      Rajeev Chamyal
>>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From rajeev.chamyal at oracle.com  Thu Mar 10 05:14:29 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 9 Mar 2016 21:14:29 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8145896 JInternalFrame
 setMaximum before adding to desktop throws null pointer exception
In-Reply-To: <56E024B5.3020009@oracle.com>
References: <e9072916-7d94-4d7d-b90b-d79741458bd3@default>
	<567AAC2C.4060203@oracle.com>
	<55a23711-f731-458d-a4f9-c88718db88d8@default>
	<5683F273.2000808@oracle.com>
	<6c9af273-8385-4b40-8e11-83d1e0d8212f@default>
	<9f2eba3e-a1e2-400a-b251-d7769e403349@default>
	<56DFAA4A.7060208@oracle.com> <56E024B5.3020009@oracle.com>
Message-ID: <11ef368c-38bb-4ec6-b0b3-6a245f0b1eb0@default>

Hello Sergey,

I have updated the test as per review comments.
http://cr.openjdk.java.net/~rchamyal/8145896/webrev.02/

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov 
Sent: 09 March 2016 18:57
To: Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review request for JDK-8145896 JInternalFrame setMaximum before adding to desktop throws null pointer exception

Hi, Rajeev.
The fix looks fine, but the test should be updated. JFrame is created on non-EDT thread. It is unclear what l&f we should test(some specific,all,default?).
This also can be simplified:
70         if (testFailed) {
   71             dispose();
   72             throw new RuntimeException("Test Failed");
   73         }
   74         dispose();

On 09.03.16 7:44, Rajeev Chamyal wrote:
> Hello Sergey,
>
> Could you please review the updated webrev.
> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>
> Regards,
> Rajeev Chamyal
>
>
> On 11-01-2016 15:27, Rajeev Chamyal wrote:
>> Hello Sergey,
>>
>> Could you please review the updated webrev.
>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Rajeev Chamyal
>> Sent: 02 January 2016 11:46
>> To: Sergey Bylokhov; swing-dev at openjdk.java.net
>> Subject: RE: Review request for JDK-8145896 JInternalFrame setMaximum 
>> before adding to desktop throws null pointer exception
>>
>> Hello Sergey,
>>
>> Thanks for review I have updated webrev.
>> There was one more issue with fix to fix it , I have updated 
>> BasicInternalFrameUI.java and added it to webrev.
>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: 30 December 2015 20:34
>> To: Rajeev Chamyal; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>> Subject: Re: Review request for JDK-8145896 JInternalFrame setMaximum 
>> before adding to desktop throws null pointer exception
>>
>> Hi, Rajeev.
>> A few notes:
>> - The "Rectangle desktopBounds = f.getParent().getBounds();" can 
>> reuse the new "c" variable.
>> - Is the "JDesktopPane d = f.getDesktopPane();" is necessary? It 
>> seems that it is not used after the null check.
>>
>> On 30/12/15 10:30, Rajeev Chamyal wrote:
>>> Hello All,
>>>
>>> I need one more review for this webrev.
>>>
>>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/
>>> <http://cr.openjdk.java.net/%7Erchamyal/8145896/webrev.00/>
>>>
>>> Regards,
>>>
>>> Rajeev Chamyal
>>>
>>> *From:*Alexander Scherbatiy
>>> *Sent:* 23 December 2015 19:44
>>> *To:* Rajeev Chamyal
>>> *Cc:* Sergey Bylokhov; Prasanta Sadhukhan; 
>>> swing-dev at openjdk.java.net
>>> *Subject:* Re: Review request for JDK-8145896 JInternalFrame 
>>> setMaximum before adding to desktop throws null pointer exception
>>>
>>>
>>>     The fix looks good to me.
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>> On 12/21/2015 3:09 PM, Rajeev Chamyal wrote:
>>>
>>>      Hello All,
>>>
>>>      Please review the following fix for Jdk9:
>>>
>>>      Bug: https://bugs.openjdk.java.net/browse/JDK-8145896
>>>
>>>      Webrev:http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/
>>>      <http://cr.openjdk.java.net/%7Erchamyal/8145896/webrev.00/>
>>>
>>>      Issue: JInternalFrame setMaximum before adding to desktop throws
>>>      null pointer exception
>>>
>>>      Cause: Null checks for parent and Desktop pane are missing
>>>
>>>      Fix: Added null checks for parent and desktop pane.
>>>
>>>      Verified the fix on windows,Ubuntu and Mac with all supported LAF.
>>>
>>>      Regards,
>>>
>>>      Rajeev Chamyal
>>>
>>
>> --
>> Best regards, Sergey.
>


--
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Thu Mar 10 06:04:07 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 10 Mar 2016 09:04:07 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56DFF43C.8040708@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56DFF43C.8040708@oracle.com>
Message-ID: <56E10E57.6060608@oracle.com>

Hi Sergey,

I confirm that it is built. I built it locally on Linux and Solaris.

--Semyon

On 3/9/2016 1:00 PM, Sergey Bylokhov wrote:
> Hi, Semyon.
> A few initial questions. Please confirm that the changes were build 
> successfully on all platforms via jprt. I assume that jck passed after 
> the fix.
>
> On 06.03.16 0:14, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>
>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>> FileChooser for Linux and AWT Robot for Linux.
>> Also the new system property is added to request specific GTK version
>> swing.gtk.version.
>>
>> --Semyon
>
>



From prem.balakrishnan at oracle.com  Thu Mar 10 06:45:19 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Wed, 9 Mar 2016 22:45:19 -0800 (PST)
Subject: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong
 background color with Win7+WindowsLnf
In-Reply-To: <56DFFABB.7080901@oracle.com>
References: <ab4bee47-326c-407b-bf95-f6d546af6edf@default>
	<56DFFABB.7080901@oracle.com>
Message-ID: <55e9e1d2-b385-442b-91df-ba520f6c7c87@default>

Hi Semyon and Alexey,

 

Thankyou for the Review.

 

I have updated the test as per review comments.

http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.01/ 

 

Regards,
Prem

 

 

From: Alexey Ivanov 
Sent: Wednesday, March 09, 2016 3:58 PM
To: Prem Balakrishnan; Rajeev Chamyal; Sergey Bylokhov; Semyon Sadetsky; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong background color with Win7+WindowsLnf

 

Hi Prem,

The fix itself looks good.
Yet I have some questions to the test.

Could you please place the comment with @test tag and other before the class declaration rather than before imports?
Could you place asterisk in front of each line in this comment block? It will look consistent with Java style doc comments and other tests.

Do you really need to create UI?
Wouldn't it be enough to create JDesktopPane and check its background color? I believe it will significantly simplify the test.

I think converting Color to ColorUIResource is unnecessary here. ColorUIResource is Color decorated with UIResource interface: Color.equals method does not take this distinction into account.

In main(), you can create and initialize the LaF array in one go.

In executeTest(), you should dispose mainFrame on EDT rather than on main thread. I'd recommend using finally block in run() to dispose mainFrame: it will handle both success and failure.

Additionally, you access variables from different threads. The way the code is written now does not guarantee memory consistency between the different threads, thus the test could fail or pass sporadically.

And I agree with Semyon, the test should fail on other platforms, you should just skip the test.


Regards,
Alexey

On 09.03.2016 9:59, Prem Balakrishnan wrote:

Hi,

Please review fix for JDK9,

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

Webrev: http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.00/

  

Issue:

JDesktopPane - Wrong background color with Win7+WindowsLnf

 

Cause:

Desktop.background property set to "win.desktop.backgroundColor"

 

Fix:

Changed Desktop.background property  to "win.mdi.backgroundColor"

 

 

Regards,
Prem

 

 

 

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160309/15513f6d/attachment.html>

From semyon.sadetsky at oracle.com  Thu Mar 10 06:54:34 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 10 Mar 2016 09:54:34 +0300
Subject: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong
 background color with Win7+WindowsLnf
In-Reply-To: <55e9e1d2-b385-442b-91df-ba520f6c7c87@default>
References: <ab4bee47-326c-407b-bf95-f6d546af6edf@default>
	<56DFFABB.7080901@oracle.com>
	<55e9e1d2-b385-442b-91df-ba520f6c7c87@default>
Message-ID: <56E11A2A.9080602@oracle.com>

Looks good.

--Semyon

On 3/10/2016 9:45 AM, Prem Balakrishnan wrote:
>
> Hi Semyon and Alexey,
>
> Thankyou for the Review.
>
> I have updated the test as per review comments.
>
> http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.01/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/7012008/webrev.01/>
>
> Regards,
> Prem
>
> *From:*Alexey Ivanov
> *Sent:* Wednesday, March 09, 2016 3:58 PM
> *To:* Prem Balakrishnan; Rajeev Chamyal; Sergey Bylokhov; Semyon 
> Sadetsky; swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - 
> Wrong background color with Win7+WindowsLnf
>
> Hi Prem,
>
> The fix itself looks good.
> Yet I have some questions to the test.
>
> Could you please place the comment with @test tag and other before the 
> class declaration rather than before imports?
> Could you place asterisk in front of each line in this comment block? 
> It will look consistent with Java style doc comments and other tests.
>
> Do you really need to create UI?
> Wouldn't it be enough to create JDesktopPane and check its background 
> color? I believe it will significantly simplify the test.
>
> I think converting Color to ColorUIResource is unnecessary here. 
> ColorUIResource is Color decorated with UIResource interface: 
> Color.equals method does not take this distinction into account.
>
> In main(), you can create and initialize the LaF array in one go.
>
> In executeTest(), you should dispose mainFrame on EDT rather than on 
> main thread. I'd recommend using finally block in run() to dispose 
> mainFrame: it will handle both success and failure.
>
> Additionally, you access variables from different threads. The way the 
> code is written now does not guarantee memory consistency between the 
> different threads, thus the test could fail or pass sporadically.
>
> And I agree with Semyon, the test should fail on other platforms, you 
> should just skip the test.
>
>
> Regards,
> Alexey
>
> On 09.03.2016 9:59, Prem Balakrishnan wrote:
>
>     Hi*,*
>
>     Please review fix for JDK9,
>
>     *Bug:*https://bugs.openjdk.java.net/browse/JDK-7012008**
>
>     *Webrev:*http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.00/ <http://cr.openjdk.java.net/%7Earapte/prem/7012008/webrev.00/>
>
>     *Issue:*
>
>     JDesktopPane - Wrong background color with Win7+WindowsLnf
>
>     *Cause:*
>
>     Desktop.background property set to "win.desktop.backgroundColor"
>
>     *Fix:*
>
>     Changed Desktop.background property  to "win.mdi.backgroundColor"
>
>     Regards,
>     Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160310/c59f0870/attachment.html>

From alexey.ivanov at oracle.com  Thu Mar 10 09:36:38 2016
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 10 Mar 2016 12:36:38 +0300
Subject: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong
 background color with Win7+WindowsLnf
In-Reply-To: <55e9e1d2-b385-442b-91df-ba520f6c7c87@default>
References: <ab4bee47-326c-407b-bf95-f6d546af6edf@default>
	<56DFFABB.7080901@oracle.com>
	<55e9e1d2-b385-442b-91df-ba520f6c7c87@default>
Message-ID: <56E14026.2090609@oracle.com>

Hi Prem,

Thank you for updating the test, it looks much simpler now.

Could you please move the comment with JTreg @test tags to the class 
declaration? I mean put it below imports.

The array of look-and-feels to test would be better readable if 
formatted like this:

         String[] lookAndFeel = new String[] {
             "com.sun.java.swing.plaf.windows.WindowsLookAndFeel",
"com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel"
         };

Don't you agree?

I'm sure the line
         desktopPane.setVisible(true)
is redundant in this case.

Why do you catch the four exceptions in main? I see no reason to catch 
any exceptions in main: an exception will fail the test and you will see 
the real problem rather than the generic message "Setting 
WindowsLookAndFeel Failed".


Just to confirm: Does the test pass on Linux or Mac?

I also suggest renaming 'lookAndFeel1' variable in loop to 'laf'.

Regards,
Alexey

On 10.03.2016 9:45, Prem Balakrishnan wrote:
>
> Hi Semyon and Alexey,
>
> Thankyou for the Review.
>
> I have updated the test as per review comments.
>
> http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.01/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/7012008/webrev.01/>
>
> Regards,
> Prem
>
> *From:*Alexey Ivanov
> *Sent:* Wednesday, March 09, 2016 3:58 PM
> *To:* Prem Balakrishnan; Rajeev Chamyal; Sergey Bylokhov; Semyon 
> Sadetsky; swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - 
> Wrong background color with Win7+WindowsLnf
>
> Hi Prem,
>
> The fix itself looks good.
> Yet I have some questions to the test.
>
> Could you please place the comment with @test tag and other before the 
> class declaration rather than before imports?
> Could you place asterisk in front of each line in this comment block? 
> It will look consistent with Java style doc comments and other tests.
>
> Do you really need to create UI?
> Wouldn't it be enough to create JDesktopPane and check its background 
> color? I believe it will significantly simplify the test.
>
> I think converting Color to ColorUIResource is unnecessary here. 
> ColorUIResource is Color decorated with UIResource interface: 
> Color.equals method does not take this distinction into account.
>
> In main(), you can create and initialize the LaF array in one go.
>
> In executeTest(), you should dispose mainFrame on EDT rather than on 
> main thread. I'd recommend using finally block in run() to dispose 
> mainFrame: it will handle both success and failure.
>
> Additionally, you access variables from different threads. The way the 
> code is written now does not guarantee memory consistency between the 
> different threads, thus the test could fail or pass sporadically.
>
> And I agree with Semyon, the test should fail on other platforms, you 
> should just skip the test.
>
>
> Regards,
> Alexey
>
> On 09.03.2016 9:59, Prem Balakrishnan wrote:
>
>     Hi*,*
>
>     Please review fix for JDK9,
>
>     *Bug:*https://bugs.openjdk.java.net/browse/JDK-7012008**
>
>     *Webrev:*http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.00/ <http://cr.openjdk.java.net/%7Earapte/prem/7012008/webrev.00/>
>
>     *Issue:*
>
>     JDesktopPane - Wrong background color with Win7+WindowsLnf
>
>     *Cause:*
>
>     Desktop.background property set to "win.desktop.backgroundColor"
>
>     *Fix:*
>
>     Changed Desktop.background property  to "win.mdi.backgroundColor"
>
>     Regards,
>     Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160310/b5a4aad4/attachment.html>

From prem.balakrishnan at oracle.com  Thu Mar 10 10:57:21 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 10 Mar 2016 02:57:21 -0800 (PST)
Subject: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong
 background color with Win7+WindowsLnf
In-Reply-To: <56E14026.2090609@oracle.com>
References: <ab4bee47-326c-407b-bf95-f6d546af6edf@default>
	<56DFFABB.7080901@oracle.com>
	<55e9e1d2-b385-442b-91df-ba520f6c7c87@default>
	<56E14026.2090609@oracle.com>
Message-ID: <c978c24a-ead6-413a-9540-52002fbe10c9@default>

Hi Alexey,

 

Updated the test as per review comments.

http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.02/ 

 

 

JTreg @test tags:

As per TAG SYNTAX, Test tags must be enclosed in a comment at the head of the file, refer below link

http://openjdk.java.net/jtreg/tag-spec.html#TAG_SYNTAX , 

and we are following the same conventions in all the JDK9 tests.

 

Just to confirm: Does the test pass on Linux or Mac?

@requires (os.family == "windows") is added to tag, 

which doesn't allow the following test to run on any other platform except windows.

(When executed using JTreg)

 

Regards,
Prem

 

 

 

From: Alexey Ivanov 
Sent: Thursday, March 10, 2016 3:07 PM
To: Prem Balakrishnan; Semyon Sadetsky; Rajeev Chamyal; Sergey Bylokhov; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong background color with Win7+WindowsLnf

 

Hi Prem,

Thank you for updating the test, it looks much simpler now.

Could you please move the comment with JTreg @test tags to the class declaration? I mean put it below imports.

The array of look-and-feels to test would be better readable if formatted like this:

        String[] lookAndFeel = new String[] {
            "com.sun.java.swing.plaf.windows.WindowsLookAndFeel",
            "com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel"
        };

Don't you agree?

I'm sure the line
        desktopPane.setVisible(true)
is redundant in this case.

Why do you catch the four exceptions in main? I see no reason to catch any exceptions in main: an exception will fail the test and you will see the real problem rather than the generic message "Setting WindowsLookAndFeel Failed".


Just to confirm: Does the test pass on Linux or Mac?

I also suggest renaming 'lookAndFeel1' variable in loop to 'laf'.

Regards,
Alexey

On 10.03.2016 9:45, Prem Balakrishnan wrote:

Hi Semyon and Alexey,

 

Thankyou for the Review.

 

I have updated the test as per review comments.

http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.01/ 

 

Regards,
Prem

 

 

From: Alexey Ivanov 
Sent: Wednesday, March 09, 2016 3:58 PM
To: Prem Balakrishnan; Rajeev Chamyal; Sergey Bylokhov; Semyon Sadetsky; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong background color with Win7+WindowsLnf

 

Hi Prem,

The fix itself looks good.
Yet I have some questions to the test.

Could you please place the comment with @test tag and other before the class declaration rather than before imports?
Could you place asterisk in front of each line in this comment block? It will look consistent with Java style doc comments and other tests.

Do you really need to create UI?
Wouldn't it be enough to create JDesktopPane and check its background color? I believe it will significantly simplify the test.

I think converting Color to ColorUIResource is unnecessary here. ColorUIResource is Color decorated with UIResource interface: Color.equals method does not take this distinction into account.

In main(), you can create and initialize the LaF array in one go.

In executeTest(), you should dispose mainFrame on EDT rather than on main thread. I'd recommend using finally block in run() to dispose mainFrame: it will handle both success and failure.

Additionally, you access variables from different threads. The way the code is written now does not guarantee memory consistency between the different threads, thus the test could fail or pass sporadically.

And I agree with Semyon, the test should fail on other platforms, you should just skip the test.


Regards,
Alexey

On 09.03.2016 9:59, Prem Balakrishnan wrote:

Hi,

Please review fix for JDK9,

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/prem/7012008/webrev.00/"http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.00/

  

Issue:

JDesktopPane - Wrong background color with Win7+WindowsLnf

 

Cause:

Desktop.background property set to "win.desktop.backgroundColor"

 

Fix:

Changed Desktop.background property  to "win.mdi.backgroundColor"

 

 

Regards,
Prem

 

 

 

 

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160310/fce2a99c/attachment.html>

From alexey.ivanov at oracle.com  Thu Mar 10 12:03:54 2016
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 10 Mar 2016 15:03:54 +0300
Subject: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - Wrong
 background color with Win7+WindowsLnf
In-Reply-To: <c978c24a-ead6-413a-9540-52002fbe10c9@default>
References: <ab4bee47-326c-407b-bf95-f6d546af6edf@default>
	<56DFFABB.7080901@oracle.com>
	<55e9e1d2-b385-442b-91df-ba520f6c7c87@default>
	<56E14026.2090609@oracle.com>
	<c978c24a-ead6-413a-9540-52002fbe10c9@default>
Message-ID: <56E162AA.5060708@oracle.com>

Hi Prem,

Looks good.
Thanks!

On 10.03.2016 13:57, Prem Balakrishnan wrote:
>
> Hi Alexey,
>
> Updated the test as per review comments.
>
> http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.02/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/7012008/webrev.02/>
>
> *JTreg @test tags:*
>
> As per TAG SYNTAX, Test tags must be enclosed in a comment at the head 
> of the file, refer below link
>
> *http://openjdk.java.net/jtreg/tag-spec.html#TAG_SYNTAX , *
>
> and we are following the same conventions in all the JDK9 tests.
>
I see. I remember I saw some tests had this JTreg tag comments before 
the class, and I find it more convenient because IDE doesn't collapse 
the comment automatically.
>
> *Just to confirm: Does the test pass on Linux or Mac?*
>
> *@requires (os.family == "windows") is added to tag, *
>
> which doesn?t allow the following test to run on any other platform 
> except windows.
>
> (When executed using JTreg)
>
Thanks! I haven't seen that notation before, I just wanted to be sure.


Regards,
Alexey
>
> Regards,
> Prem
>
> *From:*Alexey Ivanov
> *Sent:* Thursday, March 10, 2016 3:07 PM
> *To:* Prem Balakrishnan; Semyon Sadetsky; Rajeev Chamyal; Sergey 
> Bylokhov; swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> Review Request: JDK-7012008 JDesktopPane - 
> Wrong background color with Win7+WindowsLnf
>
> Hi Prem,
>
> Thank you for updating the test, it looks much simpler now.
>
> Could you please move the comment with JTreg @test tags to the class 
> declaration? I mean put it below imports.
>
> The array of look-and-feels to test would be better readable if 
> formatted like this:
>
>         String[] lookAndFeel = new String[] {
> "com.sun.java.swing.plaf.windows.WindowsLookAndFeel",
> "com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel"
>         };
>
> Don't you agree?
>
> I'm sure the line
>         desktopPane.setVisible(true)
> is redundant in this case.
>
> Why do you catch the four exceptions in main? I see no reason to catch 
> any exceptions in main: an exception will fail the test and you will 
> see the real problem rather than the generic message "Setting 
> WindowsLookAndFeel Failed".
>
>
> Just to confirm: Does the test pass on Linux or Mac?
>
> I also suggest renaming 'lookAndFeel1' variable in loop to 'laf'.
>
> Regards,
> Alexey
>
> On 10.03.2016 9:45, Prem Balakrishnan wrote:
>
>     Hi Semyon and Alexey,
>
>     Thankyou for the Review.
>
>     I have updated the test as per review comments.
>
>     http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.01/
>     <http://cr.openjdk.java.net/%7Earapte/prem/7012008/webrev.01/>
>
>     Regards,
>     Prem
>
>     *From:*Alexey Ivanov
>     *Sent:* Wednesday, March 09, 2016 3:58 PM
>     *To:* Prem Balakrishnan; Rajeev Chamyal; Sergey Bylokhov; Semyon
>     Sadetsky; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> Review Request: JDK-7012008
>     JDesktopPane - Wrong background color with Win7+WindowsLnf
>
>     Hi Prem,
>
>     The fix itself looks good.
>     Yet I have some questions to the test.
>
>     Could you please place the comment with @test tag and other before
>     the class declaration rather than before imports?
>     Could you place asterisk in front of each line in this comment
>     block? It will look consistent with Java style doc comments and
>     other tests.
>
>     Do you really need to create UI?
>     Wouldn't it be enough to create JDesktopPane and check its
>     background color? I believe it will significantly simplify the test.
>
>     I think converting Color to ColorUIResource is unnecessary here.
>     ColorUIResource is Color decorated with UIResource interface:
>     Color.equals method does not take this distinction into account.
>
>     In main(), you can create and initialize the LaF array in one go.
>
>     In executeTest(), you should dispose mainFrame on EDT rather than
>     on main thread. I'd recommend using finally block in run() to
>     dispose mainFrame: it will handle both success and failure.
>
>     Additionally, you access variables from different threads. The way
>     the code is written now does not guarantee memory consistency
>     between the different threads, thus the test could fail or pass
>     sporadically.
>
>     And I agree with Semyon, the test should fail on other platforms,
>     you should just skip the test.
>
>
>     Regards,
>     Alexey
>
>     On 09.03.2016 9:59, Prem Balakrishnan wrote:
>
>         Hi*,*
>
>         Please review fix for JDK9,
>
>         *Bug:*https://bugs.openjdk.java.net/browse/JDK-7012008**
>
>         *Webrev:*http://cr.openjdk.java.net/~arapte/prem/7012008/webrev.00/
>         <http://cr.openjdk.java.net/%7Earapte/prem/7012008/webrev.00/>
>
>         *Issue:*
>
>         JDesktopPane - Wrong background color with Win7+WindowsLnf
>
>         *Cause:*
>
>         Desktop.background property set to "win.desktop.backgroundColor"
>
>         *Fix:*
>
>         Changed Desktop.background property  to "win.mdi.backgroundColor"
>
>         Regards,
>         Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160310/5236bd50/attachment.html>

From alexandr.scherbatiy at oracle.com  Thu Mar 10 13:30:47 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Thu, 10 Mar 2016 05:30:47 -0800
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with
 GTK LnF
In-Reply-To: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
References: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
Message-ID: <56E17707.3070603@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 3/7/2016 9:10 PM, Avik Niyogi wrote:
> Hi All,
>
> Kindly review the bug fix for JDK 9.
>
> *Bug:*
>
> https://bugs.openjdk.java.net/browse/JDK-8151282
>
> *Webrev:*
>
> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.00/>_
> _
> _
> *Issue:*
> The test case failed for GTK LAF.
>
> *Cause:*
> The test case was meant to be Mac specific and was missing a jtreg 
> parameter
>
> *Fix:*
> Minor change to test case with @requires tag added to set the fix.
>
> With Regards,
> Avik Niyogi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160310/e1e0f9da/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Mar 10 13:52:52 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Mar 2016 16:52:52 +0300
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with
 GTK LnF
In-Reply-To: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
References: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
Message-ID: <56E17C34.5030303@oracle.com>

Hi, Avik.
A few questions.
  - Why webrev contains the new file?
- You marked the test as a mac specific but it is iterates over a bunch 
of l&fs. It seems it should not be OS specific, but should check some 
specific l&fs (which support such icons): Metal, Nimbus, Aqua, 
Windows(???). So gtk/motif should be skipped.

On 08.03.16 8:10, Avik Niyogi wrote:
> Hi All,
>
> Kindly review the bug fix for JDK 9.
>
> *Bug:*
>
> https://bugs.openjdk.java.net/browse/JDK-8151282
>
> *Webrev:*
>
> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
> _
> _
> *Issue:*
> The test case failed for GTK LAF.
>
> *Cause:*
> The test case was meant to be Mac specific and was missing a jtreg parameter
>
> *Fix:*
> Minor change to test case with @requires tag added to set the fix.
>
> With Regards,
> Avik Niyogi


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Mar 10 13:57:43 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Mar 2016 16:57:43 +0300
Subject: <Swing Dev> Review request for JDK-8145896 JInternalFrame
 setMaximum before adding to desktop throws null pointer exception
In-Reply-To: <11ef368c-38bb-4ec6-b0b3-6a245f0b1eb0@default>
References: <e9072916-7d94-4d7d-b90b-d79741458bd3@default>
	<567AAC2C.4060203@oracle.com>
	<55a23711-f731-458d-a4f9-c88718db88d8@default>
	<5683F273.2000808@oracle.com>
	<6c9af273-8385-4b40-8e11-83d1e0d8212f@default>
	<9f2eba3e-a1e2-400a-b251-d7769e403349@default>
	<56DFAA4A.7060208@oracle.com> <56E024B5.3020009@oracle.com>
	<11ef368c-38bb-4ec6-b0b3-6a245f0b1eb0@default>
Message-ID: <56E17D57.60002@oracle.com>

Looks fine.

On 10.03.16 8:14, Rajeev Chamyal wrote:
> Hello Sergey,
>
> I have updated the test as per review comments.
> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.02/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 09 March 2016 18:57
> To: Rajeev Chamyal; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> Review request for JDK-8145896 JInternalFrame setMaximum before adding to desktop throws null pointer exception
>
> Hi, Rajeev.
> The fix looks fine, but the test should be updated. JFrame is created on non-EDT thread. It is unclear what l&f we should test(some specific,all,default?).
> This also can be simplified:
> 70         if (testFailed) {
>     71             dispose();
>     72             throw new RuntimeException("Test Failed");
>     73         }
>     74         dispose();
>
> On 09.03.16 7:44, Rajeev Chamyal wrote:
>> Hello Sergey,
>>
>> Could you please review the updated webrev.
>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>>
>> Regards,
>> Rajeev Chamyal
>>
>>
>> On 11-01-2016 15:27, Rajeev Chamyal wrote:
>>> Hello Sergey,
>>>
>>> Could you please review the updated webrev.
>>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Rajeev Chamyal
>>> Sent: 02 January 2016 11:46
>>> To: Sergey Bylokhov; swing-dev at openjdk.java.net
>>> Subject: RE: Review request for JDK-8145896 JInternalFrame setMaximum
>>> before adding to desktop throws null pointer exception
>>>
>>> Hello Sergey,
>>>
>>> Thanks for review I have updated webrev.
>>> There was one more issue with fix to fix it , I have updated
>>> BasicInternalFrameUI.java and added it to webrev.
>>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.01/
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: 30 December 2015 20:34
>>> To: Rajeev Chamyal; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>>> Subject: Re: Review request for JDK-8145896 JInternalFrame setMaximum
>>> before adding to desktop throws null pointer exception
>>>
>>> Hi, Rajeev.
>>> A few notes:
>>> - The "Rectangle desktopBounds = f.getParent().getBounds();" can
>>> reuse the new "c" variable.
>>> - Is the "JDesktopPane d = f.getDesktopPane();" is necessary? It
>>> seems that it is not used after the null check.
>>>
>>> On 30/12/15 10:30, Rajeev Chamyal wrote:
>>>> Hello All,
>>>>
>>>> I need one more review for this webrev.
>>>>
>>>> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Erchamyal/8145896/webrev.00/>
>>>>
>>>> Regards,
>>>>
>>>> Rajeev Chamyal
>>>>
>>>> *From:*Alexander Scherbatiy
>>>> *Sent:* 23 December 2015 19:44
>>>> *To:* Rajeev Chamyal
>>>> *Cc:* Sergey Bylokhov; Prasanta Sadhukhan;
>>>> swing-dev at openjdk.java.net
>>>> *Subject:* Re: Review request for JDK-8145896 JInternalFrame
>>>> setMaximum before adding to desktop throws null pointer exception
>>>>
>>>>
>>>>      The fix looks good to me.
>>>>
>>>>      Thanks,
>>>>      Alexandr.
>>>>
>>>> On 12/21/2015 3:09 PM, Rajeev Chamyal wrote:
>>>>
>>>>       Hello All,
>>>>
>>>>       Please review the following fix for Jdk9:
>>>>
>>>>       Bug: https://bugs.openjdk.java.net/browse/JDK-8145896
>>>>
>>>>       Webrev:http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/
>>>>       <http://cr.openjdk.java.net/%7Erchamyal/8145896/webrev.00/>
>>>>
>>>>       Issue: JInternalFrame setMaximum before adding to desktop throws
>>>>       null pointer exception
>>>>
>>>>       Cause: Null checks for parent and Desktop pane are missing
>>>>
>>>>       Fix: Added null checks for parent and desktop pane.
>>>>
>>>>       Verified the fix on windows,Ubuntu and Mac with all supported LAF.
>>>>
>>>>       Regards,
>>>>
>>>>       Rajeev Chamyal
>>>>
>>>
>>> --
>>> Best regards, Sergey.
>>
>
>
> --
> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Mar 10 20:35:04 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Mar 2016 23:35:04 +0300
Subject: <Swing Dev> [9] Review Request: 8144166 [macosx] Test
 java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java
 fails
Message-ID: <56E1DA78.1080000@oracle.com>

Hello.
Please review the fix for jdk9.

Problem description:
  - CompEventOnHiddenComponent test was written not according the 
specification but according an assumption(performance related) - "the 
component should not post move/resize events if no listeners were 
registered". The test creates a JInternalFrame and adds 
ComponentListener to it. No events should come to the listeners, because 
the frame is not resized or moved by the test(except initial layout). 
Initial move/resize events are skipped usually, because during 
initialization there are no any listeners. But this is not the case in 
Aqua. AquaInternalFrameDockIconUI adds a listeners to the JInternalFrame 
during initialization -> move/resize events are posted -> the test adds 
own listeners -> events dispatched -> the test listeners called -> boom.

According above description the bug could be closed as not a defect. But 
I found another related problem in the AquaInternalFrameDockIconUI.

  - These component listeners in AquaInternalFrameDockIconUI are used to 
maintain the cache of image for the dock(the icon which is used when the 
internal frame is minimized). The logic is next:
    * Before the frame will be minimized it draws to the special 
ImageIcon which will be used as an icon for the dock.
    * After the frame is minimized and dock is showing the saved image 
will be used(and placed to the cache)
    * If the frame will be resized/show the cache will be reset.
    * When in the next time the same frame will be minimized the cached 
image will be used.

The bug is in the last step. When the frame will be minimized in the 
second time, it can have another content. But minimized icon will show 
the miniature from the previous minimization. Note this is the only step 
where the cache is used.

Solution:
As a solution all cache related stuff were dropped. The new test was added.


Bug: https://bugs.openjdk.java.net/browse/JDK-8144166
Webrev can be found at: http://cr.openjdk.java.net/~serb/8144166/webrev.01

-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Fri Mar 11 06:30:14 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 11 Mar 2016 09:30:14 +0300
Subject: <Swing Dev> [9] Review Request: 8144166 [macosx] Test
 java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java
 fails
In-Reply-To: <56E1DA78.1080000@oracle.com>
References: <56E1DA78.1080000@oracle.com>
Message-ID: <56E265F6.5020800@oracle.com>

Hi Sergey,

Could you explain why do you suppose that the icon cannot be requested 
more then once between the frame minimize and restore?

 > The bug is in the last step. When the frame will be minimized in the 
second time, it can have another content. But minimized icon
 > will show the miniature from the previous minimization...
Doesn't it contradict with :
 >    * If the frame will be resized/show the cache will be reset.
?

--Semyon

On 3/10/2016 11:35 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk9.
>
> Problem description:
>  - CompEventOnHiddenComponent test was written not according the 
> specification but according an assumption(performance related) - "the 
> component should not post move/resize events if no listeners were 
> registered". The test creates a JInternalFrame and adds 
> ComponentListener to it. No events should come to the listeners, 
> because the frame is not resized or moved by the test(except initial 
> layout). Initial move/resize events are skipped usually, because 
> during initialization there are no any listeners. But this is not the 
> case in Aqua. AquaInternalFrameDockIconUI adds a listeners to the 
> JInternalFrame during initialization -> move/resize events are posted 
> -> the test adds own listeners -> events dispatched -> the test 
> listeners called -> boom.
>
> According above description the bug could be closed as not a defect. 
> But I found another related problem in the AquaInternalFrameDockIconUI.
>
>  - These component listeners in AquaInternalFrameDockIconUI are used 
> to maintain the cache of image for the dock(the icon which is used 
> when the internal frame is minimized). The logic is next:
>    * Before the frame will be minimized it draws to the special 
> ImageIcon which will be used as an icon for the dock.
>    * After the frame is minimized and dock is showing the saved image 
> will be used(and placed to the cache)
>    * If the frame will be resized/show the cache will be reset.
>    * When in the next time the same frame will be minimized the cached 
> image will be used.
>
> The bug is in the last step. When the frame will be minimized in the 
> second time, it can have another content. But minimized icon will show 
> the miniature from the previous minimization. Note this is the only 
> step where the cache is used.
>
> Solution:
> As a solution all cache related stuff were dropped. The new test was 
> added.
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144166
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8144166/webrev.01
>



From Sergey.Bylokhov at oracle.com  Fri Mar 11 09:40:19 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 11 Mar 2016 12:40:19 +0300
Subject: <Swing Dev> [9] Review Request: 8144166 [macosx] Test
 java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java
 fails
In-Reply-To: <56E265F6.5020800@oracle.com>
References: <56E1DA78.1080000@oracle.com> <56E265F6.5020800@oracle.com>
Message-ID: <56E29283.9060906@oracle.com>

On 11.03.16 9:30, Semyon Sadetsky wrote:
> Hi Sergey,
>
> Could you explain why do you suppose that the icon cannot be requested
> more then once between the frame minimize and restore?

Every time when the frame is minimized the new 
AquaInternalFrameDockIconUI is created. Every 
AquaInternalFrameDockIconUI have its own ScaledImageLabel(which is 
JLabel). At the beginning this label is initialized by the icon from the 
cache, and this label is used until the frame is restored(cache is not 
used).

>
>  > The bug is in the last step. When the frame will be minimized in the
> second time, it can have another content. But minimized icon
>  > will show the miniature from the previous minimization...
> Doesn't it contradict with :
>  >    * If the frame will be resized/show the cache will be reset.
> ?
>
> --Semyon
>
> On 3/10/2016 11:35 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk9.
>>
>> Problem description:
>>  - CompEventOnHiddenComponent test was written not according the
>> specification but according an assumption(performance related) - "the
>> component should not post move/resize events if no listeners were
>> registered". The test creates a JInternalFrame and adds
>> ComponentListener to it. No events should come to the listeners,
>> because the frame is not resized or moved by the test(except initial
>> layout). Initial move/resize events are skipped usually, because
>> during initialization there are no any listeners. But this is not the
>> case in Aqua. AquaInternalFrameDockIconUI adds a listeners to the
>> JInternalFrame during initialization -> move/resize events are posted
>> -> the test adds own listeners -> events dispatched -> the test
>> listeners called -> boom.
>>
>> According above description the bug could be closed as not a defect.
>> But I found another related problem in the AquaInternalFrameDockIconUI.
>>
>>  - These component listeners in AquaInternalFrameDockIconUI are used
>> to maintain the cache of image for the dock(the icon which is used
>> when the internal frame is minimized). The logic is next:
>>    * Before the frame will be minimized it draws to the special
>> ImageIcon which will be used as an icon for the dock.
>>    * After the frame is minimized and dock is showing the saved image
>> will be used(and placed to the cache)
>>    * If the frame will be resized/show the cache will be reset.
>>    * When in the next time the same frame will be minimized the cached
>> image will be used.
>>
>> The bug is in the last step. When the frame will be minimized in the
>> second time, it can have another content. But minimized icon will show
>> the miniature from the previous minimization. Note this is the only
>> step where the cache is used.
>>
>> Solution:
>> As a solution all cache related stuff were dropped. The new test was
>> added.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144166
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8144166/webrev.01
>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Fri Mar 11 13:42:39 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 11 Mar 2016 17:42:39 +0400
Subject: <Swing Dev> [9] Review request for 8151303 [macosx] [hidpi]
 JButton's low-res. icon is visible when clicking on it
In-Reply-To: <56E01DE7.9040103@oracle.com>
References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com>
Message-ID: <56E2CB4F.6040301@oracle.com>

On 09/03/16 16:58, Sergey Bylokhov wrote:
> Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to 
> support this functionality? It seems that the number of usage of this 
> check "image instanceof MultiResolutionImage" will grow over time.
    ImageProducer produces pixels for an image and is not able to take 
an information about the image resolution variants.

  May be we can add Toolkit.createImage(Image image, ImageFilter 
imageFilter) method which takes MultiResolutionImage into account to 
cover the common case where filtered image is created.

  Thanks,
  Alexandr.
> I think that at least our own API should support MultiResolutionImage 
> w/o such checks, otherwise the user will need to do the same.
>
> cc 2d-dev
>
> On 09.03.16 15:30, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>    bug: https://bugs.openjdk.java.net/browse/JDK-8151303
>>    webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00
>>
>>    The AquaUtils does not take into account MultiResolutionImage for
>> selected/disabled/lightened images generation.
>>    The fix also leaves the MultiResolutionCachedImage check because the
>> base system icon size can be differ from the requested painted size.
>>
>>    Thanks,
>>    Alexandr.
>
>



From james.graham at oracle.com  Fri Mar 11 20:15:55 2016
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 11 Mar 2016 12:15:55 -0800
Subject: <Swing Dev> [OpenJDK 2D-Dev] [9] Review request for 8151303
 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it
In-Reply-To: <56E2CB4F.6040301@oracle.com>
References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com>
	<56E2CB4F.6040301@oracle.com>
Message-ID: <56E3277B.3000309@oracle.com>

Is this tied in with ImageFilter/FilteredImageSource?

It looks like since FIS takes only a Producer, it has lost the handle to 
the image to get a source for a particular resolution.  What happens if 
we introduce MultiResolution[Image]Producer?  It would provide a single 
method that would mimic <OriginalImage>.getRV().getProducer()?

I imagine this would greatly complicate the internals of ToolkitImage to 
support this, though...

			...jim

On 3/11/16 5:42 AM, Alexander Scherbatiy wrote:
> On 09/03/16 16:58, Sergey Bylokhov wrote:
>> Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to
>> support this functionality? It seems that the number of usage of this
>> check "image instanceof MultiResolutionImage" will grow over time.
>     ImageProducer produces pixels for an image and is not able to take
> an information about the image resolution variants.
>
>   May be we can add Toolkit.createImage(Image image, ImageFilter
> imageFilter) method which takes MultiResolutionImage into account to
> cover the common case where filtered image is created.
>
>   Thanks,
>   Alexandr.
>> I think that at least our own API should support MultiResolutionImage
>> w/o such checks, otherwise the user will need to do the same.
>>
>> cc 2d-dev
>>
>> On 09.03.16 15:30, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8151303
>>>    webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00
>>>
>>>    The AquaUtils does not take into account MultiResolutionImage for
>>> selected/disabled/lightened images generation.
>>>    The fix also leaves the MultiResolutionCachedImage check because the
>>> base system icon size can be differ from the requested painted size.
>>>
>>>    Thanks,
>>>    Alexandr.
>>
>>
>


From avik.niyogi at oracle.com  Mon Mar 14 05:04:59 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 14 Mar 2016 10:34:59 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
Message-ID: <26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>

Hi All,
A gentle reminder, please review code changes.

With Regards,
Avik Niyogi
> On 08-Mar-2016, at 9:51 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi All,
> 
> Please review code changes done as with inputs provided.
> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/>
> 
> Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
> In the new fix as provided, references to base class layout manager is removed in current solution.
> 
> With Regards,
> Avik Niyogi
> 
>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin <alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>> 
>> Hello Avik
>> 
>> Let me make it clear I don't approve the proposed fix
>> and ask you to do additional evaluation.
>> 
>> Every LookAndFeel is different and it doesn't make much sense
>> to compare Metal LaF with AquaLaf.
>> 
>> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
>> 
>> The bug you are fixing has the following subject 
>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>> 
>> Could you please fix exactly the problem with the minimal heights,
>> without changing the UI delegate class.
>> 
>> Thanks
>> alexp
>> 
>>> Gentle reminder. Please review this fix.
>>> 
>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>> 
>>>> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>  and not TabbedPaneLayout() as which is the default.
>>>> 
>>>> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
>>>> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>>>> 
>>>> Fixing the minimum size in AquaTabbedPaneUI will fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>>> 
>>>> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
>>>> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>>>> 
>>>> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>> 
>>>>> Hello Avik
>>>>> 
>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
>>>>> I don't think setting the layout manager from the base class is the right solution here.
>>>>> 
>>>>> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
>>>>> 
>>>>> Thanks
>>>>> alexp
>>>>> 
>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> Kindly review the bug fix for JDK 9.
>>>>>> 
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>>>>> 
>>>>>> Webrev:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>
>>>>>> 
>>>>>> Issue:
>>>>>> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>>>>>> 
>>>>>> Cause:
>>>>>> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>>>>>> 
>>>>>> Fix:
>>>>>> Major linking calls to super class fix done within createLayoutManager().
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160314/9104df6c/attachment.html>

From avik.niyogi at oracle.com  Mon Mar 14 05:05:51 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 14 Mar 2016 10:35:51 +0530
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
	exception was raised entering Emoji into JTextArea
In-Reply-To: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
Message-ID: <0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>

Hi All,
A gentle reminder, please review my code changes.

With Regards,
Avik Niyogi
> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi All,
> 
> Kindly review the bug fix for JDK 9.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8148555 <https://bugs.openjdk.java.net/browse/JDK-8148555>
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/>
> 
> Issue:
> Emoji selection in Character Viewer was causing exception in JNI
> 
> Cause:
> Emojis are considered to be of different class type (namely, NSConcreteMutableAttributedString) from NSString which other characters are because of a surrogate pair for them.
> 
> Fix:
> Major changes done for condition of emojis in JNI. Albeit rendering is not yet supported, they will appear as blank ?Missing font? notation.
> Also, added debug point in case of issue with glyph arrises.
> 
> With Regards,
> Avik Niyogi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160314/ed3fda12/attachment.html>

From avik.niyogi at oracle.com  Mon Mar 14 05:23:39 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 14 Mar 2016 10:53:39 +0530
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
	javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java
	fails with GTK LnF
In-Reply-To: <56E17C34.5030303@oracle.com>
References: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
	<56E17C34.5030303@oracle.com>
Message-ID: <8AE0341F-6D3A-4586-B7CC-38318B986450@oracle.com>

Hi Sergey,
Seems like it is a delay issue. Will submit test case with a waitForIdle() fix.

With Regards,
Avik Niyogi
> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Avik.
> A few questions.
> - Why webrev contains the new file?
> - You marked the test as a mac specific but it is iterates over a bunch of l&fs. It seems it should not be OS specific, but should check some specific l&fs (which support such icons): Metal, Nimbus, Aqua, Windows(???). So gtk/motif should be skipped.
> 
> On 08.03.16 8:10, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the bug fix for JDK 9.
>> 
>> *Bug:*
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8151282
>> 
>> *Webrev:*
>> 
>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
>> _
>> _
>> *Issue:*
>> The test case failed for GTK LAF.
>> 
>> *Cause:*
>> The test case was meant to be Mac specific and was missing a jtreg parameter
>> 
>> *Fix:*
>> Minor change to test case with @requires tag added to set the fix.
>> 
>> With Regards,
>> Avik Niyogi
> 
> 
> -- 
> Best regards, Sergey.



From semyon.sadetsky at oracle.com  Mon Mar 14 11:29:06 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 14 Mar 2016 14:29:06 +0300
Subject: <Swing Dev> [9] Review request for 8149631: rgb(...) CSS color
 values are not parsed properly
Message-ID: <56E6A082.8040405@oracle.com>

Hello,

Please review fix for JDK9:

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

The issue is a regression of 4419748 which added support for border 
sides but it parse the rgb(...) color values wrong. Also before 4419748 
the parenthesis notations worked only for CSS attribute that is not 
expected to contain several values. The reason is splitting the 
multi-value CSS attribute (for example, "background: rgb(0, 0, 0) url( 
'b.gif' ) no-repeat;") using space divider didn't take into account that 
spaces within parenthesis should not be used as top-level dividers.
Fixing the value splitting should correct the situation for (...) 
entries in all multi-value CSS attributes.

--Semyon


From alexandr.scherbatiy at oracle.com  Mon Mar 14 12:23:08 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 14 Mar 2016 15:23:08 +0300
Subject: <Swing Dev> RfR, JDK-8145228 , Java Access Bridge,
 getAccessibleStatesStringFromContext doesn't wrap the call to
 getAccessibleRole
In-Reply-To: <CAFcJ+g4q12+++_DtS+iEJf=ifLiObBaGF_4Wr=-+n=k_5ETPpQ@mail.gmail.com>
References: <56D4ABAB.8080504@oracle.com>
	<CAFcJ+g4q12+++_DtS+iEJf=ifLiObBaGF_4Wr=-+n=k_5ETPpQ@mail.gmail.com>
Message-ID: <56E6AD2C.5030505@oracle.com>



  The fix looks good to me.

  There is a small comment about code formatting.
  I believe that according to the new Java Style Guidelines where should 
not be a space between open brackets "( ()"
http://cr.openjdk.java.net/~alundblad/styleguide/#toc-lambda-expressions

  Thanks,
  Alexandr.

On 3/1/2016 2:18 AM, Renaud Paquay wrote:
> looks good to me -- assuming it is ok to use lambda syntax in this 
> file, the rest of the file still uses the anonymous inner class syntax.
>
> On Mon, Feb 29, 2016 at 12:35 PM, Pete Brunet <peter.brunet at oracle.com 
> <mailto:peter.brunet at oracle.com>> wrote:
>
>     Please review this change which runs code on the EDT like it
>     should have.
>
>     http://cr.openjdk.java.net/~ptbrunet/JDK-8145228/webrev.00/
>     <http://cr.openjdk.java.net/%7Eptbrunet/JDK-8145228/webrev.00/>
>
>



From avik.niyogi at oracle.com  Mon Mar 14 12:25:23 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 14 Mar 2016 17:55:23 +0530
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
	javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java
	fails with GTK LnF
In-Reply-To: <8AE0341F-6D3A-4586-B7CC-38318B986450@oracle.com>
References: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
	<56E17C34.5030303@oracle.com>
	<8AE0341F-6D3A-4586-B7CC-38318B986450@oracle.com>
Message-ID: <2DD39FDD-D8C9-47B6-BAAB-D1AEA0A22DF6@oracle.com>

Hi All,
Please review code changes made as per inputs provided.

http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/>
With Regards,
Avik Niyogi
> On 14-Mar-2016, at 10:53 am, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi Sergey,
> Seems like it is a delay issue. Will submit test case with a waitForIdle() fix.
> 
> With Regards,
> Avik Niyogi
>> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>> 
>> Hi, Avik.
>> A few questions.
>> - Why webrev contains the new file?
>> - You marked the test as a mac specific but it is iterates over a bunch of l&fs. It seems it should not be OS specific, but should check some specific l&fs (which support such icons): Metal, Nimbus, Aqua, Windows(???). So gtk/motif should be skipped.
>> 
>> On 08.03.16 8:10, Avik Niyogi wrote:
>>> Hi All,
>>> 
>>> Kindly review the bug fix for JDK 9.
>>> 
>>> *Bug:*
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8151282
>>> 
>>> *Webrev:*
>>> 
>>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
>>> _
>>> _
>>> *Issue:*
>>> The test case failed for GTK LAF.
>>> 
>>> *Cause:*
>>> The test case was meant to be Mac specific and was missing a jtreg parameter
>>> 
>>> *Fix:*
>>> Minor change to test case with @requires tag added to set the fix.
>>> 
>>> With Regards,
>>> Avik Niyogi
>> 
>> 
>> -- 
>> Best regards, Sergey.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160314/89660e72/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Mar 14 13:18:02 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 14 Mar 2016 16:18:02 +0300
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
 exception was raised entering Emoji into JTextArea
In-Reply-To: <0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
Message-ID: <56E6BA0A.10301@oracle.com>

Hi, Avik.
Can you please take a look to these two tests before fixing this bug:

TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
--------------------------------------------------
TEST: 
javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java

I remember they passed on jdk8, but it seems we have a regression in 
jdk9 and both of them fail.

On 14.03.16 8:05, Avik Niyogi wrote:
> Hi All,
> A gentle reminder, please review my code changes.
>
> With Regards,
> Avik Niyogi
>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi All,
>>
>> Kindly review the bug fix for JDK 9.
>>
>> *Bug:*
>>
>> _https://bugs.openjdk.java.net/browse/JDK-8148555_
>> _
>> _
>> *Webrev:*
>>
>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_
>>
>> *Issue:*
>> Emoji selection in Character Viewer was causing exception in JNI
>>
>> *Cause:*
>> Emojis are considered to be of different class type (namely,
>> NSConcreteMutableAttributedString) from NSString which other
>> characters are because of a surrogate pair for them.
>>
>> *Fix:*
>> Major changes done for condition of emojis in JNI. Albeit rendering is
>> not yet supported, they will appear as blank ?Missing font? notation.
>> Also, added debug point in case of issue with glyph arrises.
>>
>> With Regards,
>> Avik Niyogi
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Mar 14 13:22:41 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 14 Mar 2016 16:22:41 +0300
Subject: <Swing Dev> [9] Review request for 8149631: rgb(...) CSS color
 values are not parsed properly
In-Reply-To: <56E6A082.8040405@oracle.com>
References: <56E6A082.8040405@oracle.com>
Message-ID: <56E6BB21.40606@oracle.com>

Something strange occurs in the webrev for the testcase, there is no diff.

On 14.03.16 14:29, Semyon Sadetsky wrote:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8149631
> webrev: http://cr.openjdk.java.net/~ssadetsky/8149631/webrev.00/
>
> The issue is a regression of 4419748 which added support for border
> sides but it parse the rgb(...) color values wrong. Also before 4419748
> the parenthesis notations worked only for CSS attribute that is not
> expected to contain several values. The reason is splitting the
> multi-value CSS attribute (for example, "background: rgb(0, 0, 0) url(
> 'b.gif' ) no-repeat;") using space divider didn't take into account that
> spaces within parenthesis should not be used as top-level dividers.
> Fixing the value splitting should correct the situation for (...)
> entries in all multi-value CSS attributes.
>
> --Semyon


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Mon Mar 14 15:13:02 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 14 Mar 2016 18:13:02 +0300
Subject: <Swing Dev> [9] Review request for 8149631: rgb(...) CSS color
 values are not parsed properly
In-Reply-To: <56E6BB21.40606@oracle.com>
References: <56E6A082.8040405@oracle.com> <56E6BB21.40606@oracle.com>
Message-ID: <56E6D4FE.80905@oracle.com>

Thanks, Sergey. The webrev is corrected.

On 3/14/2016 4:22 PM, Sergey Bylokhov wrote:
> Something strange occurs in the webrev for the testcase, there is no 
> diff.
>
> On 14.03.16 14:29, Semyon Sadetsky wrote:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8149631
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8149631/webrev.00/
>>
>> The issue is a regression of 4419748 which added support for border
>> sides but it parse the rgb(...) color values wrong. Also before 4419748
>> the parenthesis notations worked only for CSS attribute that is not
>> expected to contain several values. The reason is splitting the
>> multi-value CSS attribute (for example, "background: rgb(0, 0, 0) url(
>> 'b.gif' ) no-repeat;") using space divider didn't take into account that
>> spaces within parenthesis should not be used as top-level dividers.
>> Fixing the value splitting should correct the situation for (...)
>> entries in all multi-value CSS attributes.
>>
>> --Semyon
>
>



From semyon.sadetsky at oracle.com  Mon Mar 14 16:48:28 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 14 Mar 2016 19:48:28 +0300
Subject: <Swing Dev> [9] Review request for 8151015: JTextArea.insert() does
 not behave as expected with invalid position
Message-ID: <56E6EB5C.7000305@oracle.com>

Hello,

Please review fix for JDK9:

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

It is regression of 4496801. The fix for 4496801 was wrong and the 
correct fix should be taking into account the implied character at the 
end of the document. Reverting 4496801 fixes 8151015. Also the correct 
fix for 4496801 is provided.

--Semyon


From Sergey.Bylokhov at oracle.com  Tue Mar 15 00:28:49 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 15 Mar 2016 03:28:49 +0300
Subject: <Swing Dev> [9] Review Request: 8151857 [TEST_BUG] bug6544309.java
 fails intermittently
Message-ID: <56E75741.6010909@oracle.com>

Hello,
Please review the small fix for jdk9.

The test javax/swing/JPopupMenu/6544309/bug6544309.java fails if 
executed in a batch via jtreg.

The problem is that this test shows popup menu and expects that some 
specific menuitems will be selected after keyboard navigation. But some 
other test in the javax/swing/JPopupMenu/** moves the mouse to the 
center of the screen, which causes an auto-selection of the menu item on 
osx and wrong final test result. Note that if the test is executed alone 
it is passed most of the time.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151857
Webrev can be found at: http://cr.openjdk.java.net/~serb/8151857/webrev.00

-- 
Best regards, Sergey.


From yuri.nesterenko at oracle.com  Tue Mar 15 07:53:49 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Tue, 15 Mar 2016 10:53:49 +0300
Subject: <Swing Dev> [9] Review Request: 8151857 [TEST_BUG]
 bug6544309.java fails intermittently
In-Reply-To: <56E75741.6010909@oracle.com>
References: <56E75741.6010909@oracle.com>
Message-ID: <56E7BF8D.6050404@oracle.com>

Looks fine.
-yan

On 03/15/2016 03:28 AM, Sergey Bylokhov wrote:
> Hello,
> Please review the small fix for jdk9.
>
> The test javax/swing/JPopupMenu/6544309/bug6544309.java fails if
> executed in a batch via jtreg.
>
> The problem is that this test shows popup menu and expects that some
> specific menuitems will be selected after keyboard navigation. But some
> other test in the javax/swing/JPopupMenu/** moves the mouse to the
> center of the screen, which causes an auto-selection of the menu item on
> osx and wrong final test result. Note that if the test is executed alone
> it is passed most of the time.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151857
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8151857/webrev.00
>



From alexander.v.stepanov at oracle.com  Tue Mar 15 10:38:28 2016
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Tue, 15 Mar 2016 13:38:28 +0300
Subject: <Swing Dev> [9] Review Request: 8151857 [TEST_BUG]
 bug6544309.java fails intermittently
In-Reply-To: <56E7BF8D.6050404@oracle.com>
References: <56E75741.6010909@oracle.com> <56E7BF8D.6050404@oracle.com>
Message-ID: <56E7E624.4080407@oracle.com>

+1 (not a reviewer)

Thanks,
Alexander

On 3/15/2016 10:53 AM, Yuri Nesterenko wrote:
> Looks fine.
> -yan
>
> On 03/15/2016 03:28 AM, Sergey Bylokhov wrote:
>> Hello,
>> Please review the small fix for jdk9.
>>
>> The test javax/swing/JPopupMenu/6544309/bug6544309.java fails if
>> executed in a batch via jtreg.
>>
>> The problem is that this test shows popup menu and expects that some
>> specific menuitems will be selected after keyboard navigation. But some
>> other test in the javax/swing/JPopupMenu/** moves the mouse to the
>> center of the screen, which causes an auto-selection of the menu item on
>> osx and wrong final test result. Note that if the test is executed alone
>> it is passed most of the time.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151857
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8151857/webrev.00
>>
>



From alexandr.scherbatiy at oracle.com  Tue Mar 15 14:01:39 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 15 Mar 2016 18:01:39 +0400
Subject: <Swing Dev> [OpenJDK 2D-Dev] [9] Review request for 8151303
 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it
In-Reply-To: <56E3277B.3000309@oracle.com>
References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com>
	<56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com>
Message-ID: <56E815C3.40208@oracle.com>

On 12/03/16 00:15, Jim Graham wrote:
> Is this tied in with ImageFilter/FilteredImageSource?
>
> It looks like since FIS takes only a Producer, it has lost the handle 
> to the image to get a source for a particular resolution. What happens 
> if we introduce MultiResolution[Image]Producer?  It would provide a 
> single method that would mimic <OriginalImage>.getRV().getProducer()?
>
> I imagine this would greatly complicate the internals of ToolkitImage 
> to support this, though...

  It is possible to introduce MultiResolutionImageProducer to make the 
code below work without changes:
     Image mrImage = createMultiResolutionImage();
     Image img = toolkit.createImage(new 
FilteredImageSource(mrImage.getSource(), filter));

  One update will be that FilteredImageSource should implement 
MultiResolutionImageProducer even it is used for non multi-resolution 
images.

   The MRI can be created using two general ways: using fixed number of 
resolution variants or generating a resolution variant with necessary 
quality on demand.

  The current implementation is rely on that MRToolkitImage contains a 
fixed number of resolution variants. In this case MediaTracker can 
iterate over resolution variants and load them all.

  Using MultiResolutionImageProducer leads that MRToolkitImage will not 
know about number of resolution variants in case when they are generated 
on the fly and there will be no way to load all of them by MediaTracker.

As I see, the way to solve it is only using MRI.getResolutionVariants() 
method for the MultiResolutionImageProducer creation. So the result of 
the call
    toolkit.createImage(new FilteredImageSource(mrImage.getSource(), 
filter));
  will be a MRToolkitImage which is based on fixed number of filtered 
resolution variants from the original MRI.

  Thanks,
  Alexandr.

> ...jim
>
> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote:
>> On 09/03/16 16:58, Sergey Bylokhov wrote:
>>> Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to
>>> support this functionality? It seems that the number of usage of this
>>> check "image instanceof MultiResolutionImage" will grow over time.
>>     ImageProducer produces pixels for an image and is not able to take
>> an information about the image resolution variants.
>>
>>   May be we can add Toolkit.createImage(Image image, ImageFilter
>> imageFilter) method which takes MultiResolutionImage into account to
>> cover the common case where filtered image is created.
>>
>>   Thanks,
>>   Alexandr.
>>> I think that at least our own API should support MultiResolutionImage
>>> w/o such checks, otherwise the user will need to do the same.
>>>
>>> cc 2d-dev
>>>
>>> On 09.03.16 15:30, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8151303
>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00
>>>>
>>>>    The AquaUtils does not take into account MultiResolutionImage for
>>>> selected/disabled/lightened images generation.
>>>>    The fix also leaves the MultiResolutionCachedImage check because 
>>>> the
>>>> base system icon size can be differ from the requested painted size.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>
>>>
>>



From Sergey.Bylokhov at oracle.com  Tue Mar 15 14:06:33 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 15 Mar 2016 17:06:33 +0300
Subject: <Swing Dev> [OpenJDK 2D-Dev] [9] Review request for 8151303
 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it
In-Reply-To: <56E815C3.40208@oracle.com>
References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com>
	<56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com>
	<56E815C3.40208@oracle.com>
Message-ID: <56E816E9.1010308@oracle.com>

On 15.03.16 17:01, Alexander Scherbatiy wrote:

>   One update will be that FilteredImageSource should implement
> MultiResolutionImageProducer even it is used for non multi-resolution
> images.
>
>    The MRI can be created using two general ways: using fixed number of
> resolution variants or generating a resolution variant with necessary
> quality on demand.
>
>   The current implementation is rely on that MRToolkitImage contains a
> fixed number of resolution variants. In this case MediaTracker can
> iterate over resolution variants and load them all.
>
>   Using MultiResolutionImageProducer leads that MRToolkitImage will not
> know about number of resolution variants in case when they are generated
> on the fly and there will be no way to load all of them by MediaTracker.

Just an idea to thinking about, can we save this filter to the MRI 
itself and apply it after some resolution variant will be created on the 
fly?

>
> As I see, the way to solve it is only using MRI.getResolutionVariants()
> method for the MultiResolutionImageProducer creation. So the result of
> the call
>     toolkit.createImage(new FilteredImageSource(mrImage.getSource(),
> filter));
>   will be a MRToolkitImage which is based on fixed number of filtered
> resolution variants from the original MRI.
>
>   Thanks,
>   Alexandr.
>
>> ...jim
>>
>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote:
>>> On 09/03/16 16:58, Sergey Bylokhov wrote:
>>>> Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to
>>>> support this functionality? It seems that the number of usage of this
>>>> check "image instanceof MultiResolutionImage" will grow over time.
>>>     ImageProducer produces pixels for an image and is not able to take
>>> an information about the image resolution variants.
>>>
>>>   May be we can add Toolkit.createImage(Image image, ImageFilter
>>> imageFilter) method which takes MultiResolutionImage into account to
>>> cover the common case where filtered image is created.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>> I think that at least our own API should support MultiResolutionImage
>>>> w/o such checks, otherwise the user will need to do the same.
>>>>
>>>> cc 2d-dev
>>>>
>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8151303
>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00
>>>>>
>>>>>    The AquaUtils does not take into account MultiResolutionImage for
>>>>> selected/disabled/lightened images generation.
>>>>>    The fix also leaves the MultiResolutionCachedImage check because
>>>>> the
>>>>> base system icon size can be differ from the requested painted size.
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>
>>>>
>>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Mar 15 16:35:40 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 15 Mar 2016 20:35:40 +0400
Subject: <Swing Dev> [OpenJDK 2D-Dev] [9] Review request for 8151303
 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it
In-Reply-To: <56E816E9.1010308@oracle.com>
References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com>
	<56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com>
	<56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com>
Message-ID: <56E839DC.2040904@oracle.com>

On 15/03/16 18:06, Sergey Bylokhov wrote:
> On 15.03.16 17:01, Alexander Scherbatiy wrote:
>
>>   One update will be that FilteredImageSource should implement
>> MultiResolutionImageProducer even it is used for non multi-resolution
>> images.
>>
>>    The MRI can be created using two general ways: using fixed number of
>> resolution variants or generating a resolution variant with necessary
>> quality on demand.
>>
>>   The current implementation is rely on that MRToolkitImage contains a
>> fixed number of resolution variants. In this case MediaTracker can
>> iterate over resolution variants and load them all.
>>
>>   Using MultiResolutionImageProducer leads that MRToolkitImage will not
>> know about number of resolution variants in case when they are generated
>> on the fly and there will be no way to load all of them by MediaTracker.
>
> Just an idea to thinking about, can we save this filter to the MRI 
> itself and apply it after some resolution variant will be created on 
> the fly?

Do you mean that it helps to leave the code in the AquaUtils class 
unchanged:
---------------
  124     static Image generateLightenedImage(final Image image, final 
int percent) {
  125         final GrayFilter filter = new GrayFilter(true, percent);
  126         final ImageProducer prod = new 
FilteredImageSource(image.getSource(), filter);
  127         return Toolkit.getDefaultToolkit().createImage(prod);
  128     }
---------------

   or it is just an a better way for a filtered multi-resolution image 
generation?

   Thanks,
   Alexandr.
>
>>
>> As I see, the way to solve it is only using MRI.getResolutionVariants()
>> method for the MultiResolutionImageProducer creation. So the result of
>> the call
>>     toolkit.createImage(new FilteredImageSource(mrImage.getSource(),
>> filter));
>>   will be a MRToolkitImage which is based on fixed number of filtered
>> resolution variants from the original MRI.
>>
>>   Thanks,
>>   Alexandr.
>>
>>> ...jim
>>>
>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote:
>>>> On 09/03/16 16:58, Sergey Bylokhov wrote:
>>>>> Probably we should enhance 
>>>>> ImageProducer/Tk.createImage/ImageFilter to
>>>>> support this functionality? It seems that the number of usage of this
>>>>> check "image instanceof MultiResolutionImage" will grow over time.
>>>>     ImageProducer produces pixels for an image and is not able to take
>>>> an information about the image resolution variants.
>>>>
>>>>   May be we can add Toolkit.createImage(Image image, ImageFilter
>>>> imageFilter) method which takes MultiResolutionImage into account to
>>>> cover the common case where filtered image is created.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>> I think that at least our own API should support MultiResolutionImage
>>>>> w/o such checks, otherwise the user will need to do the same.
>>>>>
>>>>> cc 2d-dev
>>>>>
>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the fix:
>>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8151303
>>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00
>>>>>>
>>>>>>    The AquaUtils does not take into account MultiResolutionImage for
>>>>>> selected/disabled/lightened images generation.
>>>>>>    The fix also leaves the MultiResolutionCachedImage check because
>>>>>> the
>>>>>> base system icon size can be differ from the requested painted size.
>>>>>>
>>>>>>    Thanks,
>>>>>>    Alexandr.
>>>>>
>>>>>
>>>>
>>
>
>



From philip.race at oracle.com  Tue Mar 15 19:39:10 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 15 Mar 2016 12:39:10 -0700
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56DB4C3B.1060902@oracle.com>
References: <56DB4C3B.1060902@oracle.com>
Message-ID: <56E864DE.4000706@oracle.com>

There is a lot to read here. I think I need to patch and try it but 
first ...

Two high level questions :
1) Have you verified that this behaves properly (or no worse than
currently) with -Djava.awt.headless=true since Swing components
are supposed to be able to draw off-screen in headless mode .. and
yet a dependency on GTK and its dependency on xlibraries seems to mean
that you can't load GTK in this case.
BTW I think it may be painful to get them to layout in such a case
but that's another issue.

2) Have you tried a hi-dpi system ?

3) Have you submitted a JPRT job ? It is essential to know that this
builds cleanly on the "official" compilation environment.

4)I expect you ran Swingset2 + GTK L&F but have you run any of the 
regression test suite ?

Minor comments :

GTKEngine.java

  494         Container parent = context.getComponent().getParent();
  495         if(GTKLookAndFeel.is3()) {
  496             if (parent != null && parent.getParent() instanceof JComboBox) {
  497                 if (parent.getParent().hasFocus()) {
  498                     synthState |= SynthConstants.FOCUSED;
  499                 }
  500             }
  501         }

GTKPainter.java

746         if (GTKLookAndFeel.is3()) {
  747             if (slider.getOrientation() == JSlider.VERTICAL) {
  748                 y += 1;
  749                 h -= 2;
  750             } else {
  751                 x += 1;
  752                 w -= 2;
  753             }
  754         }

I don't know where these numbers come from or what coordinate system
is being used here but it seems you are changing them for gtk 2.2 as 
well as 3
Can you speak to this ?

GTKStyle.java

735         if(!GTKLookAndFeel.is3()) {

840      } else if(GTKLookAndFeel.is3() && "ComboBox.forceOpaque".equals(key)) {


we prefer a space between "if" and "("

sun_awt_X11_GtkFileDialogPeer.c

  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {


Maybe I am not looking at the right fn but I thought I saw
this fn return a boolean so a check against NULL looks wrong.

  393         gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
  394                 dialog), TRUE);


You didn't add this but it is awfully specific about the GTK version and
I wonder if this test is doing what it should be doing on GTK 3?

It is interesting that some equivalent looking Java level dialog 
checking in XToolkit.java
checked for 3.0 too ..

swing_GTKEngine.c :

   30 /* Static buffer for conversion from java.lang.String to UTF-8 */
   31 static char convertionBuffer[CONV_BUFFER_SIZE];

So the variable name should be spelt conversionBuffer.

awt_UNIXToolkit.c

< 287 free(ret);

You deleted this free(). Is that correct ? It seems to imply
you now expect a boolean return as discussed above and
so in that case NULL looks odd here (line 260) too.

gtk3_interface.h :

   36 #define G_PI    3.1415926535897932384626433832795028841971693993751

I don't think that is completely accurate :-) And I should have reviewed this yesterday [1].

-phil.

[1] http://www.piday.org/


On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>
> The fix contains GTK3 based implementation for Swing GTK LnF, AWT 
> FileChooser for Linux and AWT Robot for Linux.
> Also the new system property is added to request specific GTK version 
> swing.gtk.version.
>
> --Semyon



From alexandr.scherbatiy at oracle.com  Wed Mar 16 11:21:05 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 16 Mar 2016 15:21:05 +0400
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
 minimal heigh of JTabbedPane with more tabs
In-Reply-To: <26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
Message-ID: <56E941A1.1090402@oracle.com>


Does the same issue affects the AquaTabbedPaneContrastUI?

Thanks,
Alexandr.

On 14/03/16 09:04, Avik Niyogi wrote:
> Hi All,
> A gentle reminder, please review code changes.
>
> With Regards,
> Avik Niyogi
>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi <avik.niyogi at oracle.com 
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi All,
>>
>> Please review code changes done as with inputs provided.
>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>
>>
>> Also, albeit the title of issue mentioned is as above, the injection 
>> of issue occurs because 
>> *pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT);* is not 
>> honoured.
>> In the new fix as provided, references to base class layout manager 
>> is removed in current solution.
>>
>> With Regards,
>> Avik Niyogi
>>
>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin 
>>> <alexander.potochkin at oracle.com 
>>> <mailto:alexander.potochkin at oracle.com>> wrote:
>>>
>>> Hello Avik
>>>
>>> Let me make it clear I don't approve the proposed fix
>>> and ask you to do additional evaluation.
>>>
>>> Every LookAndFeel is different and it doesn't make much sense
>>> to compare Metal LaF with AquaLaf.
>>>
>>> The AquaLaf mimics the native MacOS controls and therefore look 
>>> quite different from any other Lafs.
>>>
>>> The bug you are fixing has the following subject
>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>
>>> Could you please fix exactly the problem with the minimal heights,
>>> without changing the UI delegate class.
>>>
>>> Thanks
>>> alexp
>>>
>>>> Gentle reminder. Please review this fix.
>>>>
>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi <avik.niyogi at oracle.com> 
>>>>> wrote:
>>>>>
>>>>> The issue is with setting of TabbedPane*Scroll*Layout() for the 
>>>>> option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>>  and *not* TabbedPaneLayout() as which is the default.
>>>>>
>>>>> The minimum size fixes itself because the *ScrollLayout* check 
>>>>> fails in *setTabLayoutPolicy*() for the pane. So the issue is with 
>>>>> the call to set layout manager.
>>>>> There are only two configurations that the *JTabbedPane* can exist 
>>>>> in of which *SCROLL_TAB_LAYOUT* is one of them.
>>>>>
>>>>> Fixing the minimum size in *AquaTabbedPaneUI* will fix it for 
>>>>> *TabbedPaneLayout*() only which is the *WRAP_TAB_LAYOUT*.
>>>>>
>>>>> Also, I have checked other implementations such as for *Metal* and 
>>>>> *Motif* and *they have similar code for doing this process*.
>>>>> Hence, with in-depth analysis, this fix has no other impact apart 
>>>>> from this fix.
>>>>>
>>>>> In case the impact caused by this change has caused some 
>>>>> definitive regressions, please mention them so they can be 
>>>>> addressed. Thank you.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>
>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin 
>>>>>> <alexander.potochkin at oracle.com> wrote:
>>>>>>
>>>>>> Hello Avik
>>>>>>
>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is 
>>>>>> specific for the AquaTabbedPaneUI.
>>>>>> I don't think setting the layout manager from the base class is 
>>>>>> the right solution here.
>>>>>>
>>>>>> If there is a problem with minimum size it should be fixed inside 
>>>>>> the AquaTabbedPaneUI
>>>>>>
>>>>>> Thanks
>>>>>> alexp
>>>>>>
>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>
>>>>>>> *Bug:*
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8137169
>>>>>>>
>>>>>>> *Webrev:*
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ 
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>
>>>>>>>
>>>>>>> *Issue:*
>>>>>>> For Aqua Look&Feel, multiple calls 
>>>>>>> to pane.getMinimumSize().height causes incremental return of values.
>>>>>>>
>>>>>>> *Cause:*
>>>>>>> The impact was caused by a major broken code within 
>>>>>>> AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>
>>>>>>> *Fix:*
>>>>>>> Major linking calls to super class fix done within 
>>>>>>> createLayoutManager().
>>>>>>>
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160316/d0043df4/attachment.html>

From semyon.sadetsky at oracle.com  Wed Mar 16 17:52:41 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 16 Mar 2016 20:52:41 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56E864DE.4000706@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
Message-ID: <56E99D68.90208@oracle.com>

Hi Phil,

Thank for review. You will find my reply below in the text.

The updated webrev is 
http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
It also contains:
- new properties jdk.gtk.version and jdk.gtk.verbose
- appearance tuning for Ubuntu 15 (GTK 3.14). It may require more but we 
can do this later as a separate bug.
The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and 
then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some 
appearance changes.

On 3/15/2016 10:39 PM, Phil Race wrote:
> There is a lot to read here. I think I need to patch and try it but 
> first ...
>
> Two high level questions :
> 1) Have you verified that this behaves properly (or no worse than
> currently) with -Djava.awt.headless=true since Swing components
> are supposed to be able to draw off-screen in headless mode .. and
> yet a dependency on GTK and its dependency on xlibraries seems to mean
> that you can't load GTK in this case.
> BTW I think it may be painful to get them to layout in such a case
> but that's another issue.
I tested it by painting to a BufferedImage. Seems it is enough.
>
> 2) Have you tried a hi-dpi system ?
Yes I have. It is identical to the existing GTK2 based appearance.
>
> 3) Have you submitted a JPRT job ? It is essential to know that this
> builds cleanly on the "official" compilation environment.
I will do this before the push. I think it will be OK because I did not 
use any new C constructs and the new libraries are linked dynamically.
> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the 
> regression test suite ?
Yes I ran javax/swing tests but many of them fails with GTK2 as well. 
With GTK3 the result was the same except for some unstable tests. Unity 
desktop has new window decorations like borderless windows which are 
resized by dragging the outer window shadow, invisible overlay 
scrollbars, etc. Many tests written for old window decorations fails.
>
> Minor comments :
>
> GTKEngine.java
>
>  494         Container parent = context.getComponent().getParent();
>  495         if(GTKLookAndFeel.is3()) {
>  496             if (parent != null && parent.getParent() instanceof 
> JComboBox) {
>  497                 if (parent.getParent().hasFocus()) {
>  498                     synthState |= SynthConstants.FOCUSED;
>  499                 }
>  500             }
>  501         }
>
> GTKPainter.java
>
> 746         if (GTKLookAndFeel.is3()) {
>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>  748                 y += 1;
>  749                 h -= 2;
>  750             } else {
>  751                 x += 1;
>  752                 w -= 2;
>  753             }
>  754         }
>
> I don't know where these numbers come from or what coordinate system
> is being used here but it seems you are changing them for gtk 2.2 as 
> well as 3
> Can you speak to this ?
It is an appearance tuning for GTK3. I didn't change it for GTK2, why do 
you think so?
This was used before my fix as well, for example

                     if (containerParent instanceof JComboBox) {
                         x += (focusSize + 2);
                         y += (focusSize + 1);
                         w -= (2 * focusSize + 1);
                         h -= (2 * focusSize + 2);
                     } else {
                         x += focusSize;
                         y += focusSize;
                         w -= 2 * focusSize;
                         h -= 2 * focusSize;
                     }

The only place where I changed the existing GTK2 appearance is:

1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", "slider-length");

  in GTKStyle.java, because this property was omitted by mistake.
>
> GTKStyle.java
>
> 735         if(!GTKLookAndFeel.is3()) {
>
> 840      } else if(GTKLookAndFeel.is3() && 
> "ComboBox.forceOpaque".equals(key)) {
>
>
> we prefer a space between "if" and "("
Accepted.
>
> sun_awt_X11_GtkFileDialogPeer.c
>
>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>
>
> Maybe I am not looking at the right fn but I thought I saw
> this fn return a boolean so a check against NULL looks wrong.
The declaration is in GtkApi struct of gtk_interface.h. It returns 
char*. NULL means that the version is compatible.
>
>  393 
> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>  394                 dialog), TRUE);
>
>
> You didn't add this but it is awfully specific about the GTK version and
> I wonder if this test is doing what it should be doing on GTK 3?
Accepted.
>
> It is interesting that some equivalent looking Java level dialog 
> checking in XToolkit.java
> checked for 3.0 too ..
>
> swing_GTKEngine.c :
>
>   30 /* Static buffer for conversion from java.lang.String to UTF-8 */
>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>
> So the variable name should be spelt conversionBuffer.
Accepted.
>
> awt_UNIXToolkit.c
>
> < 287 free(ret);
>
> You deleted this free(). Is that correct ? It seems to imply
> you now expect a boolean return as discussed above and
> so in that case NULL looks odd here (line 260) too.
The JNI exported method returns boolean while the GTK method returns 
char*. free() is deleted intentionally according to the GTK docs it 
belongs to the library and should not be freed by user code.
>
> gtk3_interface.h :
>
>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>
> I don't think that is completely accurate :-) And I should have 
> reviewed this yesterday [1].
:) This is glib's definition I just copied.

--Semyon
>
> -phil.
>
> [1] http://www.piday.org/
>
>
> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>
>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT 
>> FileChooser for Linux and AWT Robot for Linux.
>> Also the new system property is added to request specific GTK version 
>> swing.gtk.version.
>>
>> --Semyon
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160316/b5253204/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed Mar 16 18:06:29 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 16 Mar 2016 22:06:29 +0400
Subject: <Swing Dev> [9] Review request for 8151015: JTextArea.insert()
 does not behave as expected with invalid position
In-Reply-To: <56E6EB5C.7000305@oracle.com>
References: <56E6EB5C.7000305@oracle.com>
Message-ID: <56E9A0A5.8070102@oracle.com>


The fix looks good to me.

Just a small comment: if it is a new test it probably should not contain 
1998 year in the copyright.

Thanks,
Alexandr.

On 14/03/16 20:48, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8151015
> webrev: http://cr.openjdk.java.net/~ssadetsky/8151015/webrev.00/
>
> It is regression of 4496801. The fix for 4496801 was wrong and the 
> correct fix should be taking into account the implied character at the 
> end of the document. Reverting 4496801 fixes 8151015. Also the correct 
> fix for 4496801 is provided.
>
> --Semyon



From alexandr.scherbatiy at oracle.com  Wed Mar 16 18:25:58 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 16 Mar 2016 22:25:58 +0400
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
 exception was raised entering Emoji into JTextArea
In-Reply-To: <56E6BA0A.10301@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com>
Message-ID: <56E9A536.6090903@oracle.com>


Could the -(NSMutableString *) parseString: method be declared as class 
method instead of instance?

Thanks,
Alexandr.

On 14/03/16 17:18, Sergey Bylokhov wrote:
> Hi, Avik.
> Can you please take a look to these two tests before fixing this bug:
>
> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
> --------------------------------------------------
> TEST: 
> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>
> I remember they passed on jdk8, but it seems we have a regression in 
> jdk9 and both of them fail.
>
> On 14.03.16 8:05, Avik Niyogi wrote:
>> Hi All,
>> A gentle reminder, please review my code changes.
>>
>> With Regards,
>> Avik Niyogi
>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com
>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>
>>> Hi All,
>>>
>>> Kindly review the bug fix for JDK 9.
>>>
>>> *Bug:*
>>>
>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_
>>> _
>>> _
>>> *Webrev:*
>>>
>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_
>>>
>>> *Issue:*
>>> Emoji selection in Character Viewer was causing exception in JNI
>>>
>>> *Cause:*
>>> Emojis are considered to be of different class type (namely,
>>> NSConcreteMutableAttributedString) from NSString which other
>>> characters are because of a surrogate pair for them.
>>>
>>> *Fix:*
>>> Major changes done for condition of emojis in JNI. Albeit rendering is
>>> not yet supported, they will appear as blank ?Missing font? notation.
>>> Also, added debug point in case of issue with glyph arrises.
>>>
>>> With Regards,
>>> Avik Niyogi
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160316/7be8f005/attachment.html>

From philip.race at oracle.com  Wed Mar 16 22:11:56 2016
From: philip.race at oracle.com (Phil Race)
Date: Wed, 16 Mar 2016 15:11:56 -0700
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56E99D68.90208@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com>
Message-ID: <56E9DA2C.9090603@oracle.com>

This all sounds reasonable so I am OK with the changes.

-phil.

On 03/16/2016 10:52 AM, Semyon Sadetsky wrote:
> Hi Phil,
>
> Thank for review. You will find my reply below in the text.
>
> The updated webrev is 
> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
> It also contains:
> - new properties jdk.gtk.version and jdk.gtk.verbose
> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more but 
> we can do this later as a separate bug.
> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and 
> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some 
> appearance changes.
>
> On 3/15/2016 10:39 PM, Phil Race wrote:
>> There is a lot to read here. I think I need to patch and try it but 
>> first ...
>>
>> Two high level questions :
>> 1) Have you verified that this behaves properly (or no worse than
>> currently) with -Djava.awt.headless=true since Swing components
>> are supposed to be able to draw off-screen in headless mode .. and
>> yet a dependency on GTK and its dependency on xlibraries seems to mean
>> that you can't load GTK in this case.
>> BTW I think it may be painful to get them to layout in such a case
>> but that's another issue.
> I tested it by painting to a BufferedImage. Seems it is enough.
>>
>> 2) Have you tried a hi-dpi system ?
> Yes I have. It is identical to the existing GTK2 based appearance.
>>
>> 3) Have you submitted a JPRT job ? It is essential to know that this
>> builds cleanly on the "official" compilation environment.
> I will do this before the push. I think it will be OK because I did 
> not use any new C constructs and the new libraries are linked dynamically.
>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the 
>> regression test suite ?
> Yes I ran javax/swing tests but many of them fails with GTK2 as well. 
> With GTK3 the result was the same except for some unstable tests. 
> Unity desktop has new window decorations like borderless windows which 
> are resized by dragging the outer window shadow, invisible overlay 
> scrollbars, etc. Many tests written for old window decorations fails.
>>
>> Minor comments :
>>
>> GTKEngine.java
>>
>>  494         Container parent = context.getComponent().getParent();
>>  495         if(GTKLookAndFeel.is3()) {
>>  496             if (parent != null && parent.getParent() instanceof 
>> JComboBox) {
>>  497                 if (parent.getParent().hasFocus()) {
>>  498                     synthState |= SynthConstants.FOCUSED;
>>  499                 }
>>  500             }
>>  501         }
>>
>> GTKPainter.java
>>
>> 746         if (GTKLookAndFeel.is3()) {
>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>  748                 y += 1;
>>  749                 h -= 2;
>>  750             } else {
>>  751                 x += 1;
>>  752                 w -= 2;
>>  753             }
>>  754         }
>>
>> I don't know where these numbers come from or what coordinate system
>> is being used here but it seems you are changing them for gtk 2.2 as 
>> well as 3
>> Can you speak to this ?
> It is an appearance tuning for GTK3. I didn't change it for GTK2, why 
> do you think so?
> This was used before my fix as well, for example
>
>                     if (containerParent instanceof JComboBox) {
>                         x += (focusSize + 2);
>                         y += (focusSize + 1);
>                         w -= (2 * focusSize + 1);
>                         h -= (2 * focusSize + 2);
>                     } else {
>                         x += focusSize;
>                         y += focusSize;
>                         w -= 2 * focusSize;
>                         h -= 2 * focusSize;
>                     }
>
> The only place where I changed the existing GTK2 appearance is:
>
> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", "slider-length");
>
>  in GTKStyle.java, because this property was omitted by mistake.
>>
>> GTKStyle.java
>>
>> 735         if(!GTKLookAndFeel.is3()) {
>>
>> 840      } else if(GTKLookAndFeel.is3() && 
>> "ComboBox.forceOpaque".equals(key)) {
>>
>>
>> we prefer a space between "if" and "("
> Accepted.
>>
>> sun_awt_X11_GtkFileDialogPeer.c
>>
>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>
>>
>> Maybe I am not looking at the right fn but I thought I saw
>> this fn return a boolean so a check against NULL looks wrong.
> The declaration is in GtkApi struct of gtk_interface.h. It returns 
> char*. NULL means that the version is compatible.
>>
>>  393 
>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>  394                 dialog), TRUE);
>>
>>
>> You didn't add this but it is awfully specific about the GTK version and
>> I wonder if this test is doing what it should be doing on GTK 3?
> Accepted.
>>
>> It is interesting that some equivalent looking Java level dialog 
>> checking in XToolkit.java
>> checked for 3.0 too ..
>>
>> swing_GTKEngine.c :
>>
>>   30 /* Static buffer for conversion from java.lang.String to UTF-8 */
>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>
>> So the variable name should be spelt conversionBuffer.
> Accepted.
>>
>> awt_UNIXToolkit.c
>>
>> < 287 free(ret);
>>
>> You deleted this free(). Is that correct ? It seems to imply
>> you now expect a boolean return as discussed above and
>> so in that case NULL looks odd here (line 260) too.
> The JNI exported method returns boolean while the GTK method returns 
> char*. free() is deleted intentionally according to the GTK docs it 
> belongs to the library and should not be freed by user code.
>>
>> gtk3_interface.h :
>>
>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>
>> I don't think that is completely accurate :-) And I should have 
>> reviewed this yesterday [1].
> :) This is glib's definition I just copied.
>
> --Semyon
>>
>> -phil.
>>
>> [1] http://www.piday.org/
>>
>>
>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>
>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT 
>>> FileChooser for Linux and AWT Robot for Linux.
>>> Also the new system property is added to request specific GTK 
>>> version swing.gtk.version.
>>>
>>> --Semyon
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160316/b6e69a61/attachment.html>

From philip.race at oracle.com  Wed Mar 16 22:25:26 2016
From: philip.race at oracle.com (Phil Race)
Date: Wed, 16 Mar 2016 15:25:26 -0700
Subject: <Swing Dev> RfR, JDK-8145228 , Java Access Bridge,
 getAccessibleStatesStringFromContext doesn't wrap the call to
 getAccessibleRole
In-Reply-To: <56D4ABAB.8080504@oracle.com>
References: <56D4ABAB.8080504@oracle.com>
Message-ID: <56E9DD56.1090504@oracle.com>

+1.

-phil.

On 02/29/2016 12:35 PM, Pete Brunet wrote:
> Please review this change which runs code on the EDT like it should have.
>
> http://cr.openjdk.java.net/~ptbrunet/JDK-8145228/webrev.00/



From Sergey.Bylokhov at oracle.com  Thu Mar 17 11:46:49 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 17 Mar 2016 14:46:49 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56E99D68.90208@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com>
Message-ID: <56EA9929.9020605@oracle.com>

Small notes:
  - It will be good to move the code which reads the system properties 
to the static init block, otherwise we can be in trouble if these 
properties will be changed at runtime.
  - Is it necessary to use ordinal? can we replace it with some specific 
data?(the same for the indexed access in .values()[..])

On 16.03.16 20:52, Semyon Sadetsky wrote:
> Hi Phil,
>
> Thank for review. You will find my reply below in the text.
>
> The updated webrev is
> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
> It also contains:
> - new properties jdk.gtk.version and jdk.gtk.verbose
> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more but we
> can do this later as a separate bug.
> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
> appearance changes.
>
> On 3/15/2016 10:39 PM, Phil Race wrote:
>> There is a lot to read here. I think I need to patch and try it but
>> first ...
>>
>> Two high level questions :
>> 1) Have you verified that this behaves properly (or no worse than
>> currently) with -Djava.awt.headless=true since Swing components
>> are supposed to be able to draw off-screen in headless mode .. and
>> yet a dependency on GTK and its dependency on xlibraries seems to mean
>> that you can't load GTK in this case.
>> BTW I think it may be painful to get them to layout in such a case
>> but that's another issue.
> I tested it by painting to a BufferedImage. Seems it is enough.
>>
>> 2) Have you tried a hi-dpi system ?
> Yes I have. It is identical to the existing GTK2 based appearance.
>>
>> 3) Have you submitted a JPRT job ? It is essential to know that this
>> builds cleanly on the "official" compilation environment.
> I will do this before the push. I think it will be OK because I did not
> use any new C constructs and the new libraries are linked dynamically.
>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>> regression test suite ?
> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
> With GTK3 the result was the same except for some unstable tests. Unity
> desktop has new window decorations like borderless windows which are
> resized by dragging the outer window shadow, invisible overlay
> scrollbars, etc. Many tests written for old window decorations fails.
>>
>> Minor comments :
>>
>> GTKEngine.java
>>
>>  494         Container parent = context.getComponent().getParent();
>>  495         if(GTKLookAndFeel.is3()) {
>>  496             if (parent != null && parent.getParent() instanceof
>> JComboBox) {
>>  497                 if (parent.getParent().hasFocus()) {
>>  498                     synthState |= SynthConstants.FOCUSED;
>>  499                 }
>>  500             }
>>  501         }
>>
>> GTKPainter.java
>>
>> 746         if (GTKLookAndFeel.is3()) {
>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>  748                 y += 1;
>>  749                 h -= 2;
>>  750             } else {
>>  751                 x += 1;
>>  752                 w -= 2;
>>  753             }
>>  754         }
>>
>> I don't know where these numbers come from or what coordinate system
>> is being used here but it seems you are changing them for gtk 2.2 as
>> well as 3
>> Can you speak to this ?
> It is an appearance tuning for GTK3. I didn't change it for GTK2, why do
> you think so?
> This was used before my fix as well, for example
>
>                      if (containerParent instanceof JComboBox) {
>                          x += (focusSize + 2);
>                          y += (focusSize + 1);
>                          w -= (2 * focusSize + 1);
>                          h -= (2 * focusSize + 2);
>                      } else {
>                          x += focusSize;
>                          y += focusSize;
>                          w -= 2 * focusSize;
>                          h -= 2 * focusSize;
>                      }
>
> The only place where I changed the existing GTK2 appearance is:
>
> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", "slider-length");
>
>   in GTKStyle.java, because this property was omitted by mistake.
>>
>> GTKStyle.java
>>
>> 735         if(!GTKLookAndFeel.is3()) {
>>
>> 840      } else if(GTKLookAndFeel.is3() &&
>> "ComboBox.forceOpaque".equals(key)) {
>>
>>
>> we prefer a space between "if" and "("
> Accepted.
>>
>> sun_awt_X11_GtkFileDialogPeer.c
>>
>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>
>>
>> Maybe I am not looking at the right fn but I thought I saw
>> this fn return a boolean so a check against NULL looks wrong.
> The declaration is in GtkApi struct of gtk_interface.h. It returns
> char*. NULL means that the version is compatible.
>>
>>  393
>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>  394                 dialog), TRUE);
>>
>>
>> You didn't add this but it is awfully specific about the GTK version and
>> I wonder if this test is doing what it should be doing on GTK 3?
> Accepted.
>>
>> It is interesting that some equivalent looking Java level dialog
>> checking in XToolkit.java
>> checked for 3.0 too ..
>>
>> swing_GTKEngine.c :
>>
>>   30 /* Static buffer for conversion from java.lang.String to UTF-8 */
>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>
>> So the variable name should be spelt conversionBuffer.
> Accepted.
>>
>> awt_UNIXToolkit.c
>>
>> < 287 free(ret);
>>
>> You deleted this free(). Is that correct ? It seems to imply
>> you now expect a boolean return as discussed above and
>> so in that case NULL looks odd here (line 260) too.
> The JNI exported method returns boolean while the GTK method returns
> char*. free() is deleted intentionally according to the GTK docs it
> belongs to the library and should not be freed by user code.
>>
>> gtk3_interface.h :
>>
>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>
>> I don't think that is completely accurate :-) And I should have
>> reviewed this yesterday [1].
> :) This is glib's definition I just copied.
>
> --Semyon
>>
>> -phil.
>>
>> [1] http://www.piday.org/
>>
>>
>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>
>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>> FileChooser for Linux and AWT Robot for Linux.
>>> Also the new system property is added to request specific GTK version
>>> swing.gtk.version.
>>>
>>> --Semyon
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Mar 17 12:57:02 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 17 Mar 2016 15:57:02 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56E99D68.90208@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com>
Message-ID: <56EAA99E.2040104@oracle.com>

On 16.03.16 20:52, Semyon Sadetsky wrote:
> Hi Phil,
>
> Thank for review. You will find my reply below in the text.
>
> The updated webrev is
> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/

On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):

ERROR: Build failed for target 'images' in configuration 
'linux-x86_64-normal-server-release' (exit code 2)
=== Output from failing command(s) repeated here ===
* For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
/mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
In function ?Java_sun_awt_X11_XDesktopPeer_init?:
/mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
error: implicit declaration of function ?gtk2_load? 
[-Werror=implicit-function-declaration]
      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
          ^
/mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
error: implicit declaration of function ?gtk2_show_uri_load? 
[-Werror=implicit-function-declaration]
      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
                            ^
cc1: all warnings being treated as errors
=== End of repeated output ===
=== Make failure sequence repeated here ===
Awt2dLibraries.gmk:369: recipe for target 
'/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
failed
make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
=== End of repeated output ===


> It also contains:
> - new properties jdk.gtk.version and jdk.gtk.verbose
> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more but we
> can do this later as a separate bug.
> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
> appearance changes.
>
> On 3/15/2016 10:39 PM, Phil Race wrote:
>> There is a lot to read here. I think I need to patch and try it but
>> first ...
>>
>> Two high level questions :
>> 1) Have you verified that this behaves properly (or no worse than
>> currently) with -Djava.awt.headless=true since Swing components
>> are supposed to be able to draw off-screen in headless mode .. and
>> yet a dependency on GTK and its dependency on xlibraries seems to mean
>> that you can't load GTK in this case.
>> BTW I think it may be painful to get them to layout in such a case
>> but that's another issue.
> I tested it by painting to a BufferedImage. Seems it is enough.
>>
>> 2) Have you tried a hi-dpi system ?
> Yes I have. It is identical to the existing GTK2 based appearance.
>>
>> 3) Have you submitted a JPRT job ? It is essential to know that this
>> builds cleanly on the "official" compilation environment.
> I will do this before the push. I think it will be OK because I did not
> use any new C constructs and the new libraries are linked dynamically.
>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>> regression test suite ?
> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
> With GTK3 the result was the same except for some unstable tests. Unity
> desktop has new window decorations like borderless windows which are
> resized by dragging the outer window shadow, invisible overlay
> scrollbars, etc. Many tests written for old window decorations fails.
>>
>> Minor comments :
>>
>> GTKEngine.java
>>
>>  494         Container parent = context.getComponent().getParent();
>>  495         if(GTKLookAndFeel.is3()) {
>>  496             if (parent != null && parent.getParent() instanceof
>> JComboBox) {
>>  497                 if (parent.getParent().hasFocus()) {
>>  498                     synthState |= SynthConstants.FOCUSED;
>>  499                 }
>>  500             }
>>  501         }
>>
>> GTKPainter.java
>>
>> 746         if (GTKLookAndFeel.is3()) {
>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>  748                 y += 1;
>>  749                 h -= 2;
>>  750             } else {
>>  751                 x += 1;
>>  752                 w -= 2;
>>  753             }
>>  754         }
>>
>> I don't know where these numbers come from or what coordinate system
>> is being used here but it seems you are changing them for gtk 2.2 as
>> well as 3
>> Can you speak to this ?
> It is an appearance tuning for GTK3. I didn't change it for GTK2, why do
> you think so?
> This was used before my fix as well, for example
>
>                      if (containerParent instanceof JComboBox) {
>                          x += (focusSize + 2);
>                          y += (focusSize + 1);
>                          w -= (2 * focusSize + 1);
>                          h -= (2 * focusSize + 2);
>                      } else {
>                          x += focusSize;
>                          y += focusSize;
>                          w -= 2 * focusSize;
>                          h -= 2 * focusSize;
>                      }
>
> The only place where I changed the existing GTK2 appearance is:
>
> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", "slider-length");
>
>   in GTKStyle.java, because this property was omitted by mistake.
>>
>> GTKStyle.java
>>
>> 735         if(!GTKLookAndFeel.is3()) {
>>
>> 840      } else if(GTKLookAndFeel.is3() &&
>> "ComboBox.forceOpaque".equals(key)) {
>>
>>
>> we prefer a space between "if" and "("
> Accepted.
>>
>> sun_awt_X11_GtkFileDialogPeer.c
>>
>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>
>>
>> Maybe I am not looking at the right fn but I thought I saw
>> this fn return a boolean so a check against NULL looks wrong.
> The declaration is in GtkApi struct of gtk_interface.h. It returns
> char*. NULL means that the version is compatible.
>>
>>  393
>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>  394                 dialog), TRUE);
>>
>>
>> You didn't add this but it is awfully specific about the GTK version and
>> I wonder if this test is doing what it should be doing on GTK 3?
> Accepted.
>>
>> It is interesting that some equivalent looking Java level dialog
>> checking in XToolkit.java
>> checked for 3.0 too ..
>>
>> swing_GTKEngine.c :
>>
>>   30 /* Static buffer for conversion from java.lang.String to UTF-8 */
>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>
>> So the variable name should be spelt conversionBuffer.
> Accepted.
>>
>> awt_UNIXToolkit.c
>>
>> < 287 free(ret);
>>
>> You deleted this free(). Is that correct ? It seems to imply
>> you now expect a boolean return as discussed above and
>> so in that case NULL looks odd here (line 260) too.
> The JNI exported method returns boolean while the GTK method returns
> char*. free() is deleted intentionally according to the GTK docs it
> belongs to the library and should not be freed by user code.
>>
>> gtk3_interface.h :
>>
>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>
>> I don't think that is completely accurate :-) And I should have
>> reviewed this yesterday [1].
> :) This is glib's definition I just copied.
>
> --Semyon
>>
>> -phil.
>>
>> [1] http://www.piday.org/
>>
>>
>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>
>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>> FileChooser for Linux and AWT Robot for Linux.
>>> Also the new system property is added to request specific GTK version
>>> swing.gtk.version.
>>>
>>> --Semyon
>>
>


-- 
Best regards, Sergey.


From avik.niyogi at oracle.com  Thu Mar 17 13:17:58 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 17 Mar 2016 18:47:58 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <56E941A1.1090402@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
Message-ID: <44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>

Hi Alexander,
The issue only applies for ScrollingTabbedPane and hence this fix.

With Regards,
Avik Niyogi

> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> 
> Does the same issue affects the AquaTabbedPaneContrastUI?
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 09:04, Avik Niyogi wrote:
>> Hi All,
>> A gentle reminder, please review code changes.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>> 
>>> Hi All,
>>> 
>>> Please review code changes done as with inputs provided.
>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>
>>> 
>>> Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
>>> In the new fix as provided, references to base class layout manager is removed in current solution.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>> 
>>>> Hello Avik
>>>> 
>>>> Let me make it clear I don't approve the proposed fix
>>>> and ask you to do additional evaluation.
>>>> 
>>>> Every LookAndFeel is different and it doesn't make much sense
>>>> to compare Metal LaF with AquaLaf.
>>>> 
>>>> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
>>>> 
>>>> The bug you are fixing has the following subject 
>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>> 
>>>> Could you please fix exactly the problem with the minimal heights,
>>>> without changing the UI delegate class.
>>>> 
>>>> Thanks
>>>> alexp
>>>> 
>>>>> Gentle reminder. Please review this fix.
>>>>> 
>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>> 
>>>>>> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>>>  and not TabbedPaneLayout() as which is the default.
>>>>>> 
>>>>>> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
>>>>>> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>>>>>> 
>>>>>> Fixing the minimum size in AquaTabbedPaneUI will fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>>>>> 
>>>>>> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
>>>>>> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>>>>>> 
>>>>>> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>> 
>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hello Avik
>>>>>>> 
>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
>>>>>>> I don't think setting the layout manager from the base class is the right solution here.
>>>>>>> 
>>>>>>> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
>>>>>>> 
>>>>>>> Thanks
>>>>>>> alexp
>>>>>>> 
>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>> 
>>>>>>>> Bug:
>>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8137169>https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>>>>>>> 
>>>>>>>> Webrev:
>>>>>>>> 
>>>>>>>>  <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>
>>>>>>>> 
>>>>>>>> Issue:
>>>>>>>> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>>>>>>>> 
>>>>>>>> Cause:
>>>>>>>> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>> 
>>>>>>>> Fix:
>>>>>>>> Major linking calls to super class fix done within createLayoutManager().
>>>>>>>> 
>>>>>>>> With Regards,
>>>>>>>> Avik Niyogi
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160317/e86c764a/attachment.html>

From avik.niyogi at oracle.com  Thu Mar 17 13:21:32 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 17 Mar 2016 18:51:32 +0530
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
	exception was raised entering Emoji into JTextArea
In-Reply-To: <56E9A536.6090903@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com> <56E9A536.6090903@oracle.com>
Message-ID: <E98C9197-A1A0-4C20-825F-5C36818064F0@oracle.com>

It can be made into a class method, but herein this case it is needed for that instance only and hence the need for instance method and referred with ?self?.

With Regards,
Avik Niyogi
> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> 
> Could the -(NSMutableString *) parseString: method be declared as class method instead of instance?
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 17:18, Sergey Bylokhov wrote:
>> Hi, Avik. 
>> Can you please take a look to these two tests before fixing this bug: 
>> 
>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
>> -------------------------------------------------- 
>> TEST: javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>> 
>> I remember they passed on jdk8, but it seems we have a regression in jdk9 and both of them fail. 
>> 
>> On 14.03.16 8:05, Avik Niyogi wrote: 
>>> Hi All, 
>>> A gentle reminder, please review my code changes. 
>>> 
>>> With Regards, 
>>> Avik Niyogi 
>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com> 
>>>> <mailto:avik.niyogi at oracle.com> <mailto:avik.niyogi at oracle.com>> wrote: 
>>>> 
>>>> Hi All, 
>>>> 
>>>> Kindly review the bug fix for JDK 9. 
>>>> 
>>>> *Bug:* 
>>>> 
>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_ <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
>>>> _ 
>>>> _ 
>>>> *Webrev:* 
>>>> 
>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ <http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_> 
>>>> 
>>>> *Issue:* 
>>>> Emoji selection in Character Viewer was causing exception in JNI 
>>>> 
>>>> *Cause:* 
>>>> Emojis are considered to be of different class type (namely, 
>>>> NSConcreteMutableAttributedString) from NSString which other 
>>>> characters are because of a surrogate pair for them. 
>>>> 
>>>> *Fix:* 
>>>> Major changes done for condition of emojis in JNI. Albeit rendering is 
>>>> not yet supported, they will appear as blank ?Missing font? notation. 
>>>> Also, added debug point in case of issue with glyph arrises. 
>>>> 
>>>> With Regards, 
>>>> Avik Niyogi 
>>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160317/1d99f702/attachment.html>

From semyon.sadetsky at oracle.com  Thu Mar 17 13:25:56 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 17 Mar 2016 16:25:56 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56EAA99E.2040104@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
Message-ID: <56EAB064.9040403@oracle.com>

The awt_Desktop.c is missed in the webrev.
Please see the updated one: 
http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/

--Semyon

On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
> On 16.03.16 20:52, Semyon Sadetsky wrote:
>> Hi Phil,
>>
>> Thank for review. You will find my reply below in the text.
>>
>> The updated webrev is
>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>
> On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):
>
> ERROR: Build failed for target 'images' in configuration 
> 'linux-x86_64-normal-server-release' (exit code 2)
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
> error: implicit declaration of function ?gtk2_load? 
> [-Werror=implicit-function-declaration]
>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>          ^
> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
> error: implicit declaration of function ?gtk2_show_uri_load? 
> [-Werror=implicit-function-declaration]
>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>                            ^
> cc1: all warnings being treated as errors
> === End of repeated output ===
> === Make failure sequence repeated here ===
> Awt2dLibraries.gmk:369: recipe for target 
> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
> failed
> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
> === End of repeated output ===
>
>
>> It also contains:
>> - new properties jdk.gtk.version and jdk.gtk.verbose
>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more but we
>> can do this later as a separate bug.
>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>> appearance changes.
>>
>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>> There is a lot to read here. I think I need to patch and try it but
>>> first ...
>>>
>>> Two high level questions :
>>> 1) Have you verified that this behaves properly (or no worse than
>>> currently) with -Djava.awt.headless=true since Swing components
>>> are supposed to be able to draw off-screen in headless mode .. and
>>> yet a dependency on GTK and its dependency on xlibraries seems to mean
>>> that you can't load GTK in this case.
>>> BTW I think it may be painful to get them to layout in such a case
>>> but that's another issue.
>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>
>>> 2) Have you tried a hi-dpi system ?
>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>
>>> 3) Have you submitted a JPRT job ? It is essential to know that this
>>> builds cleanly on the "official" compilation environment.
>> I will do this before the push. I think it will be OK because I did not
>> use any new C constructs and the new libraries are linked dynamically.
>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>> regression test suite ?
>> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
>> With GTK3 the result was the same except for some unstable tests. Unity
>> desktop has new window decorations like borderless windows which are
>> resized by dragging the outer window shadow, invisible overlay
>> scrollbars, etc. Many tests written for old window decorations fails.
>>>
>>> Minor comments :
>>>
>>> GTKEngine.java
>>>
>>>  494         Container parent = context.getComponent().getParent();
>>>  495         if(GTKLookAndFeel.is3()) {
>>>  496             if (parent != null && parent.getParent() instanceof
>>> JComboBox) {
>>>  497                 if (parent.getParent().hasFocus()) {
>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>  499                 }
>>>  500             }
>>>  501         }
>>>
>>> GTKPainter.java
>>>
>>> 746         if (GTKLookAndFeel.is3()) {
>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>  748                 y += 1;
>>>  749                 h -= 2;
>>>  750             } else {
>>>  751                 x += 1;
>>>  752                 w -= 2;
>>>  753             }
>>>  754         }
>>>
>>> I don't know where these numbers come from or what coordinate system
>>> is being used here but it seems you are changing them for gtk 2.2 as
>>> well as 3
>>> Can you speak to this ?
>> It is an appearance tuning for GTK3. I didn't change it for GTK2, why do
>> you think so?
>> This was used before my fix as well, for example
>>
>>                      if (containerParent instanceof JComboBox) {
>>                          x += (focusSize + 2);
>>                          y += (focusSize + 1);
>>                          w -= (2 * focusSize + 1);
>>                          h -= (2 * focusSize + 2);
>>                      } else {
>>                          x += focusSize;
>>                          y += focusSize;
>>                          w -= 2 * focusSize;
>>                          h -= 2 * focusSize;
>>                      }
>>
>> The only place where I changed the existing GTK2 appearance is:
>>
>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", 
>> "slider-length");
>>
>>   in GTKStyle.java, because this property was omitted by mistake.
>>>
>>> GTKStyle.java
>>>
>>> 735         if(!GTKLookAndFeel.is3()) {
>>>
>>> 840      } else if(GTKLookAndFeel.is3() &&
>>> "ComboBox.forceOpaque".equals(key)) {
>>>
>>>
>>> we prefer a space between "if" and "("
>> Accepted.
>>>
>>> sun_awt_X11_GtkFileDialogPeer.c
>>>
>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>
>>>
>>> Maybe I am not looking at the right fn but I thought I saw
>>> this fn return a boolean so a check against NULL looks wrong.
>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>> char*. NULL means that the version is compatible.
>>>
>>>  393
>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>>  394                 dialog), TRUE);
>>>
>>>
>>> You didn't add this but it is awfully specific about the GTK version 
>>> and
>>> I wonder if this test is doing what it should be doing on GTK 3?
>> Accepted.
>>>
>>> It is interesting that some equivalent looking Java level dialog
>>> checking in XToolkit.java
>>> checked for 3.0 too ..
>>>
>>> swing_GTKEngine.c :
>>>
>>>   30 /* Static buffer for conversion from java.lang.String to UTF-8 */
>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>
>>> So the variable name should be spelt conversionBuffer.
>> Accepted.
>>>
>>> awt_UNIXToolkit.c
>>>
>>> < 287 free(ret);
>>>
>>> You deleted this free(). Is that correct ? It seems to imply
>>> you now expect a boolean return as discussed above and
>>> so in that case NULL looks odd here (line 260) too.
>> The JNI exported method returns boolean while the GTK method returns
>> char*. free() is deleted intentionally according to the GTK docs it
>> belongs to the library and should not be freed by user code.
>>>
>>> gtk3_interface.h :
>>>
>>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>>
>>> I don't think that is completely accurate :-) And I should have
>>> reviewed this yesterday [1].
>> :) This is glib's definition I just copied.
>>
>> --Semyon
>>>
>>> -phil.
>>>
>>> [1] http://www.piday.org/
>>>
>>>
>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>
>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>> FileChooser for Linux and AWT Robot for Linux.
>>>> Also the new system property is added to request specific GTK version
>>>> swing.gtk.version.
>>>>
>>>> --Semyon
>>>
>>
>
>



From alexandr.scherbatiy at oracle.com  Thu Mar 17 13:33:31 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 17 Mar 2016 17:33:31 +0400
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
 exception was raised entering Emoji into JTextArea
In-Reply-To: <E98C9197-A1A0-4C20-825F-5C36818064F0@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com> <56E9A536.6090903@oracle.com>
	<E98C9197-A1A0-4C20-825F-5C36818064F0@oracle.com>
Message-ID: <56EAB22B.8010208@oracle.com>


The fix looks good to me.

Just a small note: it is better to remove comment "527         //" since 
it does not have a description.

Thanks,
Alexandr.

On 17/03/16 17:21, Avik Niyogi wrote:
> It can be made into a class method, but herein this case it is needed 
> for that instance only and hence the need for instance method and 
> referred with ?self?.
>
> With Regards,
> Avik Niyogi
>> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com 
>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>
>>
>> Could the -(NSMutableString *) parseString: method be declared as 
>> class method instead of instance?
>>
>> Thanks,
>> Alexandr.
>>
>> On 14/03/16 17:18, Sergey Bylokhov wrote:
>>> Hi, Avik.
>>> Can you please take a look to these two tests before fixing this bug:
>>>
>>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
>>> --------------------------------------------------
>>> TEST: 
>>> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>>>
>>> I remember they passed on jdk8, but it seems we have a regression in 
>>> jdk9 and both of them fail.
>>>
>>> On 14.03.16 8:05, Avik Niyogi wrote:
>>>> Hi All,
>>>> A gentle reminder, please review my code changes.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com
>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Kindly review the bug fix for JDK 9.
>>>>>
>>>>> *Bug:*
>>>>>
>>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_
>>>>> _
>>>>> _
>>>>> *Webrev:*
>>>>>
>>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_
>>>>>
>>>>> *Issue:*
>>>>> Emoji selection in Character Viewer was causing exception in JNI
>>>>>
>>>>> *Cause:*
>>>>> Emojis are considered to be of different class type (namely,
>>>>> NSConcreteMutableAttributedString) from NSString which other
>>>>> characters are because of a surrogate pair for them.
>>>>>
>>>>> *Fix:*
>>>>> Major changes done for condition of emojis in JNI. Albeit 
>>>>> rendering is
>>>>> not yet supported, they will appear as blank ?Missing font? notation.
>>>>> Also, added debug point in case of issue with glyph arrises.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160317/172e6f54/attachment.html>

From semyon.sadetsky at oracle.com  Thu Mar 17 14:37:57 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 17 Mar 2016 17:37:57 +0300
Subject: <Swing Dev> [9] Review request for 8146301: Enter key does not work
 in a deserialized JFileChooser
Message-ID: <56EAC145.6050209@oracle.com>

Hello,

Please review fix for JDK9:

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

This is a regression of JDK-8021253 in which explicit setting the 
default button was moved to the hierarchy listener but this listener 
disappears after serialization/deserialization cycle because it is not 
serializable. The solution is to make it serializable.

--Semyon


From victor.dyakov at oracle.com  Thu Mar 17 15:25:44 2016
From: victor.dyakov at oracle.com (Victor D'yakov)
Date: Thu, 17 Mar 2016 08:25:44 -0700
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56EAB064.9040403@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com>
Message-ID: <56EACC78.8030200@oracle.com>



On 17.03.2016 6:25, Semyon Sadetsky wrote:
> The awt_Desktop.c is missed in the webrev.
> Please see the updated one: 
> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>
> --Semyon
>
> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>> Hi Phil,
>>>
>>> Thank for review. You will find my reply below in the text.
>>>
>>> The updated webrev is
>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>
>> On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):
>>
>> ERROR: Build failed for target 'images' in configuration 
>> 'linux-x86_64-normal-server-release' (exit code 2)
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>> error: implicit declaration of function ?gtk2_load? 
>> [-Werror=implicit-function-declaration]
>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>          ^
>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>> error: implicit declaration of function ?gtk2_show_uri_load? 
>> [-Werror=implicit-function-declaration]
>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>                            ^
>> cc1: all warnings being treated as errors
>> === End of repeated output ===
>> === Make failure sequence repeated here ===
>> Awt2dLibraries.gmk:369: recipe for target 
>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>> failed
>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>> === End of repeated output ===
>>
>>
>>> It also contains:
>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more 
>>> but we
>>> can do this later as a separate bug.
>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>>> appearance changes.
>>>
>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>> There is a lot to read here. I think I need to patch and try it but
>>>> first ...
>>>>
>>>> Two high level questions :
>>>> 1) Have you verified that this behaves properly (or no worse than
>>>> currently) with -Djava.awt.headless=true since Swing components
>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>> yet a dependency on GTK and its dependency on xlibraries seems to mean
>>>> that you can't load GTK in this case.
>>>> BTW I think it may be painful to get them to layout in such a case
>>>> but that's another issue.
>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>
>>>> 2) Have you tried a hi-dpi system ?
>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>
>>>> 3) Have you submitted a JPRT job ? It is essential to know that this
>>>> builds cleanly on the "official" compilation environment.
>>> I will do this before the push. I think it will be OK because I did not
>>> use any new C constructs and the new libraries are linked dynamically.
Ok.

Please place the JPRT link here on review thread once you are ready.

Thanks,
Victor

>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>> regression test suite ?
>>> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
>>> With GTK3 the result was the same except for some unstable tests. Unity
>>> desktop has new window decorations like borderless windows which are
>>> resized by dragging the outer window shadow, invisible overlay
>>> scrollbars, etc. Many tests written for old window decorations fails.
>>>>
>>>> Minor comments :
>>>>
>>>> GTKEngine.java
>>>>
>>>>  494         Container parent = context.getComponent().getParent();
>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>  496             if (parent != null && parent.getParent() instanceof
>>>> JComboBox) {
>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>  499                 }
>>>>  500             }
>>>>  501         }
>>>>
>>>> GTKPainter.java
>>>>
>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>>  748                 y += 1;
>>>>  749                 h -= 2;
>>>>  750             } else {
>>>>  751                 x += 1;
>>>>  752                 w -= 2;
>>>>  753             }
>>>>  754         }
>>>>
>>>> I don't know where these numbers come from or what coordinate system
>>>> is being used here but it seems you are changing them for gtk 2.2 as
>>>> well as 3
>>>> Can you speak to this ?
>>> It is an appearance tuning for GTK3. I didn't change it for GTK2, 
>>> why do
>>> you think so?
>>> This was used before my fix as well, for example
>>>
>>>                      if (containerParent instanceof JComboBox) {
>>>                          x += (focusSize + 2);
>>>                          y += (focusSize + 1);
>>>                          w -= (2 * focusSize + 1);
>>>                          h -= (2 * focusSize + 2);
>>>                      } else {
>>>                          x += focusSize;
>>>                          y += focusSize;
>>>                          w -= 2 * focusSize;
>>>                          h -= 2 * focusSize;
>>>                      }
>>>
>>> The only place where I changed the existing GTK2 appearance is:
>>>
>>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", 
>>> "slider-length");
>>>
>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>
>>>> GTKStyle.java
>>>>
>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>
>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>
>>>>
>>>> we prefer a space between "if" and "("
>>> Accepted.
>>>>
>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>
>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>
>>>>
>>>> Maybe I am not looking at the right fn but I thought I saw
>>>> this fn return a boolean so a check against NULL looks wrong.
>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>> char*. NULL means that the version is compatible.
>>>>
>>>>  393
>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>>>  394                 dialog), TRUE);
>>>>
>>>>
>>>> You didn't add this but it is awfully specific about the GTK 
>>>> version and
>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>> Accepted.
>>>>
>>>> It is interesting that some equivalent looking Java level dialog
>>>> checking in XToolkit.java
>>>> checked for 3.0 too ..
>>>>
>>>> swing_GTKEngine.c :
>>>>
>>>>   30 /* Static buffer for conversion from java.lang.String to UTF-8 */
>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>
>>>> So the variable name should be spelt conversionBuffer.
>>> Accepted.
>>>>
>>>> awt_UNIXToolkit.c
>>>>
>>>> < 287 free(ret);
>>>>
>>>> You deleted this free(). Is that correct ? It seems to imply
>>>> you now expect a boolean return as discussed above and
>>>> so in that case NULL looks odd here (line 260) too.
>>> The JNI exported method returns boolean while the GTK method returns
>>> char*. free() is deleted intentionally according to the GTK docs it
>>> belongs to the library and should not be freed by user code.
>>>>
>>>> gtk3_interface.h :
>>>>
>>>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>>>
>>>> I don't think that is completely accurate :-) And I should have
>>>> reviewed this yesterday [1].
>>> :) This is glib's definition I just copied.
>>>
>>> --Semyon
>>>>
>>>> -phil.
>>>>
>>>> [1] http://www.piday.org/
>>>>
>>>>
>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>
>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>> Also the new system property is added to request specific GTK version
>>>>> swing.gtk.version.
>>>>>
>>>>> --Semyon
>>>>
>>>
>>
>>
>



From Sergey.Bylokhov at oracle.com  Thu Mar 17 15:55:26 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 17 Mar 2016 18:55:26 +0300
Subject: <Swing Dev> [9] Review request for 8146301: Enter key does not
 work in a deserialized JFileChooser
In-Reply-To: <56EAC145.6050209@oracle.com>
References: <56EAC145.6050209@oracle.com>
Message-ID: <56EAD36E.8090108@oracle.com>

Does the test is passed on all platforms?

On 17.03.16 17:37, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8146301
> webrev: http://cr.openjdk.java.net/~ssadetsky/8146301/webrev.00/
>
> This is a regression of JDK-8021253 in which explicit setting the
> default button was moved to the hierarchy listener but this listener
> disappears after serialization/deserialization cycle because it is not
> serializable. The solution is to make it serializable.
>
> --Semyon


-- 
Best regards, Sergey.


From philip.race at oracle.com  Thu Mar 17 16:42:50 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 17 Mar 2016 09:42:50 -0700
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56EAB064.9040403@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com>
Message-ID: <56EADE8A.9060508@oracle.com>

This reminded me I had not yet tried the build myself.
When I did I not get the error that Sergey did but I got this as well :-

jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
In function ?get_integer_property?:
jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2542:19: 
error: initialization makes integer from pointer without a cast [-Werror]
jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
In function ?get_boolean_property?:
jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2549:19: 
error: initialization makes integer from pointer without

Both lines it complains about were :

     gint intval = NULL;

I changed them to
        gint intval = 0;

I am not using the 'official' compiler, but you really should make sure 
jprt is
happy before confirming the webrev as final - and also fix all of these 
even if
the official compiler does not complain.

And I did not notice any problems running SwingSet2 with either of GTK2 
or GTK3
specified. It at least ran fine and clearly picked up different versions.


-phil.


On 03/17/2016 06:25 AM, Semyon Sadetsky wrote:
> The awt_Desktop.c is missed in the webrev.
> Please see the updated one: 
> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>
> --Semyon
>
> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>> Hi Phil,
>>>
>>> Thank for review. You will find my reply below in the text.
>>>
>>> The updated webrev is
>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>
>> On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):
>>
>> ERROR: Build failed for target 'images' in configuration 
>> 'linux-x86_64-normal-server-release' (exit code 2)
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>> error: implicit declaration of function ?gtk2_load? 
>> [-Werror=implicit-function-declaration]
>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>          ^
>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>> error: implicit declaration of function ?gtk2_show_uri_load? 
>> [-Werror=implicit-function-declaration]
>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>                            ^
>> cc1: all warnings being treated as errors
>> === End of repeated output ===
>> === Make failure sequence repeated here ===
>> Awt2dLibraries.gmk:369: recipe for target 
>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>> failed
>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>> === End of repeated output ===
>>
>>
>>> It also contains:
>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more 
>>> but we
>>> can do this later as a separate bug.
>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>>> appearance changes.
>>>
>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>> There is a lot to read here. I think I need to patch and try it but
>>>> first ...
>>>>
>>>> Two high level questions :
>>>> 1) Have you verified that this behaves properly (or no worse than
>>>> currently) with -Djava.awt.headless=true since Swing components
>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>> yet a dependency on GTK and its dependency on xlibraries seems to mean
>>>> that you can't load GTK in this case.
>>>> BTW I think it may be painful to get them to layout in such a case
>>>> but that's another issue.
>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>
>>>> 2) Have you tried a hi-dpi system ?
>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>
>>>> 3) Have you submitted a JPRT job ? It is essential to know that this
>>>> builds cleanly on the "official" compilation environment.
>>> I will do this before the push. I think it will be OK because I did not
>>> use any new C constructs and the new libraries are linked dynamically.
>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>> regression test suite ?
>>> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
>>> With GTK3 the result was the same except for some unstable tests. Unity
>>> desktop has new window decorations like borderless windows which are
>>> resized by dragging the outer window shadow, invisible overlay
>>> scrollbars, etc. Many tests written for old window decorations fails.
>>>>
>>>> Minor comments :
>>>>
>>>> GTKEngine.java
>>>>
>>>>  494         Container parent = context.getComponent().getParent();
>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>  496             if (parent != null && parent.getParent() instanceof
>>>> JComboBox) {
>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>  499                 }
>>>>  500             }
>>>>  501         }
>>>>
>>>> GTKPainter.java
>>>>
>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>>  748                 y += 1;
>>>>  749                 h -= 2;
>>>>  750             } else {
>>>>  751                 x += 1;
>>>>  752                 w -= 2;
>>>>  753             }
>>>>  754         }
>>>>
>>>> I don't know where these numbers come from or what coordinate system
>>>> is being used here but it seems you are changing them for gtk 2.2 as
>>>> well as 3
>>>> Can you speak to this ?
>>> It is an appearance tuning for GTK3. I didn't change it for GTK2, 
>>> why do
>>> you think so?
>>> This was used before my fix as well, for example
>>>
>>>                      if (containerParent instanceof JComboBox) {
>>>                          x += (focusSize + 2);
>>>                          y += (focusSize + 1);
>>>                          w -= (2 * focusSize + 1);
>>>                          h -= (2 * focusSize + 2);
>>>                      } else {
>>>                          x += focusSize;
>>>                          y += focusSize;
>>>                          w -= 2 * focusSize;
>>>                          h -= 2 * focusSize;
>>>                      }
>>>
>>> The only place where I changed the existing GTK2 appearance is:
>>>
>>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", 
>>> "slider-length");
>>>
>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>
>>>> GTKStyle.java
>>>>
>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>
>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>
>>>>
>>>> we prefer a space between "if" and "("
>>> Accepted.
>>>>
>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>
>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>
>>>>
>>>> Maybe I am not looking at the right fn but I thought I saw
>>>> this fn return a boolean so a check against NULL looks wrong.
>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>> char*. NULL means that the version is compatible.
>>>>
>>>>  393
>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>>>  394                 dialog), TRUE);
>>>>
>>>>
>>>> You didn't add this but it is awfully specific about the GTK 
>>>> version and
>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>> Accepted.
>>>>
>>>> It is interesting that some equivalent looking Java level dialog
>>>> checking in XToolkit.java
>>>> checked for 3.0 too ..
>>>>
>>>> swing_GTKEngine.c :
>>>>
>>>>   30 /* Static buffer for conversion from java.lang.String to UTF-8 */
>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>
>>>> So the variable name should be spelt conversionBuffer.
>>> Accepted.
>>>>
>>>> awt_UNIXToolkit.c
>>>>
>>>> < 287 free(ret);
>>>>
>>>> You deleted this free(). Is that correct ? It seems to imply
>>>> you now expect a boolean return as discussed above and
>>>> so in that case NULL looks odd here (line 260) too.
>>> The JNI exported method returns boolean while the GTK method returns
>>> char*. free() is deleted intentionally according to the GTK docs it
>>> belongs to the library and should not be freed by user code.
>>>>
>>>> gtk3_interface.h :
>>>>
>>>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>>>
>>>> I don't think that is completely accurate :-) And I should have
>>>> reviewed this yesterday [1].
>>> :) This is glib's definition I just copied.
>>>
>>> --Semyon
>>>>
>>>> -phil.
>>>>
>>>> [1] http://www.piday.org/
>>>>
>>>>
>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>
>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>> Also the new system property is added to request specific GTK version
>>>>> swing.gtk.version.
>>>>>
>>>>> --Semyon
>>>>
>>>
>>
>>
>



From philip.race at oracle.com  Thu Mar 17 19:57:37 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 17 Mar 2016 12:57:37 -0700
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56EADE8A.9060508@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com> <56EADE8A.9060508@oracle.com>
Message-ID: <56EB0C31.20300@oracle.com>

I ran your changes (which included my fix) through jprt and all Solaris 
platforms failed as follows :-

jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c", line 37: error: typedef redeclared: GtkWindow (E_TYPEDEF_REDECLARED)
cc: acomp failed for jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c


-phil.

On 03/17/2016 09:42 AM, Phil Race wrote:
> This reminded me I had not yet tried the build myself.
> When I did I not get the error that Sergey did but I got this as well :-
>
> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
> In function ?get_integer_property?:
> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2542:19: 
> error: initialization makes integer from pointer without a cast [-Werror]
> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
> In function ?get_boolean_property?:
> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2549:19: 
> error: initialization makes integer from pointer without
>
> Both lines it complains about were :
>
>     gint intval = NULL;
>
> I changed them to
>        gint intval = 0;
>
> I am not using the 'official' compiler, but you really should make 
> sure jprt is
> happy before confirming the webrev as final - and also fix all of 
> these even if
> the official compiler does not complain.
>
> And I did not notice any problems running SwingSet2 with either of 
> GTK2 or GTK3
> specified. It at least ran fine and clearly picked up different versions.
>
>
> -phil.
>
>
> On 03/17/2016 06:25 AM, Semyon Sadetsky wrote:
>> The awt_Desktop.c is missed in the webrev.
>> Please see the updated one: 
>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>>
>> --Semyon
>>
>> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>> Hi Phil,
>>>>
>>>> Thank for review. You will find my reply below in the text.
>>>>
>>>> The updated webrev is
>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>
>>> On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):
>>>
>>> ERROR: Build failed for target 'images' in configuration 
>>> 'linux-x86_64-normal-server-release' (exit code 2)
>>> === Output from failing command(s) repeated here ===
>>> * For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>>> error: implicit declaration of function ?gtk2_load? 
>>> [-Werror=implicit-function-declaration]
>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>          ^
>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>>> error: implicit declaration of function ?gtk2_show_uri_load? 
>>> [-Werror=implicit-function-declaration]
>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>                            ^
>>> cc1: all warnings being treated as errors
>>> === End of repeated output ===
>>> === Make failure sequence repeated here ===
>>> Awt2dLibraries.gmk:369: recipe for target 
>>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>>> failed
>>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>>> === End of repeated output ===
>>>
>>>
>>>> It also contains:
>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more 
>>>> but we
>>>> can do this later as a separate bug.
>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>>>> appearance changes.
>>>>
>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>> There is a lot to read here. I think I need to patch and try it but
>>>>> first ...
>>>>>
>>>>> Two high level questions :
>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>>> yet a dependency on GTK and its dependency on xlibraries seems to 
>>>>> mean
>>>>> that you can't load GTK in this case.
>>>>> BTW I think it may be painful to get them to layout in such a case
>>>>> but that's another issue.
>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>
>>>>> 2) Have you tried a hi-dpi system ?
>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>
>>>>> 3) Have you submitted a JPRT job ? It is essential to know that this
>>>>> builds cleanly on the "official" compilation environment.
>>>> I will do this before the push. I think it will be OK because I did 
>>>> not
>>>> use any new C constructs and the new libraries are linked dynamically.
>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>>> regression test suite ?
>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
>>>> With GTK3 the result was the same except for some unstable tests. 
>>>> Unity
>>>> desktop has new window decorations like borderless windows which are
>>>> resized by dragging the outer window shadow, invisible overlay
>>>> scrollbars, etc. Many tests written for old window decorations fails.
>>>>>
>>>>> Minor comments :
>>>>>
>>>>> GTKEngine.java
>>>>>
>>>>>  494         Container parent = context.getComponent().getParent();
>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>  496             if (parent != null && parent.getParent() instanceof
>>>>> JComboBox) {
>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>  499                 }
>>>>>  500             }
>>>>>  501         }
>>>>>
>>>>> GTKPainter.java
>>>>>
>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>>>  748                 y += 1;
>>>>>  749                 h -= 2;
>>>>>  750             } else {
>>>>>  751                 x += 1;
>>>>>  752                 w -= 2;
>>>>>  753             }
>>>>>  754         }
>>>>>
>>>>> I don't know where these numbers come from or what coordinate system
>>>>> is being used here but it seems you are changing them for gtk 2.2 as
>>>>> well as 3
>>>>> Can you speak to this ?
>>>> It is an appearance tuning for GTK3. I didn't change it for GTK2, 
>>>> why do
>>>> you think so?
>>>> This was used before my fix as well, for example
>>>>
>>>>                      if (containerParent instanceof JComboBox) {
>>>>                          x += (focusSize + 2);
>>>>                          y += (focusSize + 1);
>>>>                          w -= (2 * focusSize + 1);
>>>>                          h -= (2 * focusSize + 2);
>>>>                      } else {
>>>>                          x += focusSize;
>>>>                          y += focusSize;
>>>>                          w -= 2 * focusSize;
>>>>                          h -= 2 * focusSize;
>>>>                      }
>>>>
>>>> The only place where I changed the existing GTK2 appearance is:
>>>>
>>>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", 
>>>> "slider-length");
>>>>
>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>
>>>>> GTKStyle.java
>>>>>
>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>
>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>
>>>>>
>>>>> we prefer a space between "if" and "("
>>>> Accepted.
>>>>>
>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>
>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>
>>>>>
>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>> char*. NULL means that the version is compatible.
>>>>>
>>>>>  393
>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>>>>  394                 dialog), TRUE);
>>>>>
>>>>>
>>>>> You didn't add this but it is awfully specific about the GTK 
>>>>> version and
>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>> Accepted.
>>>>>
>>>>> It is interesting that some equivalent looking Java level dialog
>>>>> checking in XToolkit.java
>>>>> checked for 3.0 too ..
>>>>>
>>>>> swing_GTKEngine.c :
>>>>>
>>>>>   30 /* Static buffer for conversion from java.lang.String to 
>>>>> UTF-8 */
>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>
>>>>> So the variable name should be spelt conversionBuffer.
>>>> Accepted.
>>>>>
>>>>> awt_UNIXToolkit.c
>>>>>
>>>>> < 287 free(ret);
>>>>>
>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>> you now expect a boolean return as discussed above and
>>>>> so in that case NULL looks odd here (line 260) too.
>>>> The JNI exported method returns boolean while the GTK method returns
>>>> char*. free() is deleted intentionally according to the GTK docs it
>>>> belongs to the library and should not be freed by user code.
>>>>>
>>>>> gtk3_interface.h :
>>>>>
>>>>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>>>>
>>>>> I don't think that is completely accurate :-) And I should have
>>>>> reviewed this yesterday [1].
>>>> :) This is glib's definition I just copied.
>>>>
>>>> --Semyon
>>>>>
>>>>> -phil.
>>>>>
>>>>> [1] http://www.piday.org/
>>>>>
>>>>>
>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK9:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>
>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>> Also the new system property is added to request specific GTK 
>>>>>> version
>>>>>> swing.gtk.version.
>>>>>>
>>>>>> --Semyon
>>>>>
>>>>
>>>
>>>
>>
>



From peter.brunet at oracle.com  Thu Mar 17 21:22:16 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Thu, 17 Mar 2016 16:22:16 -0500
Subject: <Swing Dev> RfR, JDK-8145228 , Java Access Bridge,
 getAccessibleStatesStringFromContext doesn't wrap the call to
 getAccessibleRole
In-Reply-To: <56E6AD2C.5030505@oracle.com>
References: <56D4ABAB.8080504@oracle.com>
	<CAFcJ+g4q12+++_DtS+iEJf=ifLiObBaGF_4Wr=-+n=k_5ETPpQ@mail.gmail.com>
	<56E6AD2C.5030505@oracle.com>
Message-ID: <56EB2008.7010105@oracle.com>

Thanks Alexandr, I fixed that here:
http://cr.openjdk.java.net/~ptbrunet/JDK-8145228/webrev.01/

Pete

On 3/14/16 7:23 AM, Alexander Scherbatiy wrote:
>
>
>  The fix looks good to me.
>
>  There is a small comment about code formatting.
>  I believe that according to the new Java Style Guidelines where
> should not be a space between open brackets "( ()"
> http://cr.openjdk.java.net/~alundblad/styleguide/#toc-lambda-expressions
>
>  Thanks,
>  Alexandr.
>
> On 3/1/2016 2:18 AM, Renaud Paquay wrote:
>> looks good to me -- assuming it is ok to use lambda syntax in this
>> file, the rest of the file still uses the anonymous inner class syntax.
>>
>> On Mon, Feb 29, 2016 at 12:35 PM, Pete Brunet
>> <peter.brunet at oracle.com <mailto:peter.brunet at oracle.com>> wrote:
>>
>>     Please review this change which runs code on the EDT like it
>>     should have.
>>
>>     http://cr.openjdk.java.net/~ptbrunet/JDK-8145228/webrev.00/
>>     <http://cr.openjdk.java.net/%7Eptbrunet/JDK-8145228/webrev.00/>
>>
>>
>



From avik.niyogi at oracle.com  Fri Mar 18 05:46:36 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Fri, 18 Mar 2016 11:16:36 +0530
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
	exception was raised entering Emoji into JTextArea
In-Reply-To: <56E6BA0A.10301@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com>
Message-ID: <510815E4-CD6E-4C40-ABC9-C39EEF224169@oracle.com>

Hi Sergey,
I have tested the test cases as mentioned.
1) They are not related to the current fix
2) ScreenMenuBarInputTwice.java issue is not reproducible.
3) There is a test bug in ActionListenerCalledTwiceTest.java, hence a new test case called ScreenMenuBarInputTwice.java 
was created to encompass actual expectations from Java on OS X as per native behaviour.

Please review my current fix as available in the mail trail. Thank you in advance.

With Regards,
Avik Niyogi


> On 14-Mar-2016, at 6:48 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Avik.
> Can you please take a look to these two tests before fixing this bug:
> 
> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
> --------------------------------------------------
> TEST: javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
> 
> I remember they passed on jdk8, but it seems we have a regression in jdk9 and both of them fail.
> 
> On 14.03.16 8:05, Avik Niyogi wrote:
>> Hi All,
>> A gentle reminder, please review my code changes.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>
>>> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>> wrote:
>>> 
>>> Hi All,
>>> 
>>> Kindly review the bug fix for JDK 9.
>>> 
>>> *Bug:*
>>> 
>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_ <https://bugs.openjdk.java.net/browse/JDK-8148555_>
>>> _
>>> _
>>> *Webrev:*
>>> 
>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_
>>> 
>>> *Issue:*
>>> Emoji selection in Character Viewer was causing exception in JNI
>>> 
>>> *Cause:*
>>> Emojis are considered to be of different class type (namely,
>>> NSConcreteMutableAttributedString) from NSString which other
>>> characters are because of a surrogate pair for them.
>>> 
>>> *Fix:*
>>> Major changes done for condition of emojis in JNI. Albeit rendering is
>>> not yet supported, they will appear as blank ?Missing font? notation.
>>> Also, added debug point in case of issue with glyph arrises.
>>> 
>>> With Regards,
>>> Avik Niyogi
>> 
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160318/a53ee1ad/attachment.html>

From alexandr.scherbatiy at oracle.com  Fri Mar 18 08:51:23 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 18 Mar 2016 12:51:23 +0400
Subject: <Swing Dev> RfR, JDK-8145228 , Java Access Bridge,
 getAccessibleStatesStringFromContext doesn't wrap the call to
 getAccessibleRole
In-Reply-To: <56EB2008.7010105@oracle.com>
References: <56D4ABAB.8080504@oracle.com>
	<CAFcJ+g4q12+++_DtS+iEJf=ifLiObBaGF_4Wr=-+n=k_5ETPpQ@mail.gmail.com>
	<56E6AD2C.5030505@oracle.com> <56EB2008.7010105@oracle.com>
Message-ID: <56EBC18B.9050205@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 18/03/16 01:22, Pete Brunet wrote:
> Thanks Alexandr, I fixed that here:
> http://cr.openjdk.java.net/~ptbrunet/JDK-8145228/webrev.01/
>
> Pete
>
> On 3/14/16 7:23 AM, Alexander Scherbatiy wrote:
>>
>>   The fix looks good to me.
>>
>>   There is a small comment about code formatting.
>>   I believe that according to the new Java Style Guidelines where
>> should not be a space between open brackets "( ()"
>> http://cr.openjdk.java.net/~alundblad/styleguide/#toc-lambda-expressions
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 3/1/2016 2:18 AM, Renaud Paquay wrote:
>>> looks good to me -- assuming it is ok to use lambda syntax in this
>>> file, the rest of the file still uses the anonymous inner class syntax.
>>>
>>> On Mon, Feb 29, 2016 at 12:35 PM, Pete Brunet
>>> <peter.brunet at oracle.com <mailto:peter.brunet at oracle.com>> wrote:
>>>
>>>      Please review this change which runs code on the EDT like it
>>>      should have.
>>>
>>>      http://cr.openjdk.java.net/~ptbrunet/JDK-8145228/webrev.00/
>>>      <http://cr.openjdk.java.net/%7Eptbrunet/JDK-8145228/webrev.00/>
>>>
>>>



From alexandr.scherbatiy at oracle.com  Fri Mar 18 08:58:57 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 18 Mar 2016 12:58:57 +0400
Subject: <Swing Dev> [9] Review request for 8152159 LabelUI is not updated
 for TitledBorder
Message-ID: <56EBC351.3090206@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8152159
   webrev: http://cr.openjdk.java.net/~alexsch/8152159/webrev.00


   The TitledBorder label is only used for painting and does not belong  
to any component hierarchy so it is not updated by 
SwingUtilities.updateComponentTreeUI() method.
   The fix updates the  TitledBorder label UI when the label is requested.

   Thanks,
   Alexandr.


From alexandr.scherbatiy at oracle.com  Fri Mar 18 09:12:12 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 18 Mar 2016 13:12:12 +0400
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
 minimal heigh of JTabbedPane with more tabs
In-Reply-To: <44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
Message-ID: <56EBC66C.2060605@oracle.com>


It is not usually a good idea to have a duplicated code which should be 
updated every time in several places.

Is it possible to move the  methods used both in 
AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  
to TabbedPaneLayout with different names and then reused?

Thanks,
Alexandr.

On 17/03/16 17:17, Avik Niyogi wrote:
> Hi Alexander,
> The issue only applies for ScrollingTabbedPane and hence this fix.
>
> With Regards,
> Avik Niyogi
>
>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com 
>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>
>>
>> Does the same issue affects the AquaTabbedPaneContrastUI?
>>
>> Thanks,
>> Alexandr.
>>
>> On 14/03/16 09:04, Avik Niyogi wrote:
>>> Hi All,
>>> A gentle reminder, please review code changes.
>>>
>>> With Regards,
>>> Avik Niyogi
>>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> Please review code changes done as with inputs provided.
>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>
>>>>
>>>> Also, albeit the title of issue mentioned is as above, the 
>>>> injection of issue occurs because 
>>>> *pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT);* is not 
>>>> honoured.
>>>> In the new fix as provided, references to base class layout manager 
>>>> is removed in current solution.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>
>>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin 
>>>>> <alexander.potochkin at oracle.com> wrote:
>>>>>
>>>>> Hello Avik
>>>>>
>>>>> Let me make it clear I don't approve the proposed fix
>>>>> and ask you to do additional evaluation.
>>>>>
>>>>> Every LookAndFeel is different and it doesn't make much sense
>>>>> to compare Metal LaF with AquaLaf.
>>>>>
>>>>> The AquaLaf mimics the native MacOS controls and therefore look 
>>>>> quite different from any other Lafs.
>>>>>
>>>>> The bug you are fixing has the following subject
>>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>>>
>>>>> Could you please fix exactly the problem with the minimal heights,
>>>>> without changing the UI delegate class.
>>>>>
>>>>> Thanks
>>>>> alexp
>>>>>
>>>>>> Gentle reminder. Please review this fix.
>>>>>>
>>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi 
>>>>>>> <avik.niyogi at oracle.com> wrote:
>>>>>>>
>>>>>>> The issue is with setting of TabbedPane*Scroll*Layout() for the 
>>>>>>> option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>>>>  and *not* TabbedPaneLayout() as which is the default.
>>>>>>>
>>>>>>> The minimum size fixes itself because the *ScrollLayout* check 
>>>>>>> fails in *setTabLayoutPolicy*() for the pane. So the issue is 
>>>>>>> with the call to set layout manager.
>>>>>>> There are only two configurations that the *JTabbedPane* can 
>>>>>>> exist in of which *SCROLL_TAB_LAYOUT* is one of them.
>>>>>>>
>>>>>>> Fixing the minimum size in *AquaTabbedPaneUI* will fix it for 
>>>>>>> *TabbedPaneLayout*() only which is the *WRAP_TAB_LAYOUT*.
>>>>>>>
>>>>>>> Also, I have checked other implementations such as for *Metal* 
>>>>>>> and *Motif* and *they have similar code for doing this process*.
>>>>>>> Hence, with in-depth analysis, this fix has no other impact 
>>>>>>> apart from this fix.
>>>>>>>
>>>>>>> In case the impact caused by this change has caused some 
>>>>>>> definitive regressions, please mention them so they can be 
>>>>>>> addressed. Thank you.
>>>>>>>
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>>
>>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin 
>>>>>>>> <alexander.potochkin at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hello Avik
>>>>>>>>
>>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is 
>>>>>>>> specific for the AquaTabbedPaneUI.
>>>>>>>> I don't think setting the layout manager from the base class is 
>>>>>>>> the right solution here.
>>>>>>>>
>>>>>>>> If there is a problem with minimum size it should be fixed 
>>>>>>>> inside the AquaTabbedPaneUI
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> alexp
>>>>>>>>
>>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>>
>>>>>>>>> *Bug:*
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8137169
>>>>>>>>>
>>>>>>>>> *Webrev:*
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/
>>>>>>>>>
>>>>>>>>> *Issue:*
>>>>>>>>> For Aqua Look&Feel, multiple calls 
>>>>>>>>> to pane.getMinimumSize().height causes incremental return of 
>>>>>>>>> values.
>>>>>>>>>
>>>>>>>>> *Cause:*
>>>>>>>>> The impact was caused by a major broken code within 
>>>>>>>>> AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>>>
>>>>>>>>> *Fix:*
>>>>>>>>> Major linking calls to super class fix done within 
>>>>>>>>> createLayoutManager().
>>>>>>>>>
>>>>>>>>> With Regards,
>>>>>>>>> Avik Niyogi
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160318/90bea3f4/attachment.html>

From avik.niyogi at oracle.com  Fri Mar 18 10:21:22 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Fri, 18 Mar 2016 15:51:22 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <56EBC66C.2060605@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
Message-ID: <824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>

Hi Alexander,
Thank you for the inputs. I agree with you and did feel the need for removing duplicate code as well. But as per an earlier review input, changes to the super call lay outing is not accepted. This was the only other feasible solution. Created redundant code in this process, but would be maintaining with requirements with code impact to superclasses.
Please provide any insight to a probable compensate to mitigate this dichotomy of code expectation. Thank you in advance.

With Regards,
Avik Niyogi
> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> 
> It is not usually a good idea to have a duplicated code which should be updated every time in several places.
> 
> Is it possible to move the  methods used both in AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with different names and then reused?
> 
> Thanks,
> Alexandr.
> 
> On 17/03/16 17:17, Avik Niyogi wrote:
>> Hi Alexander,
>> The issue only applies for ScrollingTabbedPane and hence this fix.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>> 
>>> 
>>> Does the same issue affects the AquaTabbedPaneContrastUI?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 14/03/16 09:04, Avik Niyogi wrote:
>>>> Hi All,
>>>> A gentle reminder, please review code changes.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> Please review code changes done as with inputs provided.
>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>
>>>>> 
>>>>> Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
>>>>> In the new fix as provided, references to base class layout manager is removed in current solution.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>> 
>>>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>> 
>>>>>> Hello Avik
>>>>>> 
>>>>>> Let me make it clear I don't approve the proposed fix
>>>>>> and ask you to do additional evaluation.
>>>>>> 
>>>>>> Every LookAndFeel is different and it doesn't make much sense
>>>>>> to compare Metal LaF with AquaLaf.
>>>>>> 
>>>>>> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
>>>>>> 
>>>>>> The bug you are fixing has the following subject 
>>>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>>>> 
>>>>>> Could you please fix exactly the problem with the minimal heights,
>>>>>> without changing the UI delegate class.
>>>>>> 
>>>>>> Thanks
>>>>>> alexp
>>>>>> 
>>>>>>> Gentle reminder. Please review this fix.
>>>>>>> 
>>>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>>>>>  and not TabbedPaneLayout() as which is the default.
>>>>>>>> 
>>>>>>>> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
>>>>>>>> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>>>>>>>> 
>>>>>>>> Fixing the minimum size in AquaTabbedPaneUI will fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>>>>>>> 
>>>>>>>> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
>>>>>>>> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>>>>>>>> 
>>>>>>>> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>>>>>>>> 
>>>>>>>> With Regards,
>>>>>>>> Avik Niyogi
>>>>>>>> 
>>>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>>>>> 
>>>>>>>>> Hello Avik
>>>>>>>>> 
>>>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
>>>>>>>>> I don't think setting the layout manager from the base class is the right solution here.
>>>>>>>>> 
>>>>>>>>> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> alexp
>>>>>>>>> 
>>>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>> 
>>>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>>> 
>>>>>>>>>> Bug:
>>>>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8137169>https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>>>>>>>>> 
>>>>>>>>>> Webrev:
>>>>>>>>>> 
>>>>>>>>>>  <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>
>>>>>>>>>> 
>>>>>>>>>> Issue:
>>>>>>>>>> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>>>>>>>>>> 
>>>>>>>>>> Cause:
>>>>>>>>>> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>>>> 
>>>>>>>>>> Fix:
>>>>>>>>>> Major linking calls to super class fix done within createLayoutManager().
>>>>>>>>>> 
>>>>>>>>>> With Regards,
>>>>>>>>>> Avik Niyogi
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160318/3e812939/attachment.html>

From andrej.golovnin at gmail.com  Fri Mar 18 10:30:15 2016
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Fri, 18 Mar 2016 11:30:15 +0100
Subject: <Swing Dev> RfR, JDK-8145228 , Java Access Bridge,
 getAccessibleStatesStringFromContext doesn't wrap the call to
 getAccessibleRole
In-Reply-To: <56EBC18B.9050205@oracle.com>
References: <56D4ABAB.8080504@oracle.com>
	<CAFcJ+g4q12+++_DtS+iEJf=ifLiObBaGF_4Wr=-+n=k_5ETPpQ@mail.gmail.com>
	<56E6AD2C.5030505@oracle.com> <56EB2008.7010105@oracle.com>
	<56EBC18B.9050205@oracle.com>
Message-ID: <CAM6ZMz-12+CyRkPftiNYffP=k8Hm+qhzO+E_gbexth-B4sNfsg@mail.gmail.com>

Hi Pete,

>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145228/webrev.01/

please consider using method reference instead of a lambda in:

1411                     AccessibleRole role =
InvocationUtils.invokeAndWait(() -> {
1412                             return ac.getAccessibleRole();
1413                         }, ac);

You can rewrite it as:

1411                     AccessibleRole role =
InvocationUtils.invokeAndWait(ac::getAccessibleRole, ac);

In the first case the Java compiler would generate a syntactic method
and in the second case not.

Best regards,
Andrej Golovnin


From semyon.sadetsky at oracle.com  Fri Mar 18 12:37:28 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 18 Mar 2016 15:37:28 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56EA9929.9020605@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
Message-ID: <56EBF688.1090006@oracle.com>



On 3/17/2016 2:46 PM, Sergey Bylokhov wrote:
> Small notes:
>  - It will be good to move the code which reads the system properties 
> to the static init block, otherwise we can be in trouble if these 
> properties will be changed at runtime.
I don't' see any troubles with this. Can you describe the scenario you 
meant?
I think the properties changing at run-time is useful because it gives 
better control over GTK load. For example, developer may change the 
order to GTK3->GTK2.
>  - Is it necessary to use ordinal? can we replace it with some 
> specific data?(the same for the indexed access in .values()[..])
In general I'm good. But what specific data you propose?

--Semyon
>
> On 16.03.16 20:52, Semyon Sadetsky wrote:
>> Hi Phil,
>>
>> Thank for review. You will find my reply below in the text.
>>
>> The updated webrev is
>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>> It also contains:
>> - new properties jdk.gtk.version and jdk.gtk.verbose
>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more but we
>> can do this later as a separate bug.
>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>> appearance changes.
>>
>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>> There is a lot to read here. I think I need to patch and try it but
>>> first ...
>>>
>>> Two high level questions :
>>> 1) Have you verified that this behaves properly (or no worse than
>>> currently) with -Djava.awt.headless=true since Swing components
>>> are supposed to be able to draw off-screen in headless mode .. and
>>> yet a dependency on GTK and its dependency on xlibraries seems to mean
>>> that you can't load GTK in this case.
>>> BTW I think it may be painful to get them to layout in such a case
>>> but that's another issue.
>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>
>>> 2) Have you tried a hi-dpi system ?
>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>
>>> 3) Have you submitted a JPRT job ? It is essential to know that this
>>> builds cleanly on the "official" compilation environment.
>> I will do this before the push. I think it will be OK because I did not
>> use any new C constructs and the new libraries are linked dynamically.
>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>> regression test suite ?
>> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
>> With GTK3 the result was the same except for some unstable tests. Unity
>> desktop has new window decorations like borderless windows which are
>> resized by dragging the outer window shadow, invisible overlay
>> scrollbars, etc. Many tests written for old window decorations fails.
>>>
>>> Minor comments :
>>>
>>> GTKEngine.java
>>>
>>>  494         Container parent = context.getComponent().getParent();
>>>  495         if(GTKLookAndFeel.is3()) {
>>>  496             if (parent != null && parent.getParent() instanceof
>>> JComboBox) {
>>>  497                 if (parent.getParent().hasFocus()) {
>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>  499                 }
>>>  500             }
>>>  501         }
>>>
>>> GTKPainter.java
>>>
>>> 746         if (GTKLookAndFeel.is3()) {
>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>  748                 y += 1;
>>>  749                 h -= 2;
>>>  750             } else {
>>>  751                 x += 1;
>>>  752                 w -= 2;
>>>  753             }
>>>  754         }
>>>
>>> I don't know where these numbers come from or what coordinate system
>>> is being used here but it seems you are changing them for gtk 2.2 as
>>> well as 3
>>> Can you speak to this ?
>> It is an appearance tuning for GTK3. I didn't change it for GTK2, why do
>> you think so?
>> This was used before my fix as well, for example
>>
>>                      if (containerParent instanceof JComboBox) {
>>                          x += (focusSize + 2);
>>                          y += (focusSize + 1);
>>                          w -= (2 * focusSize + 1);
>>                          h -= (2 * focusSize + 2);
>>                      } else {
>>                          x += focusSize;
>>                          y += focusSize;
>>                          w -= 2 * focusSize;
>>                          h -= 2 * focusSize;
>>                      }
>>
>> The only place where I changed the existing GTK2 appearance is:
>>
>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", 
>> "slider-length");
>>
>>   in GTKStyle.java, because this property was omitted by mistake.
>>>
>>> GTKStyle.java
>>>
>>> 735         if(!GTKLookAndFeel.is3()) {
>>>
>>> 840      } else if(GTKLookAndFeel.is3() &&
>>> "ComboBox.forceOpaque".equals(key)) {
>>>
>>>
>>> we prefer a space between "if" and "("
>> Accepted.
>>>
>>> sun_awt_X11_GtkFileDialogPeer.c
>>>
>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>
>>>
>>> Maybe I am not looking at the right fn but I thought I saw
>>> this fn return a boolean so a check against NULL looks wrong.
>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>> char*. NULL means that the version is compatible.
>>>
>>>  393
>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>>  394                 dialog), TRUE);
>>>
>>>
>>> You didn't add this but it is awfully specific about the GTK version 
>>> and
>>> I wonder if this test is doing what it should be doing on GTK 3?
>> Accepted.
>>>
>>> It is interesting that some equivalent looking Java level dialog
>>> checking in XToolkit.java
>>> checked for 3.0 too ..
>>>
>>> swing_GTKEngine.c :
>>>
>>>   30 /* Static buffer for conversion from java.lang.String to UTF-8 */
>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>
>>> So the variable name should be spelt conversionBuffer.
>> Accepted.
>>>
>>> awt_UNIXToolkit.c
>>>
>>> < 287 free(ret);
>>>
>>> You deleted this free(). Is that correct ? It seems to imply
>>> you now expect a boolean return as discussed above and
>>> so in that case NULL looks odd here (line 260) too.
>> The JNI exported method returns boolean while the GTK method returns
>> char*. free() is deleted intentionally according to the GTK docs it
>> belongs to the library and should not be freed by user code.
>>>
>>> gtk3_interface.h :
>>>
>>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>>
>>> I don't think that is completely accurate :-) And I should have
>>> reviewed this yesterday [1].
>> :) This is glib's definition I just copied.
>>
>> --Semyon
>>>
>>> -phil.
>>>
>>> [1] http://www.piday.org/
>>>
>>>
>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>
>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>> FileChooser for Linux and AWT Robot for Linux.
>>>> Also the new system property is added to request specific GTK version
>>>> swing.gtk.version.
>>>>
>>>> --Semyon
>>>
>>
>
>



From semyon.sadetsky at oracle.com  Fri Mar 18 13:02:02 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 18 Mar 2016 16:02:02 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56EB0C31.20300@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com> <56EADE8A.9060508@oracle.com>
	<56EB0C31.20300@oracle.com>
Message-ID: <56EBFC4A.3080908@oracle.com>



On 3/17/2016 10:57 PM, Phil Race wrote:
> I ran your changes (which included my fix) through jprt and all 
> Solaris platforms failed as follows :-
>
> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c", 
> line 37: error: typedef redeclared: GtkWindow (E_TYPEDEF_REDECLARED)
> cc: acomp failed for 
> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c
>
I have fixed the Solaris build: 
http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.03/.

 > gint intval = NULL;
I think this happens with you specific compiler only. Old 
gtk2_interface.c always contained the same line.

I ran JPRT with webrev.03. The URL is:
http://sthjprt.uk.oracle.com/archives/2016/03/2016-03-18-070745.ssadetsk.client/
It seem macosx_x64_10.9-product-c2-jdk_math build failed because of 
another change. (?) Could you help me to interpret the JPRT job status?

--Semyon
>
> -phil.
>
> On 03/17/2016 09:42 AM, Phil Race wrote:
>> This reminded me I had not yet tried the build myself.
>> When I did I not get the error that Sergey did but I got this as well :-
>>
>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>> In function ?get_integer_property?:
>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2542:19: 
>> error: initialization makes integer from pointer without a cast 
>> [-Werror]
>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>> In function ?get_boolean_property?:
>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2549:19: 
>> error: initialization makes integer from pointer without
>>
>> Both lines it complains about were :
>>
>>     gint intval = NULL;
>>
>> I changed them to
>>        gint intval = 0;
>>
>> I am not using the 'official' compiler, but you really should make 
>> sure jprt is
>> happy before confirming the webrev as final - and also fix all of 
>> these even if
>> the official compiler does not complain.
>>
>> And I did not notice any problems running SwingSet2 with either of 
>> GTK2 or GTK3
>> specified. It at least ran fine and clearly picked up different 
>> versions.
>>
>>
>> -phil.
>>
>>
>> On 03/17/2016 06:25 AM, Semyon Sadetsky wrote:
>>> The awt_Desktop.c is missed in the webrev.
>>> Please see the updated one: 
>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>>>
>>> --Semyon
>>>
>>> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>> Hi Phil,
>>>>>
>>>>> Thank for review. You will find my reply below in the text.
>>>>>
>>>>> The updated webrev is
>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>
>>>> On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):
>>>>
>>>> ERROR: Build failed for target 'images' in configuration 
>>>> 'linux-x86_64-normal-server-release' (exit code 2)
>>>> === Output from failing command(s) repeated here ===
>>>> * For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>>>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>>>> error: implicit declaration of function ?gtk2_load? 
>>>> [-Werror=implicit-function-declaration]
>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>          ^
>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>>>> error: implicit declaration of function ?gtk2_show_uri_load? 
>>>> [-Werror=implicit-function-declaration]
>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>                            ^
>>>> cc1: all warnings being treated as errors
>>>> === End of repeated output ===
>>>> === Make failure sequence repeated here ===
>>>> Awt2dLibraries.gmk:369: recipe for target 
>>>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>>>> failed
>>>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>>>> === End of repeated output ===
>>>>
>>>>
>>>>> It also contains:
>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more 
>>>>> but we
>>>>> can do this later as a separate bug.
>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>>>>> appearance changes.
>>>>>
>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>> There is a lot to read here. I think I need to patch and try it but
>>>>>> first ...
>>>>>>
>>>>>> Two high level questions :
>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>>>> yet a dependency on GTK and its dependency on xlibraries seems to 
>>>>>> mean
>>>>>> that you can't load GTK in this case.
>>>>>> BTW I think it may be painful to get them to layout in such a case
>>>>>> but that's another issue.
>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>
>>>>>> 2) Have you tried a hi-dpi system ?
>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>
>>>>>> 3) Have you submitted a JPRT job ? It is essential to know that this
>>>>>> builds cleanly on the "official" compilation environment.
>>>>> I will do this before the push. I think it will be OK because I 
>>>>> did not
>>>>> use any new C constructs and the new libraries are linked 
>>>>> dynamically.
>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>>>> regression test suite ?
>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
>>>>> With GTK3 the result was the same except for some unstable tests. 
>>>>> Unity
>>>>> desktop has new window decorations like borderless windows which are
>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>> scrollbars, etc. Many tests written for old window decorations fails.
>>>>>>
>>>>>> Minor comments :
>>>>>>
>>>>>> GTKEngine.java
>>>>>>
>>>>>>  494         Container parent = context.getComponent().getParent();
>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>  496             if (parent != null && parent.getParent() instanceof
>>>>>> JComboBox) {
>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>  499                 }
>>>>>>  500             }
>>>>>>  501         }
>>>>>>
>>>>>> GTKPainter.java
>>>>>>
>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>>>>  748                 y += 1;
>>>>>>  749                 h -= 2;
>>>>>>  750             } else {
>>>>>>  751                 x += 1;
>>>>>>  752                 w -= 2;
>>>>>>  753             }
>>>>>>  754         }
>>>>>>
>>>>>> I don't know where these numbers come from or what coordinate system
>>>>>> is being used here but it seems you are changing them for gtk 2.2 as
>>>>>> well as 3
>>>>>> Can you speak to this ?
>>>>> It is an appearance tuning for GTK3. I didn't change it for GTK2, 
>>>>> why do
>>>>> you think so?
>>>>> This was used before my fix as well, for example
>>>>>
>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>                          x += (focusSize + 2);
>>>>>                          y += (focusSize + 1);
>>>>>                          w -= (2 * focusSize + 1);
>>>>>                          h -= (2 * focusSize + 2);
>>>>>                      } else {
>>>>>                          x += focusSize;
>>>>>                          y += focusSize;
>>>>>                          w -= 2 * focusSize;
>>>>>                          h -= 2 * focusSize;
>>>>>                      }
>>>>>
>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>
>>>>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", 
>>>>> "slider-length");
>>>>>
>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>
>>>>>> GTKStyle.java
>>>>>>
>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>
>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>
>>>>>>
>>>>>> we prefer a space between "if" and "("
>>>>> Accepted.
>>>>>>
>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>
>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>
>>>>>>
>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>> char*. NULL means that the version is compatible.
>>>>>>
>>>>>>  393
>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>
>>>>>>  394                 dialog), TRUE);
>>>>>>
>>>>>>
>>>>>> You didn't add this but it is awfully specific about the GTK 
>>>>>> version and
>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>> Accepted.
>>>>>>
>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>> checking in XToolkit.java
>>>>>> checked for 3.0 too ..
>>>>>>
>>>>>> swing_GTKEngine.c :
>>>>>>
>>>>>>   30 /* Static buffer for conversion from java.lang.String to 
>>>>>> UTF-8 */
>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>
>>>>>> So the variable name should be spelt conversionBuffer.
>>>>> Accepted.
>>>>>>
>>>>>> awt_UNIXToolkit.c
>>>>>>
>>>>>> < 287 free(ret);
>>>>>>
>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>> you now expect a boolean return as discussed above and
>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>> The JNI exported method returns boolean while the GTK method returns
>>>>> char*. free() is deleted intentionally according to the GTK docs it
>>>>> belongs to the library and should not be freed by user code.
>>>>>>
>>>>>> gtk3_interface.h :
>>>>>>
>>>>>>   36 #define G_PI 
>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>
>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>> reviewed this yesterday [1].
>>>>> :) This is glib's definition I just copied.
>>>>>
>>>>> --Semyon
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> [1] http://www.piday.org/
>>>>>>
>>>>>>
>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review fix for JDK9:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>
>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>> Also the new system property is added to request specific GTK 
>>>>>>> version
>>>>>>> swing.gtk.version.
>>>>>>>
>>>>>>> --Semyon
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>



From peter.brunet at oracle.com  Fri Mar 18 15:25:57 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 18 Mar 2016 10:25:57 -0500
Subject: <Swing Dev> RfR, JDK-8145228 , Java Access Bridge,
 getAccessibleStatesStringFromContext doesn't wrap the call to
 getAccessibleRole
In-Reply-To: <CAM6ZMz-12+CyRkPftiNYffP=k8Hm+qhzO+E_gbexth-B4sNfsg@mail.gmail.com>
References: <56D4ABAB.8080504@oracle.com>
	<CAFcJ+g4q12+++_DtS+iEJf=ifLiObBaGF_4Wr=-+n=k_5ETPpQ@mail.gmail.com>
	<56E6AD2C.5030505@oracle.com> <56EB2008.7010105@oracle.com>
	<56EBC18B.9050205@oracle.com>
	<CAM6ZMz-12+CyRkPftiNYffP=k8Hm+qhzO+E_gbexth-B4sNfsg@mail.gmail.com>
Message-ID: <56EC1E05.7030708@oracle.com>

Thanks Andrej, That's a good idea.  I already pushed the patch for
8145228 but I opened a new bug for this work:
https://bugs.openjdk.java.net/browse/JDK-8152192

Pete

On 3/18/16 5:30 AM, Andrej Golovnin wrote:
> Hi Pete,
>
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145228/webrev.01/
> please consider using method reference instead of a lambda in:
>
> 1411                     AccessibleRole role =
> InvocationUtils.invokeAndWait(() -> {
> 1412                             return ac.getAccessibleRole();
> 1413                         }, ac);
>
> You can rewrite it as:
>
> 1411                     AccessibleRole role =
> InvocationUtils.invokeAndWait(ac::getAccessibleRole, ac);
>
> In the first case the Java compiler would generate a syntactic method
> and in the second case not.
>
> Best regards,
> Andrej Golovnin



From semyon.sadetsky at oracle.com  Fri Mar 18 15:40:29 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 18 Mar 2016 18:40:29 +0300
Subject: <Swing Dev> [9] Review request for 8152159 LabelUI is not
 updated for TitledBorder
In-Reply-To: <56EBC351.3090206@oracle.com>
References: <56EBC351.3090206@oracle.com>
Message-ID: <56EC216D.9030104@oracle.com>

Hi Alexander,

Maybe it would be more optimal to update UI in a property change 
listener added to the UIManager?

     public void propertyChange(PropertyChangeEvent e) {
         if ("lookAndFeel" == e.getPropertyName()) {
               label.updateUI();
         }
     }

--Semyon

On 3/18/2016 11:58 AM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8152159
>   webrev: http://cr.openjdk.java.net/~alexsch/8152159/webrev.00
>
>
>   The TitledBorder label is only used for painting and does not 
> belong  to any component hierarchy so it is not updated by 
> SwingUtilities.updateComponentTreeUI() method.
>   The fix updates the  TitledBorder label UI when the label is requested.
>
>   Thanks,
>   Alexandr.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160318/bb7a9e56/attachment.html>

From alexandr.scherbatiy at oracle.com  Fri Mar 18 15:49:29 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 18 Mar 2016 19:49:29 +0400
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56AB8A94.2070404@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com>
Message-ID: <56EC2389.3020507@oracle.com>


Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/

   - Public TextUIDrawing interface is added to the javax.swing.plaf 
package
   - TextUIDrawing methods description does not mention component 
properties to be more general
   - TextUIDrawing methods are made default
   - L&F sets an instance of the TextUIDrawing to look and feel defaults 
using "uiDrawing.text" property
   - ComponentUI class is not changed
   - Each ComponentUI reads TextUIDrawing from UI defaults
   - There is an interesting issue described in
http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
     which is related to the fact that MetalLabelUI returns a static 
field from createUI() method.
     TitleBorder creates a JLabel but does not put it to any component 
hierarchy. In this case SwingUtilities.updateComponentTreeUI() method 
calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI field 
and sets a new LabelUI for ordinary labels. The TitleBorder label UI is 
not changed in this case and it still uses the metalLabelUI field which 
is not initialized.
     It seems that other applications can also use components just for 
drawing and have the same issue.
     For this case the textUIDrawing field is not cleared in the 
uninstallDefaults but just set to a static default value which should 
not lead to memory leaks.

   Thanks,
   Alexandr.

On 29/01/16 19:51, Alexander Scherbatiy wrote:
> On 25/01/16 13:44, Andrej Golovnin wrote:
>> Hi Alexandr,
>>
>>> Could you review the updated fix:
>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>> ....
>>> - public TextUIDrawing interface is added to the javax.swing.plaf 
>>> package
>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>> ComponentUI class
>>> - L&F sets an instance of the TextUIDrawing to look and feel 
>>> defaults using
>>> "uiDrawing.text" property
>>> - Look and Feel delegates use the instance of the TextUIDrawing for 
>>> text
>>> drawing and measuring
>> Some thoughts on the current design/implementation:
>>
>> By adding a field to the ComponentUI class the current implementation 
>> increases
>> memory consumption for all Swing applications. And you get the 
>> feeling that
>> there are different implementations of TextUIDrawing per ComponentUI 
>> instances.
>> Personally I can't imagine to have different implementations of
>> TextUIDrawing for
>> a given LookAndFeel. If I would design/implement it, then I would
>> implement it as
>> a property of the LookAndFeel class (similar to LayoutStyle) and not
>> the ComponentUI.
>> Developers can use then the following code to obtain the instance of
>> TextUIDrawing:
>>
>> UIManager.getLookAndFeel().getUIDrawing() // or
>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>> short cut for the line above.
>   LayoutStyle keeps its instance per App context. The same is for the 
> LookAndFeel
>   when it is got through UIManager.getLookAndFeel() call.
>   It means that accessing an instance of a TextUIDrawing will leads to 
> a time consumption.
>
>   There are 3 main ways of the SwingUtilities2.drawString(...) usage:
>   1. ComponentUI classes
>   2. Components created in UI (like BasicInternalFrameTitlePane)
>   3. Public utilities methods (like WindowsGraphicsUtils.paintText())
>
>   For the cases 1 and 2 it is possible to load and store the UIDrawing 
> instance during installUI()/updateUI() calls to decrease a time access 
> to it.
>
>   For the case 3 it is necessary to get LookAndFeel instance each time 
> (which is taken from an App context)
>   or use the passed JComponent object. It requires to have a public 
> method and the associated variable for each instance of 
> JComponent/ComponentUI/... class.
>> You can use this methods then in JDK too.
>>
>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>> more useful methods,
>> e.g. a method to create a composite font, a method to convert DLUs to 
>> pixels.
>   UIDrawing name may look like it should be used for any UI drawing, 
> not only for text ones. I am afraid that it can be misleading.
>
>   Thanks,
>   Alexandr.
>
>>
>> Best regards,
>> Andrej Golovnin
>



From alexandr.scherbatiy at oracle.com  Fri Mar 18 18:29:18 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 18 Mar 2016 22:29:18 +0400
Subject: <Swing Dev> [9] Review request for 8152159 LabelUI is not
 updated for TitledBorder
In-Reply-To: <56EC216D.9030104@oracle.com>
References: <56EBC351.3090206@oracle.com> <56EC216D.9030104@oracle.com>
Message-ID: <56EC48FE.8010008@oracle.com>

On 18/03/16 19:40, Semyon Sadetsky wrote:
> Hi Alexander,
>
> Maybe it would be more optimal to update UI in a property change 
> listener added to the UIManager?
>
>     public void propertyChange(PropertyChangeEvent e) {
>         if ("lookAndFeel" == e.getPropertyName()) {
>               label.updateUI();
>         }
>     }
>

   Thank you for the review.

   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8152159/webrev.01/

   - property change listener is used to get a notification bot L&F or 
LabelUI change
   - the test is updated to check the LabelUI change

  Thanks,
  Alexandr.
> --Semyon
>
> On 3/18/2016 11:58 AM, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8152159
>>   webrev: http://cr.openjdk.java.net/~alexsch/8152159/webrev.00
>>
>>
>>   The TitledBorder label is only used for painting and does not 
>> belong  to any component hierarchy so it is not updated by 
>> SwingUtilities.updateComponentTreeUI() method.
>>   The fix updates the  TitledBorder label UI when the label is 
>> requested.
>>
>>   Thanks,
>>   Alexandr.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160318/58013677/attachment.html>

From alexandr.scherbatiy at oracle.com  Fri Mar 18 20:22:14 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Sat, 19 Mar 2016 00:22:14 +0400
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
 minimal heigh of JTabbedPane with more tabs
In-Reply-To: <824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
Message-ID: <56EC6376.5020106@oracle.com>


I would think about something like:
-------------
     public class TabbedPaneLayout implements LayoutManager {

         protected int basePreferredTabAreaWidth(final int tabPlacement, 
final int height) {
             // TabbedPaneLayout preferredTabAreaWidth implementation
         }

         protected int truncatingPreferredTabAreaWidth(final int 
tabPlacement, final int height) {
             if (tabPlacement == SwingConstants.LEFT || tabPlacement == 
SwingConstants.RIGHT) {
                 return basePreferredTabAreaWidth(tabPlacement, height);
             }

             return basePreferredTabAreaWidth(tabPlacement, height);
         }

         protected int preferredTabAreaWidth(final int tabPlacement, 
final int height) {
             return basePreferredTabAreaWidth(tabPlacement, height);
         }

     }

     class TabbedPaneScrollLayout extends TabbedPaneLayout {
         @Override
         protected int basePreferredTabAreaWidth(int tabPlacement, int 
height) {
             // TabbedPaneScrollLayout preferredTabAreaWidth implementation
         }
     }

     protected class AquaTruncatingTabbedPaneLayout extends 
AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {

         @Override
         protected int preferredTabAreaWidth(final int tabPlacement, 
final int height) {
             return truncatingPreferredTabAreaWidth(tabPlacement, height);
         }
     }

     protected class AquaTruncatingTabbedScrollPaneLayout extends 
AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {

         @Override
         protected int preferredTabAreaWidth(final int tabPlacement, 
final int height) {
             return truncatingPreferredTabAreaWidth(tabPlacement, height);
         }
     }
-------------

I just have one more question. The TabbedPaneScrollLayout is only 
created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use 
AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return 
TabbedPaneScrollLayout.

Are there any real cases when the TabbedPaneScrollLayout is created?

When you enabled the AquaTruncatingTabbedScrollPaneLayout in the 
AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not 
look similar to Aqua L&F:
http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png

The AquaTruncatingTabbedPaneLayout already contains arrows for hidden 
tabs navigation.
May be the fix should update the AquaTruncatingTabbedPaneLayout only?

Thanks,
Alexandr.

On 18/03/16 14:21, Avik Niyogi wrote:
> Hi Alexander,
> Thank you for the inputs. I agree with you and did feel the need for 
> removing duplicate code as well. But as per an earlier review input, 
> changes to the super call lay outing is not accepted. This was the 
> only other feasible solution. Created redundant code in this process, 
> but would be maintaining with requirements with code impact to 
> superclasses.
> Please provide any insight to a probable compensate to mitigate this 
> dichotomy of code expectation. Thank you in advance.
>
> With Regards,
> Avik Niyogi
>> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com 
>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>
>>
>> It is not usually a good idea to have a duplicated code which should 
>> be updated every time in several places.
>>
>> Is it possible to move the  methods used both in 
>> AquaTruncatingTabbedPaneLayout and 
>> AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with 
>> different names and then reused?
>>
>> Thanks,
>> Alexandr.
>>
>> On 17/03/16 17:17, Avik Niyogi wrote:
>>> Hi Alexander,
>>> The issue only applies for ScrollingTabbedPane and hence this fix.
>>>
>>> With Regards,
>>> Avik Niyogi
>>>
>>>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy 
>>>> <alexandr.scherbatiy at oracle.com 
>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>
>>>>
>>>> Does the same issue affects the AquaTabbedPaneContrastUI?
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>> On 14/03/16 09:04, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> A gentle reminder, please review code changes.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi <avik.niyogi at oracle.com> 
>>>>>> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Please review code changes done as with inputs provided.
>>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ 
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>
>>>>>>
>>>>>> Also, albeit the title of issue mentioned is as above, the 
>>>>>> injection of issue occurs because 
>>>>>> *pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT);* is not 
>>>>>> honoured.
>>>>>> In the new fix as provided, references to base class layout 
>>>>>> manager is removed in current solution.
>>>>>>
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>
>>>>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin 
>>>>>>> <alexander.potochkin at oracle.com> wrote:
>>>>>>>
>>>>>>> Hello Avik
>>>>>>>
>>>>>>> Let me make it clear I don't approve the proposed fix
>>>>>>> and ask you to do additional evaluation.
>>>>>>>
>>>>>>> Every LookAndFeel is different and it doesn't make much sense
>>>>>>> to compare Metal LaF with AquaLaf.
>>>>>>>
>>>>>>> The AquaLaf mimics the native MacOS controls and therefore look 
>>>>>>> quite different from any other Lafs.
>>>>>>>
>>>>>>> The bug you are fixing has the following subject
>>>>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>>>>>
>>>>>>> Could you please fix exactly the problem with the minimal heights,
>>>>>>> without changing the UI delegate class.
>>>>>>>
>>>>>>> Thanks
>>>>>>> alexp
>>>>>>>
>>>>>>>> Gentle reminder. Please review this fix.
>>>>>>>>
>>>>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi 
>>>>>>>>> <avik.niyogi at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> The issue is with setting of TabbedPane*Scroll*Layout() for 
>>>>>>>>> the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the 
>>>>>>>>> test code
>>>>>>>>>  and *not* TabbedPaneLayout() as which is the default.
>>>>>>>>>
>>>>>>>>> The minimum size fixes itself because the *ScrollLayout* check 
>>>>>>>>> fails in *setTabLayoutPolicy*() for the pane. So the issue is 
>>>>>>>>> with the call to set layout manager.
>>>>>>>>> There are only two configurations that the *JTabbedPane* can 
>>>>>>>>> exist in of which *SCROLL_TAB_LAYOUT* is one of them.
>>>>>>>>>
>>>>>>>>> Fixing the minimum size in *AquaTabbedPaneUI* will fix it for 
>>>>>>>>> *TabbedPaneLayout*() only which is the *WRAP_TAB_LAYOUT*.
>>>>>>>>>
>>>>>>>>> Also, I have checked other implementations such as for *Metal* 
>>>>>>>>> and *Motif* and *they have similar code for doing this process*.
>>>>>>>>> Hence, with in-depth analysis, this fix has no other impact 
>>>>>>>>> apart from this fix.
>>>>>>>>>
>>>>>>>>> In case the impact caused by this change has caused some 
>>>>>>>>> definitive regressions, please mention them so they can be 
>>>>>>>>> addressed. Thank you.
>>>>>>>>>
>>>>>>>>> With Regards,
>>>>>>>>> Avik Niyogi
>>>>>>>>>
>>>>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin 
>>>>>>>>>> <alexander.potochkin at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello Avik
>>>>>>>>>>
>>>>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is 
>>>>>>>>>> specific for the AquaTabbedPaneUI.
>>>>>>>>>> I don't think setting the layout manager from the base class 
>>>>>>>>>> is the right solution here.
>>>>>>>>>>
>>>>>>>>>> If there is a problem with minimum size it should be fixed 
>>>>>>>>>> inside the AquaTabbedPaneUI
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> alexp
>>>>>>>>>>
>>>>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>>>>
>>>>>>>>>>> *Bug:*
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8137169
>>>>>>>>>>>
>>>>>>>>>>> *Webrev:*
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> *Issue:*
>>>>>>>>>>> For Aqua Look&Feel, multiple calls 
>>>>>>>>>>> to pane.getMinimumSize().height causes incremental return of 
>>>>>>>>>>> values.
>>>>>>>>>>>
>>>>>>>>>>> *Cause:*
>>>>>>>>>>> The impact was caused by a major broken code within 
>>>>>>>>>>> AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>>>>>
>>>>>>>>>>> *Fix:*
>>>>>>>>>>> Major linking calls to super class fix done within 
>>>>>>>>>>> createLayoutManager().
>>>>>>>>>>>
>>>>>>>>>>> With Regards,
>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160319/40b90e6b/attachment.html>

From alexandr.scherbatiy at oracle.com  Fri Mar 18 20:24:09 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Sat, 19 Mar 2016 00:24:09 +0400
Subject: <Swing Dev> [9] Review request for 8146301: Enter key does not
 work in a deserialized JFileChooser
In-Reply-To: <56EAC145.6050209@oracle.com>
References: <56EAC145.6050209@oracle.com>
Message-ID: <56EC63E9.1010602@oracle.com>


  The fix looks good to me.

  Thanks,
  Alexandr.

On 17/03/16 18:37, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8146301
> webrev: http://cr.openjdk.java.net/~ssadetsky/8146301/webrev.00/
>
> This is a regression of JDK-8021253 in which explicit setting the 
> default button was moved to the hierarchy listener but this listener 
> disappears after serialization/deserialization cycle because it is not 
> serializable. The solution is to make it serializable.
>
> --Semyon



From alexandr.scherbatiy at oracle.com  Fri Mar 18 20:45:42 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Sat, 19 Mar 2016 00:45:42 +0400
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with
 GTK LnF
In-Reply-To: <2DD39FDD-D8C9-47B6-BAAB-D1AEA0A22DF6@oracle.com>
References: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
	<56E17C34.5030303@oracle.com>
	<8AE0341F-6D3A-4586-B7CC-38318B986450@oracle.com>
	<2DD39FDD-D8C9-47B6-BAAB-D1AEA0A22DF6@oracle.com>
Message-ID: <56EC68F6.5000106@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 14/03/16 16:25, Avik Niyogi wrote:
> Hi All,
> Please review code changes made as per inputs provided.
>
> http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.01/>
> With Regards,
> Avik Niyogi
>> On 14-Mar-2016, at 10:53 am, Avik Niyogi <avik.niyogi at oracle.com 
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi Sergey,
>> Seems like it is a delay issue. Will submit test case with a 
>> waitForIdle() fix.
>>
>> With Regards,
>> Avik Niyogi
>>> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov 
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>
>>> Hi, Avik.
>>> A few questions.
>>> - Why webrev contains the new file?
>>> - You marked the test as a mac specific but it is iterates over a 
>>> bunch of l&fs. It seems it should not be OS specific, but should 
>>> check some specific l&fs (which support such icons): Metal, Nimbus, 
>>> Aqua, Windows(???). So gtk/motif should be skipped.
>>>
>>> On 08.03.16 8:10, Avik Niyogi wrote:
>>>> Hi All,
>>>>
>>>> Kindly review the bug fix for JDK 9.
>>>>
>>>> *Bug:*
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8151282
>>>>
>>>> *Webrev:*
>>>>
>>>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
>>>> _
>>>> _
>>>> *Issue:*
>>>> The test case failed for GTK LAF.
>>>>
>>>> *Cause:*
>>>> The test case was meant to be Mac specific and was missing a jtreg 
>>>> parameter
>>>>
>>>> *Fix:*
>>>> Minor change to test case with @requires tag added to set the fix.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160319/8d86b3e9/attachment.html>

From alexandr.scherbatiy at oracle.com  Fri Mar 18 21:16:58 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Sat, 19 Mar 2016 01:16:58 +0400
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <A53CB1FD-28A4-4B22-BDF9-2268A122C764@oracle.com>
References: <EB8A0826-B75D-4FB7-8BF0-41C1E7C40CBA@oracle.com>
	<567AA8BF.5030407@oracle.com>
	<F8D8FE05-3A26-40B4-98A2-3BF0724EE408@oracle.com>
	<56938303.8050907@oracle.com>
	<DAD2ACAB-5640-40E4-89B2-B1256EB53A5B@oracle.com>
	<569543A5.7040109@oracle.com>
	<B2381901-6398-4C69-8077-1144175E461C@oracle.com>
	<569651D3.4080604@oracle.com>
	<A14D4B21-B5D3-4A08-BDB8-0956008BF208@oracle.com>
	<56976EF0.5080204@oracle.com>
	<2A741D47-D5A4-41F6-B57B-EE98B84685F5@oracle.com>
	<5697DA64.40501@oracle.com>
	<9FC2C3E2-1118-4F40-9A31-C1B01C0FF94D@oracle.com>
	<4A7B5E21-686C-45B4-8821-4F0D2CEA2E42@oracle.com>
	<569E56DC.10908@oracle.com>
	<5FBB51B9-1C62-47D0-AAC7-35849350EA21@oracle.com>
	<52e60872-c7cb-4b04-b257-24d6b975ba22@default>
	<33152751-3DA9-40FB-9900-FA204D16DAF6@oracle.com>
	<a0f24f2d-5634-4365-95fb-bf07d440fb75@default>
	<569F68DD.3010705@oracle.com>
	<6398FB4E-663B-4DC6-97CE-19A0BB3574D4@oracle.com>
	<28266B2D-3427-4938-BC7D-9C62E1E43BC4@oracle.com>
	<A53CB1FD-28A4-4B22-BDF9-2268A122C764@oracle.com>
Message-ID: <56EC704A.7050703@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 21/01/16 07:49, Avik Niyogi wrote:
> Hi All,
> Please review my code change with inputs received: 
> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.08/>
> With Regards,
> Avik Niyogi
>
>> On 21-Jan-2016, at 8:30 am, Avik Niyogi <avik.niyogi at oracle.com 
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi Sergey,
>> The JTreg will pass, but the errors are posted to the log and not as 
>> an interrupt as it would prematurely terminate execution of entire 
>> test case for other look and feels if done so.
>>
>> With Regards,
>> Avik Niyogi
>>
>>> On 21-Jan-2016, at 8:26 am, Avik Niyogi <avik.niyogi at oracle.com 
>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>
>>> Hi Sergey,
>>> This is the *log* of the test 
>>> *JProgressBarOrientationRobotTest.java* after doing a *make 
>>> java.desktop* after commenting out my code changes in 
>>> *AquaProgressBarUI.java* :
>>>
>>> run:
>>> [Metal]: LTR orientation test passed
>>> [Metal]: RTL orientation test passed
>>> [Nimbus]: LTR orientation test passed
>>> [Nimbus]: RTL orientation test passed
>>> [CDE/Motif]: LTR orientation test passed
>>> [CDE/Motif]: RTL orientation test passed
>>> [Mac OS X]: LTR orientation test passed
>>> [Mac OS X]: [Error]: LTR orientation test failed
>>> [Mac OS X]: [Error]: LTR orientation test failed
>>> BUILD SUCCESSFUL (total time: 31 seconds)
>>>
>>> With Regards,
>>> Avik Niyogi
>>>
>>>> On 20-Jan-2016, at 4:30 pm, Alexander Scherbatiy 
>>>> <alexandr.scherbatiy at oracle.com 
>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>
>>>>
>>>>  The fix looks good to me.
>>>>
>>>>  Thanks,
>>>>  Alexandr.
>>>>
>>>> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>>>>>
>>>>> Looks good to me.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rajeev Chamyal
>>>>>
>>>>> *From:*Avik Niyogi
>>>>> *Sent:* 20 January 2016 12:23
>>>>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>>>>> *Cc:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>>>> *Subject:* Re: <Swing Dev> Review request for 8015748: 
>>>>> JProgressbar with Aqua LaF ignores 
>>>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) 
>>>>> call
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Please review the code changes made as with inputs for the webrev: 
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/> 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/>
>>>>>
>>>>> With Regards,
>>>>>
>>>>> Avik Niyogi
>>>>>
>>>>>    On 20-Jan-2016, at 10:40 am, Rajeev Chamyal
>>>>>    <rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com> 
>>>>> <mailto:rajeev.chamyal at oracle.com>> wrote:
>>>>>
>>>>>    Hello Avik,
>>>>>
>>>>>    All exception caught during test should mark the test as failed.
>>>>>    For example not able to set any LAF should also be considered as
>>>>>    test failure.
>>>>>
>>>>>    Regards,
>>>>>
>>>>>    Rajeev Chamyal
>>>>>
>>>>>    *From:*Avik Niyogi
>>>>>    *Sent:*20 January 2016 10:20
>>>>>    *To:*Rajeev Chamyal
>>>>>    *Cc:*Alexander Scherbatiy; Sergey Bylokhov
>>>>>    *Subject:*Re: <Swing Dev> Review request for 8015748: JProgressbar
>>>>>    with Aqua LaF ignores
>>>>>    JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>>    call
>>>>>
>>>>>    Hi Rajeev and Sergey,
>>>>>
>>>>>    A gentle reminder. Kindly request to complete the pending review
>>>>>    of my code changes in the webrev:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>>>>>    <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>>>>>
>>>>>    Thank you in advance.
>>>>>
>>>>>    With Regards,
>>>>>
>>>>>    Avik Niyogi
>>>>>
>>>>>        On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy
>>>>>        <alexandr.scherbatiy at oracle.com 
>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>        <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>
>>>>>
>>>>>         The fix looks good to me.
>>>>>
>>>>>         Thanks,
>>>>>         Alexandr.
>>>>>
>>>>>
>>>>>        On 19/01/16 15:27, Avik Niyogi wrote:
>>>>>
>>>>>            Hi All,
>>>>>
>>>>>            A gentle reminder. Please review my code changes as
>>>>>            mentioned in the webrev below as available in the link in
>>>>>            the mail trail.
>>>>>
>>>>>            With Regards,
>>>>>
>>>>>            Avik Niyogi
>>>>>
>>>>>                On 18-Jan-2016, at 11:34 am, Avik Niyogi
>>>>>                <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>
>>>>>                <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>
>>>>>                Hi All, Please find the changes as provided with
>>>>>                incorporation of inputs:
>>>>>
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>>>>>                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>>>>>
>>>>>                With Regards,
>>>>>
>>>>>                Avik Niyogi
>>>>>
>>>>>                    On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov
>>>>>                    <Sergey.Bylokhov at oracle.com 
>>>>> <mailto:Sergey.Bylokhov at oracle.com>
>>>>>                    <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>
>>>>>                    Probably I missed something but why we need two
>>>>>                    tests? Note that the manual test is not marked as
>>>>>                    manual, which means that it will be run during the
>>>>>                    regular run?(even if -a option is provided to
>>>>>                    jtreg). Please check your other review requests
>>>>>                    for this issue.
>>>>>
>>>>>                    moreover on my system
>>>>>                    JProgressBarOrientationManualTest.java simply
>>>>>                    passed, and JProgressBarOrientationRobotTest.java
>>>>>                    failed even after the fix. Please recheck.
>>>>>
>>>>>                    On 14/01/16 13:11, Avik Niyogi wrote:
>>>>>
>>>>>
>>>>>                        Hi All,
>>>>>                        Please find the changes as provided with
>>>>>                        incorporation of inputs:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.05/>
>>>>>                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.05/>
>>>>>
>>>>>                        With Regards,
>>>>>                        Avik Niyogi
>>>>>
>>>>>
>>>>>                            On 14-Jan-2016, at 3:18 pm, Alexander
>>>>>                            Scherbatiy
>>>>>                            <alexandr.scherbatiy at oracle.com 
>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                            <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>                            wrote:
>>>>>
>>>>>                            On 1/14/2016 8:18 AM, Avik Niyogi wrote:
>>>>>
>>>>>
>>>>>                                Hi All,
>>>>>                                Please find changes as provided with
>>>>>                                incorporation of inputs:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>
>>>>>
>>>>>                             It is better to restore the graphics
>>>>>                            transform after the progress
>>>>>                            bar is painted and before the paintString
>>>>>                            call because the a method
>>>>>                            that calls
>>>>>                            AquaProgressBarUI.paint(Graphics) can rely
>>>>>                            that the
>>>>>                            graphics transform is unchanged.
>>>>>                            In your fix the graphics transform is not
>>>>>                            restored if
>>>>>                            progressBar.isStringPainted() returns 
>>>>> false.
>>>>>
>>>>>                            Thanks,
>>>>>                            Alexandr.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                                With Regards,
>>>>>                                Avik Niyogi
>>>>>
>>>>>
>>>>>                                    On 13-Jan-2016, at 7:02 pm,
>>>>>                                    Alexander Scherbatiy
>>>>>                                    <alexandr.scherbatiy at oracle.com 
>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                    <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                    <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                    <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>                                    wrote:
>>>>>
>>>>>                                    On 1/13/2016 9:28 AM, Avik Niyogi
>>>>>                                    wrote:
>>>>>
>>>>>
>>>>>                                        Hi All,
>>>>>                                        Please find changes as
>>>>>                                        provided with incorporation of
>>>>>                                        inputs:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.03/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>                                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>                                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>                                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>
>>>>>
>>>>>                                    It looks like a string on a
>>>>>                                    vertical progress bar with the
>>>>>                                    right to
>>>>>                                    left orientation will be mirrored.
>>>>>                                    Did you try just restore the
>>>>>                                    scale/translate transform after the
>>>>>                                    painter.paint() call? Will it help
>>>>>                                    in such case?
>>>>>
>>>>>                                    Thanks,
>>>>>                                    Alexandr.
>>>>>
>>>>>
>>>>>
>>>>>                                        With Regards,
>>>>>                                        Avik Niyogi
>>>>>
>>>>>
>>>>>                                            On 12-Jan-2016, at 11:49
>>>>>                                            pm, Alexander Scherbatiy
>>>>>                                            <alexandr.scherbatiy at oracle.com 
>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                            <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>                                            wrote:
>>>>>
>>>>>
>>>>>                                            - there was the comment
>>>>>                                            below that it is better to
>>>>>                                            revert the
>>>>>                                            transform back after the
>>>>>                                            painter.paint() call
>>>>>                                            - according to the comment
>>>>>                                            from the
>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-January/005262.html
>>>>>
>>>>>                                            It is true that a filled
>>>>>                                            progress bar has different
>>>>>                                            colors because
>>>>>                                            of animation under Aqua 
>>>>> L&F.
>>>>>                                            However, it is possible to
>>>>>                                            compare colors before a
>>>>>                                            progress bar
>>>>>                                            was filled and after that
>>>>>                                            to check that the progress
>>>>>                                            bar is filled
>>>>>                                            from the correct side.
>>>>>                                            For example let's set a
>>>>>                                            progress bar value to 0
>>>>>                                            and get its color
>>>>>                                            from 5/6 of the progress
>>>>>                                            bar width
>>>>>                                              progress bar:
>>>>>                                            [_________o__]  // get a
>>>>>                                            color at point o
>>>>>                                            Now set the progress bar
>>>>>                                            value to 30 and get a
>>>>>                                            color at the same
>>>>>                                            point.
>>>>>                                            If colors are the same
>>>>>                                            then  the progress bar is
>>>>>                                            filled from left
>>>>>                                            to the right 
>>>>> [||||_____o__].
>>>>>                                            If colors are different
>>>>>                                            then the progress bar is
>>>>>                                            filled from the
>>>>>                                            right to the left
>>>>>                                            [________|o||] .
>>>>>
>>>>>                                            Thanks,
>>>>>                                            Alexandr.
>>>>>
>>>>>
>>>>>                                            On 12/01/16 13:34, Avik
>>>>>                                            Niyogi wrote:
>>>>>
>>>>>
>>>>>                                                Hi All,
>>>>>
>>>>>                                                Please find the code
>>>>>                                                changes in fix as with
>>>>>                                                the inputs received
>>>>>                                                for the same.
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.02/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>
>>>>>                                                With Regards,
>>>>>                                                Avik Niyogi
>>>>>
>>>>>
>>>>>
>>>>>                                                    On 11-Jan-2016, at
>>>>>                                                    3:55 pm, Semyon
>>>>>                                                    Sadetsky
>>>>>                                                    <semyon.sadetsky at oracle.com 
>>>>> <mailto:semyon.sadetsky at oracle.com>
>>>>>                                                    <mailto:semyon.sadetsky at oracle.com><mailto:semyon.sadetsky at oracle.com>
>>>>>                                                    <mailto:semyon.sadetsky at oracle.com>
>>>>>                                                    <mailto:semyon.sadetsky at oracle.com>>
>>>>>                                                    wrote:
>>>>>
>>>>>                                                    Hi Avik,
>>>>>
>>>>>                                                    Shouldn't the
>>>>>                                                    graphics
>>>>>                                                    transformation be
>>>>>                                                    restored before the
>>>>>                                                    paintString() call?
>>>>>
>>>>>                                                    It seems to me
>>>>>                                                    that left/right
>>>>>                                                    insets need to be
>>>>>                                                    swapped for
>>>>>                                                    right-to-left
>>>>>                                                    painting with
>>>>>                                                    mirroring graphics
>>>>>                                                    transformation.
>>>>>
>>>>>                                                    --Semyon
>>>>>
>>>>>                                                    On 1/5/2016 1:22
>>>>>                                                    PM, Avik Niyogi 
>>>>> wrote:
>>>>>
>>>>>
>>>>>                                                        Hi All,
>>>>>                                                        Please find
>>>>>                                                        webrev with
>>>>>                                                        inputs as
>>>>>                                                        provided:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.01/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>                                                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>                                                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>                                                        With Regards,
>>>>>                                                        Avik Niyogi
>>>>>
>>>>>
>>>>>
>>>>>                                                            On
>>>>>                                                            23-Dec-2015,
>>>>>                                                            at 7:29
>>>>>                                                            pm,
>>>>>                                                            Alexander
>>>>>                                                            Scherbatiy
>>>>>                                                            <alexandr.scherbatiy at oracle.com 
>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                                            <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>                                                            wrote:
>>>>>
>>>>>
>>>>>                                                            - please
>>>>>                                                            check that
>>>>>                                                            the
>>>>>                                                            progress
>>>>>                                                            bar string
>>>>>                                                            (progressBar.setString()/setStringPainted())
>>>>>                                                            is painted
>>>>>                                                            correctly.
>>>>>                                                            - is it
>>>>>                                                            possible
>>>>>                                                            to write
>>>>>                                                            an
>>>>>                                                            automated
>>>>>                                                            test for
>>>>>                                                            the fix?
>>>>>
>>>>>                                                            Thanks,
>>>>>                                                            Alexandr.
>>>>>
>>>>>                                                            On
>>>>>                                                            12/21/2015
>>>>>                                                            11:47 AM,
>>>>>                                                            Avik
>>>>>                                                            Niyogi 
>>>>> wrote:
>>>>>
>>>>>
>>>>>                                                                Hi All,
>>>>>
>>>>>                                                                Kindly
>>>>>                                                                review
>>>>>                                                                the
>>>>>                                                                bug
>>>>>                                                                fix
>>>>>                                                                for 
>>>>> JDK 9.
>>>>>
>>>>>                                                                *Bug:*
>>>>> https://bugs.openjdk.java.net/browse/JDK-8015748
>>>>>
>>>>>                                                                *Webrev:*
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>                                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>                                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>                                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>
>>>>>                                                                *Issue:*
>>>>>                                                                The
>>>>>                                                                manual
>>>>>                                                                test:
>>>>>                                                                Swing_JProgressbar/Manual/ProgressBarLAFTests/ProgressBarLAFTest1
>>>>>                                                                in
>>>>>                                                                testsuite
>>>>> http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/7/swing
>>>>>                                                                fails
>>>>>
>>>>>                                                                *Cause:*
>>>>>                                                                Due to
>>>>>                                                                not
>>>>>                                                                honouring
>>>>>                                                                of
>>>>>                                                                RIGHT_TO_LEFT
>>>>>                                                                parameter
>>>>>                                                                for
>>>>>                                                                setOrientation
>>>>>                                                                method
>>>>>                                                                applied 
>>>>> for
>>>>>                                                                a
>>>>>                                                                JProgressBar
>>>>>                                                                for the
>>>>>                                                                AquaLookAndFeel
>>>>>                                                                only,
>>>>>                                                                the
>>>>>                                                                progressBar
>>>>>                                                                does
>>>>>                                                                not
>>>>>                                                                have
>>>>>                                                                the
>>>>>                                                                ability 
>>>>> to
>>>>>                                                                grow
>>>>>                                                                from right
>>>>>                                                                to
>>>>>                                                                left.
>>>>>                                                                This
>>>>>                                                                issue
>>>>>                                                                was
>>>>>                                                                verified
>>>>>                                                                to
>>>>>                                                                exist
>>>>>                                                                only in
>>>>>                                                                AquaLookAndFeel
>>>>>                                                                for
>>>>>                                                                JProgressBar.
>>>>>
>>>>>                                                                *Fix:*
>>>>>                                                                Added
>>>>>                                                                implementation
>>>>>                                                                for
>>>>>                                                                the
>>>>>                                                                check
>>>>>                                                                of
>>>>>                                                                RIGHT_TO_LEFT
>>>>>                                                                ComponentOrientation
>>>>>                                                                and
>>>>>                                                                verified
>>>>>                                                                with
>>>>>                                                                other
>>>>>                                                                combination
>>>>>                                                                orientation
>>>>>                                                                with
>>>>>                                                                available
>>>>>                                                                Horizontal
>>>>>                                                                and
>>>>>                                                                Vertical
>>>>>                                                                orientations
>>>>>                                                                as
>>>>>                                                                provided
>>>>>                                                                from
>>>>>                                                                before.
>>>>>
>>>>>                                                                With
>>>>>                                                                Regards,
>>>>>                                                                Avik
>>>>>                                                                Niyogi
>>>>>
>>>>>
>>>>>
>>>>>                    --
>>>>>                    Best regards, Sergey.
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160319/df65ef32/attachment.html>

From Sergey.Bylokhov at oracle.com  Sat Mar 19 11:22:38 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 19 Mar 2016 14:22:38 +0300
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <A53CB1FD-28A4-4B22-BDF9-2268A122C764@oracle.com>
References: <EB8A0826-B75D-4FB7-8BF0-41C1E7C40CBA@oracle.com>
	<567AA8BF.5030407@oracle.com>
	<F8D8FE05-3A26-40B4-98A2-3BF0724EE408@oracle.com>
	<56938303.8050907@oracle.com>
	<DAD2ACAB-5640-40E4-89B2-B1256EB53A5B@oracle.com>
	<569543A5.7040109@oracle.com>
	<B2381901-6398-4C69-8077-1144175E461C@oracle.com>
	<569651D3.4080604@oracle.com>
	<A14D4B21-B5D3-4A08-BDB8-0956008BF208@oracle.com>
	<56976EF0.5080204@oracle.com>
	<2A741D47-D5A4-41F6-B57B-EE98B84685F5@oracle.com>
	<5697DA64.40501@oracle.com>
	<9FC2C3E2-1118-4F40-9A31-C1B01C0FF94D@oracle.com>
	<4A7B5E21-686C-45B4-8821-4F0D2CEA2E42@oracle.com>
	<569E56DC.10908@oracle.com>
	<5FBB51B9-1C62-47D0-AAC7-35849350EA21@oracle.com>
	<52e60872-c7cb-4b04-b257-24d6b975ba22@default>
	<33152751-3DA9-40FB-9900-FA204D16DAF6@oracle.com>
	<a0f24f2d-5634-4365-95fb-bf07d440fb75@default>
	<569F68DD.3010705@oracle.com>
	<6398FB4E-663B-4DC6-97CE-19A0BB3574D4@oracle.com>
	<28266B2D-3427-4938-BC7D-9C62E1E43BC4@oracle.com>
	<A53CB1FD-28A4-4B22-BDF9-2268A122C764@oracle.com>
Message-ID: <56ED367E.3050903@oracle.com>

I guess you need a separate CR for this, because JDK-8015748 was closed 
already.

On 21.01.16 6:49, Avik Niyogi wrote:
> Hi All,
> Please review my code change with inputs received:
> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/
> With Regards,
> Avik Niyogi
>
>> On 21-Jan-2016, at 8:30 am, Avik Niyogi <avik.niyogi at oracle.com
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi Sergey,
>> The JTreg will pass, but the errors are posted to the log and not as
>> an interrupt as it would prematurely terminate execution of entire
>> test case for other look and feels if done so.
>>
>> With Regards,
>> Avik Niyogi
>>
>>> On 21-Jan-2016, at 8:26 am, Avik Niyogi <avik.niyogi at oracle.com
>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>
>>> Hi Sergey,
>>> This is the *log* of the test *JProgressBarOrientationRobotTest.java*
>>> after doing a *make java.desktop* after commenting out my code
>>> changes in *AquaProgressBarUI.java* :
>>>
>>> run:
>>> [Metal]: LTR orientation test passed
>>> [Metal]: RTL orientation test passed
>>> [Nimbus]: LTR orientation test passed
>>> [Nimbus]: RTL orientation test passed
>>> [CDE/Motif]: LTR orientation test passed
>>> [CDE/Motif]: RTL orientation test passed
>>> [Mac OS X]: LTR orientation test passed
>>> [Mac OS X]: [Error]: LTR orientation test failed
>>> [Mac OS X]: [Error]: LTR orientation test failed
>>> BUILD SUCCESSFUL (total time: 31 seconds)
>>>
>>> With Regards,
>>> Avik Niyogi
>>>
>>>> On 20-Jan-2016, at 4:30 pm, Alexander Scherbatiy
>>>> <alexandr.scherbatiy at oracle.com
>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>
>>>>
>>>>  The fix looks good to me.
>>>>
>>>>  Thanks,
>>>>  Alexandr.
>>>>
>>>> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>>>>>
>>>>> Looks good to me.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rajeev Chamyal
>>>>>
>>>>> *From:*Avik Niyogi
>>>>> *Sent:* 20 January 2016 12:23
>>>>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>>>>> *Cc:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>>>> *Subject:* Re: <Swing Dev> Review request for 8015748: JProgressbar
>>>>> with Aqua LaF ignores
>>>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>> call
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Please review the code changes made as with inputs for the webrev:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/>
>>>>>
>>>>> With Regards,
>>>>>
>>>>> Avik Niyogi
>>>>>
>>>>>    On 20-Jan-2016, at 10:40 am, Rajeev Chamyal
>>>>>    <rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com>
>>>>> <mailto:rajeev.chamyal at oracle.com>> wrote:
>>>>>
>>>>>    Hello Avik,
>>>>>
>>>>>    All exception caught during test should mark the test as failed.
>>>>>    For example not able to set any LAF should also be considered as
>>>>>    test failure.
>>>>>
>>>>>    Regards,
>>>>>
>>>>>    Rajeev Chamyal
>>>>>
>>>>>    *From:*Avik Niyogi
>>>>>    *Sent:*20 January 2016 10:20
>>>>>    *To:*Rajeev Chamyal
>>>>>    *Cc:*Alexander Scherbatiy; Sergey Bylokhov
>>>>>    *Subject:*Re: <Swing Dev> Review request for 8015748: JProgressbar
>>>>>    with Aqua LaF ignores
>>>>>    JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>>    call
>>>>>
>>>>>    Hi Rajeev and Sergey,
>>>>>
>>>>>    A gentle reminder. Kindly request to complete the pending review
>>>>>    of my code changes in the webrev:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/
>>>>>    <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>>>>>
>>>>>    Thank you in advance.
>>>>>
>>>>>    With Regards,
>>>>>
>>>>>    Avik Niyogi
>>>>>
>>>>>        On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy
>>>>>        <alexandr.scherbatiy at oracle.com
>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>        <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>
>>>>>
>>>>>         The fix looks good to me.
>>>>>
>>>>>         Thanks,
>>>>>         Alexandr.
>>>>>
>>>>>
>>>>>        On 19/01/16 15:27, Avik Niyogi wrote:
>>>>>
>>>>>            Hi All,
>>>>>
>>>>>            A gentle reminder. Please review my code changes as
>>>>>            mentioned in the webrev below as available in the link in
>>>>>            the mail trail.
>>>>>
>>>>>            With Regards,
>>>>>
>>>>>            Avik Niyogi
>>>>>
>>>>>                On 18-Jan-2016, at 11:34 am, Avik Niyogi
>>>>>                <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>
>>>>>                <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>
>>>>>                Hi All, Please find the changes as provided with
>>>>>                incorporation of inputs:
>>>>>
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/
>>>>>                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>>>>>
>>>>>                With Regards,
>>>>>
>>>>>                Avik Niyogi
>>>>>
>>>>>                    On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov
>>>>>                    <Sergey.Bylokhov at oracle.com
>>>>> <mailto:Sergey.Bylokhov at oracle.com>
>>>>>                    <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>
>>>>>                    Probably I missed something but why we need two
>>>>>                    tests? Note that the manual test is not marked as
>>>>>                    manual, which means that it will be run during the
>>>>>                    regular run?(even if -a option is provided to
>>>>>                    jtreg). Please check your other review requests
>>>>>                    for this issue.
>>>>>
>>>>>                    moreover on my system
>>>>>                    JProgressBarOrientationManualTest.java simply
>>>>>                    passed, and JProgressBarOrientationRobotTest.java
>>>>>                    failed even after the fix. Please recheck.
>>>>>
>>>>>                    On 14/01/16 13:11, Avik Niyogi wrote:
>>>>>
>>>>>
>>>>>                        Hi All,
>>>>>                        Please find the changes as provided with
>>>>>                        incorporation of inputs:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/
>>>>>                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.05/>
>>>>>
>>>>>                        With Regards,
>>>>>                        Avik Niyogi
>>>>>
>>>>>
>>>>>                            On 14-Jan-2016, at 3:18 pm, Alexander
>>>>>                            Scherbatiy
>>>>>                            <alexandr.scherbatiy at oracle.com
>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                            <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>                            wrote:
>>>>>
>>>>>                            On 1/14/2016 8:18 AM, Avik Niyogi wrote:
>>>>>
>>>>>
>>>>>                                Hi All,
>>>>>                                Please find changes as provided with
>>>>>                                incorporation of inputs:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/
>>>>>                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>
>>>>>
>>>>>                             It is better to restore the graphics
>>>>>                            transform after the progress
>>>>>                            bar is painted and before the paintString
>>>>>                            call because the a method
>>>>>                            that calls
>>>>>                            AquaProgressBarUI.paint(Graphics) can rely
>>>>>                            that the
>>>>>                            graphics transform is unchanged.
>>>>>                            In your fix the graphics transform is not
>>>>>                            restored if
>>>>>                            progressBar.isStringPainted() returns false.
>>>>>
>>>>>                            Thanks,
>>>>>                            Alexandr.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                                With Regards,
>>>>>                                Avik Niyogi
>>>>>
>>>>>
>>>>>                                    On 13-Jan-2016, at 7:02 pm,
>>>>>                                    Alexander Scherbatiy
>>>>>                                    <alexandr.scherbatiy at oracle.com
>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                    <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                    <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                    <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>                                    wrote:
>>>>>
>>>>>                                    On 1/13/2016 9:28 AM, Avik Niyogi
>>>>>                                    wrote:
>>>>>
>>>>>
>>>>>                                        Hi All,
>>>>>                                        Please find changes as
>>>>>                                        provided with incorporation of
>>>>>                                        inputs:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.03/
>>>>>                                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>                                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>                                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>
>>>>>
>>>>>                                    It looks like a string on a
>>>>>                                    vertical progress bar with the
>>>>>                                    right to
>>>>>                                    left orientation will be mirrored.
>>>>>                                    Did you try just restore the
>>>>>                                    scale/translate transform after the
>>>>>                                    painter.paint() call? Will it help
>>>>>                                    in such case?
>>>>>
>>>>>                                    Thanks,
>>>>>                                    Alexandr.
>>>>>
>>>>>
>>>>>
>>>>>                                        With Regards,
>>>>>                                        Avik Niyogi
>>>>>
>>>>>
>>>>>                                            On 12-Jan-2016, at 11:49
>>>>>                                            pm, Alexander Scherbatiy
>>>>>                                            <alexandr.scherbatiy at oracle.com
>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                            <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>                                            wrote:
>>>>>
>>>>>
>>>>>                                            - there was the comment
>>>>>                                            below that it is better to
>>>>>                                            revert the
>>>>>                                            transform back after the
>>>>>                                            painter.paint() call
>>>>>                                            - according to the comment
>>>>>                                            from the
>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-January/005262.html
>>>>>
>>>>>                                            It is true that a filled
>>>>>                                            progress bar has different
>>>>>                                            colors because
>>>>>                                            of animation under Aqua L&F.
>>>>>                                            However, it is possible to
>>>>>                                            compare colors before a
>>>>>                                            progress bar
>>>>>                                            was filled and after that
>>>>>                                            to check that the progress
>>>>>                                            bar is filled
>>>>>                                            from the correct side.
>>>>>                                            For example let's set a
>>>>>                                            progress bar value to 0
>>>>>                                            and get its color
>>>>>                                            from 5/6 of the progress
>>>>>                                            bar width
>>>>>                                              progress bar:
>>>>>                                            [_________o__]  // get a
>>>>>                                            color at point o
>>>>>                                            Now set the progress bar
>>>>>                                            value to 30 and get a
>>>>>                                            color at the same
>>>>>                                            point.
>>>>>                                            If colors are the same
>>>>>                                            then  the progress bar is
>>>>>                                            filled from left
>>>>>                                            to the right [||||_____o__].
>>>>>                                            If colors are different
>>>>>                                            then the progress bar is
>>>>>                                            filled from the
>>>>>                                            right to the left
>>>>>                                            [________|o||] .
>>>>>
>>>>>                                            Thanks,
>>>>>                                            Alexandr.
>>>>>
>>>>>
>>>>>                                            On 12/01/16 13:34, Avik
>>>>>                                            Niyogi wrote:
>>>>>
>>>>>
>>>>>                                                Hi All,
>>>>>
>>>>>                                                Please find the code
>>>>>                                                changes in fix as with
>>>>>                                                the inputs received
>>>>>                                                for the same.
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.02/
>>>>>                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>
>>>>>                                                With Regards,
>>>>>                                                Avik Niyogi
>>>>>
>>>>>
>>>>>
>>>>>                                                    On 11-Jan-2016, at
>>>>>                                                    3:55 pm, Semyon
>>>>>                                                    Sadetsky
>>>>>                                                    <semyon.sadetsky at oracle.com
>>>>> <mailto:semyon.sadetsky at oracle.com>
>>>>>                                                    <mailto:semyon.sadetsky at oracle.com><mailto:semyon.sadetsky at oracle.com>
>>>>>                                                    <mailto:semyon.sadetsky at oracle.com>
>>>>>                                                    <mailto:semyon.sadetsky at oracle.com>>
>>>>>                                                    wrote:
>>>>>
>>>>>                                                    Hi Avik,
>>>>>
>>>>>                                                    Shouldn't the
>>>>>                                                    graphics
>>>>>                                                    transformation be
>>>>>                                                    restored before the
>>>>>                                                    paintString() call?
>>>>>
>>>>>                                                    It seems to me
>>>>>                                                    that left/right
>>>>>                                                    insets need to be
>>>>>                                                    swapped for
>>>>>                                                    right-to-left
>>>>>                                                    painting with
>>>>>                                                    mirroring graphics
>>>>>                                                    transformation.
>>>>>
>>>>>                                                    --Semyon
>>>>>
>>>>>                                                    On 1/5/2016 1:22
>>>>>                                                    PM, Avik Niyogi
>>>>> wrote:
>>>>>
>>>>>
>>>>>                                                        Hi All,
>>>>>                                                        Please find
>>>>>                                                        webrev with
>>>>>                                                        inputs as
>>>>>                                                        provided:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.01/
>>>>>                                                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>                                                        <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>                                                        With Regards,
>>>>>                                                        Avik Niyogi
>>>>>
>>>>>
>>>>>
>>>>>                                                            On
>>>>>                                                            23-Dec-2015,
>>>>>                                                            at 7:29
>>>>>                                                            pm,
>>>>>                                                            Alexander
>>>>>                                                            Scherbatiy
>>>>>                                                            <alexandr.scherbatiy at oracle.com
>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                                            <mailto:alexandr.scherbatiy at oracle.com>
>>>>>                                                            <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>                                                            wrote:
>>>>>
>>>>>
>>>>>                                                            - please
>>>>>                                                            check that
>>>>>                                                            the
>>>>>                                                            progress
>>>>>                                                            bar string
>>>>>                                                            (progressBar.setString()/setStringPainted())
>>>>>                                                            is painted
>>>>>                                                            correctly.
>>>>>                                                            - is it
>>>>>                                                            possible
>>>>>                                                            to write
>>>>>                                                            an
>>>>>                                                            automated
>>>>>                                                            test for
>>>>>                                                            the fix?
>>>>>
>>>>>                                                            Thanks,
>>>>>                                                            Alexandr.
>>>>>
>>>>>                                                            On
>>>>>                                                            12/21/2015
>>>>>                                                            11:47 AM,
>>>>>                                                            Avik
>>>>>                                                            Niyogi
>>>>> wrote:
>>>>>
>>>>>
>>>>>                                                                Hi All,
>>>>>
>>>>>                                                                Kindly
>>>>>                                                                review
>>>>>                                                                the
>>>>>                                                                bug
>>>>>                                                                fix
>>>>>                                                                for
>>>>> JDK 9.
>>>>>
>>>>>                                                                *Bug:*
>>>>> https://bugs.openjdk.java.net/browse/JDK-8015748
>>>>>
>>>>>                                                                *Webrev:*
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.00/
>>>>>                                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>                                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>                                                                <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>
>>>>>                                                                *Issue:*
>>>>>                                                                The
>>>>>                                                                manual
>>>>>                                                                test:
>>>>>                                                                Swing_JProgressbar/Manual/ProgressBarLAFTests/ProgressBarLAFTest1
>>>>>                                                                in
>>>>>                                                                testsuite
>>>>> http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/7/swing
>>>>>                                                                fails
>>>>>
>>>>>                                                                *Cause:*
>>>>>                                                                Due to
>>>>>                                                                not
>>>>>                                                                honouring
>>>>>                                                                of
>>>>>                                                                RIGHT_TO_LEFT
>>>>>                                                                parameter
>>>>>                                                                for
>>>>>                                                                setOrientation
>>>>>                                                                method
>>>>>                                                                applied
>>>>> for
>>>>>                                                                a
>>>>>                                                                JProgressBar
>>>>>                                                                for the
>>>>>                                                                AquaLookAndFeel
>>>>>                                                                only,
>>>>>                                                                the
>>>>>                                                                progressBar
>>>>>                                                                does
>>>>>                                                                not
>>>>>                                                                have
>>>>>                                                                the
>>>>>                                                                ability
>>>>> to
>>>>>                                                                grow
>>>>>                                                                from
>>>>> right
>>>>>                                                                to
>>>>>                                                                left.
>>>>>                                                                This
>>>>>                                                                issue
>>>>>                                                                was
>>>>>                                                                verified
>>>>>                                                                to
>>>>>                                                                exist
>>>>>                                                                only in
>>>>>                                                                AquaLookAndFeel
>>>>>                                                                for
>>>>>                                                                JProgressBar.
>>>>>
>>>>>                                                                *Fix:*
>>>>>                                                                Added
>>>>>                                                                implementation
>>>>>                                                                for
>>>>>                                                                the
>>>>>                                                                check
>>>>>                                                                of
>>>>>                                                                RIGHT_TO_LEFT
>>>>>                                                                ComponentOrientation
>>>>>                                                                and
>>>>>                                                                verified
>>>>>                                                                with
>>>>>                                                                other
>>>>>                                                                combination
>>>>>                                                                orientation
>>>>>                                                                with
>>>>>                                                                available
>>>>>                                                                Horizontal
>>>>>                                                                and
>>>>>                                                                Vertical
>>>>>                                                                orientations
>>>>>                                                                as
>>>>>                                                                provided
>>>>>                                                                from
>>>>>                                                                before.
>>>>>
>>>>>                                                                With
>>>>>                                                                Regards,
>>>>>                                                                Avik
>>>>>                                                                Niyogi
>>>>>
>>>>>
>>>>>
>>>>>                    --
>>>>>                    Best regards, Sergey.
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Sat Mar 19 15:49:27 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 19 Mar 2016 18:49:27 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56EBF688.1090006@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com>
Message-ID: <56ED7507.1090204@oracle.com>

On 18.03.16 15:37, Semyon Sadetsky wrote:
> On 3/17/2016 2:46 PM, Sergey Bylokhov wrote:
>> Small notes:
>>  - It will be good to move the code which reads the system properties
>> to the static init block, otherwise we can be in trouble if these
>> properties will be changed at runtime.
> I don't' see any troubles with this. Can you describe the scenario you
> meant?
> I think the properties changing at run-time is useful because it gives
> better control over GTK load. For example, developer may change the
> order to GTK3->GTK2.

Yes the users can change the property at the beginning of the program or 
via command line, but it is not good thing to allow to change it after 
unix toolkit is loaded. For example isNativeGTKAvailable() can check one 
version of the library, and loadGTK() can try to load another version, 
because getEnabledGtkVersion() will return different values. It belongs 
to all places where getEnabledGtkVersion() is used.

>>  - Is it necessary to use ordinal? can we replace it with some
>> specific data?(the same for the indexed access in .values()[..])
> In general I'm good. But what specific data you propose?

And javadoc for ordinal:
"Most programmers will have no use for this method. It is designed for 
use by sophisticated enum-based data structures, such as EnumSet and 
EnumMap."

Quote from the internet:
"This is not recommended to use ordinal() (Effective Java, Item 31) as 
it relies on the order of the enum values in client's code determine the 
ordinal, and any change could lead to bad values being mapped.

Instead, it would be better to have users implement a method that would 
return a unique ID for an enum value. For instance, with an Identifiable 
interface that has a unique method id(), that the user would have to 
implement for every enum value."

>
> --Semyon
>>
>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>> Hi Phil,
>>>
>>> Thank for review. You will find my reply below in the text.
>>>
>>> The updated webrev is
>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>> It also contains:
>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more but we
>>> can do this later as a separate bug.
>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>>> appearance changes.
>>>
>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>> There is a lot to read here. I think I need to patch and try it but
>>>> first ...
>>>>
>>>> Two high level questions :
>>>> 1) Have you verified that this behaves properly (or no worse than
>>>> currently) with -Djava.awt.headless=true since Swing components
>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>> yet a dependency on GTK and its dependency on xlibraries seems to mean
>>>> that you can't load GTK in this case.
>>>> BTW I think it may be painful to get them to layout in such a case
>>>> but that's another issue.
>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>
>>>> 2) Have you tried a hi-dpi system ?
>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>
>>>> 3) Have you submitted a JPRT job ? It is essential to know that this
>>>> builds cleanly on the "official" compilation environment.
>>> I will do this before the push. I think it will be OK because I did not
>>> use any new C constructs and the new libraries are linked dynamically.
>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>> regression test suite ?
>>> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
>>> With GTK3 the result was the same except for some unstable tests. Unity
>>> desktop has new window decorations like borderless windows which are
>>> resized by dragging the outer window shadow, invisible overlay
>>> scrollbars, etc. Many tests written for old window decorations fails.
>>>>
>>>> Minor comments :
>>>>
>>>> GTKEngine.java
>>>>
>>>>  494         Container parent = context.getComponent().getParent();
>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>  496             if (parent != null && parent.getParent() instanceof
>>>> JComboBox) {
>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>  499                 }
>>>>  500             }
>>>>  501         }
>>>>
>>>> GTKPainter.java
>>>>
>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>>  748                 y += 1;
>>>>  749                 h -= 2;
>>>>  750             } else {
>>>>  751                 x += 1;
>>>>  752                 w -= 2;
>>>>  753             }
>>>>  754         }
>>>>
>>>> I don't know where these numbers come from or what coordinate system
>>>> is being used here but it seems you are changing them for gtk 2.2 as
>>>> well as 3
>>>> Can you speak to this ?
>>> It is an appearance tuning for GTK3. I didn't change it for GTK2, why do
>>> you think so?
>>> This was used before my fix as well, for example
>>>
>>>                      if (containerParent instanceof JComboBox) {
>>>                          x += (focusSize + 2);
>>>                          y += (focusSize + 1);
>>>                          w -= (2 * focusSize + 1);
>>>                          h -= (2 * focusSize + 2);
>>>                      } else {
>>>                          x += focusSize;
>>>                          y += focusSize;
>>>                          w -= 2 * focusSize;
>>>                          h -= 2 * focusSize;
>>>                      }
>>>
>>> The only place where I changed the existing GTK2 appearance is:
>>>
>>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth",
>>> "slider-length");
>>>
>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>
>>>> GTKStyle.java
>>>>
>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>
>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>
>>>>
>>>> we prefer a space between "if" and "("
>>> Accepted.
>>>>
>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>
>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>
>>>>
>>>> Maybe I am not looking at the right fn but I thought I saw
>>>> this fn return a boolean so a check against NULL looks wrong.
>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>> char*. NULL means that the version is compatible.
>>>>
>>>>  393
>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>>>  394                 dialog), TRUE);
>>>>
>>>>
>>>> You didn't add this but it is awfully specific about the GTK version
>>>> and
>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>> Accepted.
>>>>
>>>> It is interesting that some equivalent looking Java level dialog
>>>> checking in XToolkit.java
>>>> checked for 3.0 too ..
>>>>
>>>> swing_GTKEngine.c :
>>>>
>>>>   30 /* Static buffer for conversion from java.lang.String to UTF-8 */
>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>
>>>> So the variable name should be spelt conversionBuffer.
>>> Accepted.
>>>>
>>>> awt_UNIXToolkit.c
>>>>
>>>> < 287 free(ret);
>>>>
>>>> You deleted this free(). Is that correct ? It seems to imply
>>>> you now expect a boolean return as discussed above and
>>>> so in that case NULL looks odd here (line 260) too.
>>> The JNI exported method returns boolean while the GTK method returns
>>> char*. free() is deleted intentionally according to the GTK docs it
>>> belongs to the library and should not be freed by user code.
>>>>
>>>> gtk3_interface.h :
>>>>
>>>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>>>
>>>> I don't think that is completely accurate :-) And I should have
>>>> reviewed this yesterday [1].
>>> :) This is glib's definition I just copied.
>>>
>>> --Semyon
>>>>
>>>> -phil.
>>>>
>>>> [1] http://www.piday.org/
>>>>
>>>>
>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>
>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>> Also the new system property is added to request specific GTK version
>>>>> swing.gtk.version.
>>>>>
>>>>> --Semyon
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From avik.niyogi at oracle.com  Mon Mar 21 05:12:17 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 21 Mar 2016 10:42:17 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <56ED367E.3050903@oracle.com>
References: <EB8A0826-B75D-4FB7-8BF0-41C1E7C40CBA@oracle.com>
	<567AA8BF.5030407@oracle.com>
	<F8D8FE05-3A26-40B4-98A2-3BF0724EE408@oracle.com>
	<56938303.8050907@oracle.com>
	<DAD2ACAB-5640-40E4-89B2-B1256EB53A5B@oracle.com>
	<569543A5.7040109@oracle.com>
	<B2381901-6398-4C69-8077-1144175E461C@oracle.com>
	<569651D3.4080604@oracle.com>
	<A14D4B21-B5D3-4A08-BDB8-0956008BF208@oracle.com>
	<56976EF0.5080204@oracle.com>
	<2A741D47-D5A4-41F6-B57B-EE98B84685F5@oracle.com>
	<5697DA64.40501@oracle.com>
	<9FC2C3E2-1118-4F40-9A31-C1B01C0FF94D@oracle.com>
	<4A7B5E21-686C-45B4-8821-4F0D2CEA2E42@oracle.com>
	<569E56DC.10908@oracle.com>
	<5FBB51B9-1C62-47D0-AAC7-35849350EA21@oracle.com>
	<52e60872-c7cb-4b04-b257-24d6b975ba22@default>
	<33152751-3DA9-40FB-9900-FA204D16DAF6@oracle.com>
	<a0f24f2d-5634-4365-95fb-bf07d440fb75@default>
	<569F68DD.3010705@oracle.com>
	<6398FB4E-663B-4DC6-97CE-19A0BB3574D4@oracle.com>
	<28266B2D-3427-4938-BC7D-9C62E1E43BC4@oracle.com>
	<A53CB1FD-28A4-4B22-BDF9-2268A122C764@oracle.co!
	m> <56ED367E.3050903@oracle.com>
Message-ID: <D72D2B05-D686-4BDE-961D-008BA426B0DD@oracle.com>

Hi Sergey,
https://bugs.openjdk.java.net/browse/JDK-8151282 <https://bugs.openjdk.java.net/browse/JDK-8151282> is open and in progress.
With Regards,
Avik Niyogi

> On 19-Mar-2016, at 4:52 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> I guess you need a separate CR for this, because JDK-8015748 was closed already.
> 
> On 21.01.16 6:49, Avik Niyogi wrote:
>> Hi All,
>> Please review my code change with inputs received:
>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/ <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/>
>> With Regards,
>> Avik Niyogi
>> 
>>> On 21-Jan-2016, at 8:30 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>
>>> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>> wrote:
>>> 
>>> Hi Sergey,
>>> The JTreg will pass, but the errors are posted to the log and not as
>>> an interrupt as it would prematurely terminate execution of entire
>>> test case for other look and feels if done so.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 21-Jan-2016, at 8:26 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>
>>>> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>> wrote:
>>>> 
>>>> Hi Sergey,
>>>> This is the *log* of the test *JProgressBarOrientationRobotTest.java*
>>>> after doing a *make java.desktop* after commenting out my code
>>>> changes in *AquaProgressBarUI.java* :
>>>> 
>>>> run:
>>>> [Metal]: LTR orientation test passed
>>>> [Metal]: RTL orientation test passed
>>>> [Nimbus]: LTR orientation test passed
>>>> [Nimbus]: RTL orientation test passed
>>>> [CDE/Motif]: LTR orientation test passed
>>>> [CDE/Motif]: RTL orientation test passed
>>>> [Mac OS X]: LTR orientation test passed
>>>> [Mac OS X]: [Error]: LTR orientation test failed
>>>> [Mac OS X]: [Error]: LTR orientation test failed
>>>> BUILD SUCCESSFUL (total time: 31 seconds)
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 20-Jan-2016, at 4:30 pm, Alexander Scherbatiy
>>>>> <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>> wrote:
>>>>> 
>>>>> 
>>>>> The fix looks good to me.
>>>>> 
>>>>> Thanks,
>>>>> Alexandr.
>>>>> 
>>>>> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>>>>>> 
>>>>>> Looks good to me.
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Rajeev Chamyal
>>>>>> 
>>>>>> *From:*Avik Niyogi
>>>>>> *Sent:* 20 January 2016 12:23
>>>>>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>>>>>> *Cc:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net> <mailto:swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>>
>>>>>> *Subject:* Re: <Swing Dev> Review request for 8015748: JProgressbar
>>>>>> with Aqua LaF ignores
>>>>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>>> call
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> Please review the code changes made as with inputs for the webrev:
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/ <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/>
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/ <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/>>
>>>>>> 
>>>>>> With Regards,
>>>>>> 
>>>>>> Avik Niyogi
>>>>>> 
>>>>>>   On 20-Jan-2016, at 10:40 am, Rajeev Chamyal
>>>>>>   <rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com> <mailto:rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com>>
>>>>>> <mailto:rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com>>> wrote:
>>>>>> 
>>>>>>   Hello Avik,
>>>>>> 
>>>>>>   All exception caught during test should mark the test as failed.
>>>>>>   For example not able to set any LAF should also be considered as
>>>>>>   test failure.
>>>>>> 
>>>>>>   Regards,
>>>>>> 
>>>>>>   Rajeev Chamyal
>>>>>> 
>>>>>>   *From:*Avik Niyogi
>>>>>>   *Sent:*20 January 2016 10:20
>>>>>>   *To:*Rajeev Chamyal
>>>>>>   *Cc:*Alexander Scherbatiy; Sergey Bylokhov
>>>>>>   *Subject:*Re: <Swing Dev> Review request for 8015748: JProgressbar
>>>>>>   with Aqua LaF ignores
>>>>>>   JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>>>   call
>>>>>> 
>>>>>>   Hi Rajeev and Sergey,
>>>>>> 
>>>>>>   A gentle reminder. Kindly request to complete the pending review
>>>>>>   of my code changes in the webrev:
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/>
>>>>>>   <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/ <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>>
>>>>>> 
>>>>>>   Thank you in advance.
>>>>>> 
>>>>>>   With Regards,
>>>>>> 
>>>>>>   Avik Niyogi
>>>>>> 
>>>>>>       On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy
>>>>>>       <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>       <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>> wrote:
>>>>>> 
>>>>>> 
>>>>>>        The fix looks good to me.
>>>>>> 
>>>>>>        Thanks,
>>>>>>        Alexandr.
>>>>>> 
>>>>>> 
>>>>>>       On 19/01/16 15:27, Avik Niyogi wrote:
>>>>>> 
>>>>>>           Hi All,
>>>>>> 
>>>>>>           A gentle reminder. Please review my code changes as
>>>>>>           mentioned in the webrev below as available in the link in
>>>>>>           the mail trail.
>>>>>> 
>>>>>>           With Regards,
>>>>>> 
>>>>>>           Avik Niyogi
>>>>>> 
>>>>>>               On 18-Jan-2016, at 11:34 am, Avik Niyogi
>>>>>>               <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>
>>>>>>               <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>> wrote:
>>>>>> 
>>>>>>               Hi All, Please find the changes as provided with
>>>>>>               incorporation of inputs:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/>
>>>>>>               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/ <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>>
>>>>>> 
>>>>>>               With Regards,
>>>>>> 
>>>>>>               Avik Niyogi
>>>>>> 
>>>>>>                   On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov
>>>>>>                   <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>                   <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>> 
>>>>>>                   Probably I missed something but why we need two
>>>>>>                   tests? Note that the manual test is not marked as
>>>>>>                   manual, which means that it will be run during the
>>>>>>                   regular run?(even if -a option is provided to
>>>>>>                   jtreg). Please check your other review requests
>>>>>>                   for this issue.
>>>>>> 
>>>>>>                   moreover on my system
>>>>>>                   JProgressBarOrientationManualTest.java simply
>>>>>>                   passed, and JProgressBarOrientationRobotTest.java
>>>>>>                   failed even after the fix. Please recheck.
>>>>>> 
>>>>>>                   On 14/01/16 13:11, Avik Niyogi wrote:
>>>>>> 
>>>>>> 
>>>>>>                       Hi All,
>>>>>>                       Please find the changes as provided with
>>>>>>                       incorporation of inputs:
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/
>>>>>>                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.05/>
>>>>>> 
>>>>>>                       With Regards,
>>>>>>                       Avik Niyogi
>>>>>> 
>>>>>> 
>>>>>>                           On 14-Jan-2016, at 3:18 pm, Alexander
>>>>>>                           Scherbatiy
>>>>>>                           <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>                           <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>                           wrote:
>>>>>> 
>>>>>>                           On 1/14/2016 8:18 AM, Avik Niyogi wrote:
>>>>>> 
>>>>>> 
>>>>>>                               Hi All,
>>>>>>                               Please find changes as provided with
>>>>>>                               incorporation of inputs:
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/
>>>>>>                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>>                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>> 
>>>>>> 
>>>>>>                            It is better to restore the graphics
>>>>>>                           transform after the progress
>>>>>>                           bar is painted and before the paintString
>>>>>>                           call because the a method
>>>>>>                           that calls
>>>>>>                           AquaProgressBarUI.paint(Graphics) can rely
>>>>>>                           that the
>>>>>>                           graphics transform is unchanged.
>>>>>>                           In your fix the graphics transform is not
>>>>>>                           restored if
>>>>>>                           progressBar.isStringPainted() returns false.
>>>>>> 
>>>>>>                           Thanks,
>>>>>>                           Alexandr.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>                               With Regards,
>>>>>>                               Avik Niyogi
>>>>>> 
>>>>>> 
>>>>>>                                   On 13-Jan-2016, at 7:02 pm,
>>>>>>                                   Alexander Scherbatiy
>>>>>>                                   <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>                                   <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>                                   <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>                                   <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>                                   wrote:
>>>>>> 
>>>>>>                                   On 1/13/2016 9:28 AM, Avik Niyogi
>>>>>>                                   wrote:
>>>>>> 
>>>>>> 
>>>>>>                                       Hi All,
>>>>>>                                       Please find changes as
>>>>>>                                       provided with incorporation of
>>>>>>                                       inputs:
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.03/
>>>>>>                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>>                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>>                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>> 
>>>>>> 
>>>>>>                                   It looks like a string on a
>>>>>>                                   vertical progress bar with the
>>>>>>                                   right to
>>>>>>                                   left orientation will be mirrored.
>>>>>>                                   Did you try just restore the
>>>>>>                                   scale/translate transform after the
>>>>>>                                   painter.paint() call? Will it help
>>>>>>                                   in such case?
>>>>>> 
>>>>>>                                   Thanks,
>>>>>>                                   Alexandr.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>                                       With Regards,
>>>>>>                                       Avik Niyogi
>>>>>> 
>>>>>> 
>>>>>>                                           On 12-Jan-2016, at 11:49
>>>>>>                                           pm, Alexander Scherbatiy
>>>>>>                                           <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>                                           wrote:
>>>>>> 
>>>>>> 
>>>>>>                                           - there was the comment
>>>>>>                                           below that it is better to
>>>>>>                                           revert the
>>>>>>                                           transform back after the
>>>>>>                                           painter.paint() call
>>>>>>                                           - according to the comment
>>>>>>                                           from the
>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-January/005262.html
>>>>>> 
>>>>>>                                           It is true that a filled
>>>>>>                                           progress bar has different
>>>>>>                                           colors because
>>>>>>                                           of animation under Aqua L&F.
>>>>>>                                           However, it is possible to
>>>>>>                                           compare colors before a
>>>>>>                                           progress bar
>>>>>>                                           was filled and after that
>>>>>>                                           to check that the progress
>>>>>>                                           bar is filled
>>>>>>                                           from the correct side.
>>>>>>                                           For example let's set a
>>>>>>                                           progress bar value to 0
>>>>>>                                           and get its color
>>>>>>                                           from 5/6 of the progress
>>>>>>                                           bar width
>>>>>>                                             progress bar:
>>>>>>                                           [_________o__]  // get a
>>>>>>                                           color at point o
>>>>>>                                           Now set the progress bar
>>>>>>                                           value to 30 and get a
>>>>>>                                           color at the same
>>>>>>                                           point.
>>>>>>                                           If colors are the same
>>>>>>                                           then  the progress bar is
>>>>>>                                           filled from left
>>>>>>                                           to the right [||||_____o__].
>>>>>>                                           If colors are different
>>>>>>                                           then the progress bar is
>>>>>>                                           filled from the
>>>>>>                                           right to the left
>>>>>>                                           [________|o||] .
>>>>>> 
>>>>>>                                           Thanks,
>>>>>>                                           Alexandr.
>>>>>> 
>>>>>> 
>>>>>>                                           On 12/01/16 13:34, Avik
>>>>>>                                           Niyogi wrote:
>>>>>> 
>>>>>> 
>>>>>>                                               Hi All,
>>>>>> 
>>>>>>                                               Please find the code
>>>>>>                                               changes in fix as with
>>>>>>                                               the inputs received
>>>>>>                                               for the same.
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.02/
>>>>>>                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>>                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>>                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>> 
>>>>>>                                               With Regards,
>>>>>>                                               Avik Niyogi
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>                                                   On 11-Jan-2016, at
>>>>>>                                                   3:55 pm, Semyon
>>>>>>                                                   Sadetsky
>>>>>>                                                   <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>
>>>>>> <mailto:semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>
>>>>>>                                                   <mailto:semyon.sadetsky at oracle.com><mailto:semyon.sadetsky at oracle.com>
>>>>>>                                                   <mailto:semyon.sadetsky at oracle.com>
>>>>>>                                                   <mailto:semyon.sadetsky at oracle.com>>
>>>>>>                                                   wrote:
>>>>>> 
>>>>>>                                                   Hi Avik,
>>>>>> 
>>>>>>                                                   Shouldn't the
>>>>>>                                                   graphics
>>>>>>                                                   transformation be
>>>>>>                                                   restored before the
>>>>>>                                                   paintString() call?
>>>>>> 
>>>>>>                                                   It seems to me
>>>>>>                                                   that left/right
>>>>>>                                                   insets need to be
>>>>>>                                                   swapped for
>>>>>>                                                   right-to-left
>>>>>>                                                   painting with
>>>>>>                                                   mirroring graphics
>>>>>>                                                   transformation.
>>>>>> 
>>>>>>                                                   --Semyon
>>>>>> 
>>>>>>                                                   On 1/5/2016 1:22
>>>>>>                                                   PM, Avik Niyogi
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>>                                                       Hi All,
>>>>>>                                                       Please find
>>>>>>                                                       webrev with
>>>>>>                                                       inputs as
>>>>>>                                                       provided:
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.01/
>>>>>>                                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>>                                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>>                                                       With Regards,
>>>>>>                                                       Avik Niyogi
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>                                                           On
>>>>>>                                                           23-Dec-2015,
>>>>>>                                                           at 7:29
>>>>>>                                                           pm,
>>>>>>                                                           Alexander
>>>>>>                                                           Scherbatiy
>>>>>>                                                           <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>                                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>                                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>                                                           <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>                                                           wrote:
>>>>>> 
>>>>>> 
>>>>>>                                                           - please
>>>>>>                                                           check that
>>>>>>                                                           the
>>>>>>                                                           progress
>>>>>>                                                           bar string
>>>>>>                                                           (progressBar.setString()/setStringPainted())
>>>>>>                                                           is painted
>>>>>>                                                           correctly.
>>>>>>                                                           - is it
>>>>>>                                                           possible
>>>>>>                                                           to write
>>>>>>                                                           an
>>>>>>                                                           automated
>>>>>>                                                           test for
>>>>>>                                                           the fix?
>>>>>> 
>>>>>>                                                           Thanks,
>>>>>>                                                           Alexandr.
>>>>>> 
>>>>>>                                                           On
>>>>>>                                                           12/21/2015
>>>>>>                                                           11:47 AM,
>>>>>>                                                           Avik
>>>>>>                                                           Niyogi
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>>                                                               Hi All,
>>>>>> 
>>>>>>                                                               Kindly
>>>>>>                                                               review
>>>>>>                                                               the
>>>>>>                                                               bug
>>>>>>                                                               fix
>>>>>>                                                               for
>>>>>> JDK 9.
>>>>>> 
>>>>>>                                                               *Bug:*
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8015748
>>>>>> 
>>>>>>                                                               *Webrev:*
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.00/
>>>>>>                                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>>                                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>>                                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>> 
>>>>>>                                                               *Issue:*
>>>>>>                                                               The
>>>>>>                                                               manual
>>>>>>                                                               test:
>>>>>>                                                               Swing_JProgressbar/Manual/ProgressBarLAFTests/ProgressBarLAFTest1
>>>>>>                                                               in
>>>>>>                                                               testsuite
>>>>>> http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/7/swing
>>>>>>                                                               fails
>>>>>> 
>>>>>>                                                               *Cause:*
>>>>>>                                                               Due to
>>>>>>                                                               not
>>>>>>                                                               honouring
>>>>>>                                                               of
>>>>>>                                                               RIGHT_TO_LEFT
>>>>>>                                                               parameter
>>>>>>                                                               for
>>>>>>                                                               setOrientation
>>>>>>                                                               method
>>>>>>                                                               applied
>>>>>> for
>>>>>>                                                               a
>>>>>>                                                               JProgressBar
>>>>>>                                                               for the
>>>>>>                                                               AquaLookAndFeel
>>>>>>                                                               only,
>>>>>>                                                               the
>>>>>>                                                               progressBar
>>>>>>                                                               does
>>>>>>                                                               not
>>>>>>                                                               have
>>>>>>                                                               the
>>>>>>                                                               ability
>>>>>> to
>>>>>>                                                               grow
>>>>>>                                                               from
>>>>>> right
>>>>>>                                                               to
>>>>>>                                                               left.
>>>>>>                                                               This
>>>>>>                                                               issue
>>>>>>                                                               was
>>>>>>                                                               verified
>>>>>>                                                               to
>>>>>>                                                               exist
>>>>>>                                                               only in
>>>>>>                                                               AquaLookAndFeel
>>>>>>                                                               for
>>>>>>                                                               JProgressBar.
>>>>>> 
>>>>>>                                                               *Fix:*
>>>>>>                                                               Added
>>>>>>                                                               implementation
>>>>>>                                                               for
>>>>>>                                                               the
>>>>>>                                                               check
>>>>>>                                                               of
>>>>>>                                                               RIGHT_TO_LEFT
>>>>>>                                                               ComponentOrientation
>>>>>>                                                               and
>>>>>>                                                               verified
>>>>>>                                                               with
>>>>>>                                                               other
>>>>>>                                                               combination
>>>>>>                                                               orientation
>>>>>>                                                               with
>>>>>>                                                               available
>>>>>>                                                               Horizontal
>>>>>>                                                               and
>>>>>>                                                               Vertical
>>>>>>                                                               orientations
>>>>>>                                                               as
>>>>>>                                                               provided
>>>>>>                                                               from
>>>>>>                                                               before.
>>>>>> 
>>>>>>                                                               With
>>>>>>                                                               Regards,
>>>>>>                                                               Avik
>>>>>>                                                               Niyogi
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>                   --
>>>>>>                   Best regards, Sergey.
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/bbc4745c/attachment.html>

From avik.niyogi at oracle.com  Mon Mar 21 05:19:06 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 21 Mar 2016 10:49:06 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <56EC6376.5020106@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
Message-ID: <A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>

Hi Alexander,
I agree with what you said regarding the look and feel looking different. But this bug arrises due to setting of TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua look and feel should not the setting of this parameter instead throw a helpful error saying this parameter is not accepted instead of absorbing this parameter and letting it render itself into a dummy node which does not proceed further with this parameter? Maybe we need to discuss what the expected behaviour may be. Also, thank you for the inputs regarding how to proceed with removing duplicate code.

With Regards,
Avik Niyogi
> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> 
> I would think about something like:
> -------------
>     public class TabbedPaneLayout implements LayoutManager {
> 
>         protected int basePreferredTabAreaWidth(final int tabPlacement, final int height) {
>             // TabbedPaneLayout preferredTabAreaWidth implementation
>         }
> 
>         protected int truncatingPreferredTabAreaWidth(final int tabPlacement, final int height) {
>             if (tabPlacement == SwingConstants.LEFT || tabPlacement == SwingConstants.RIGHT) {
>                 return basePreferredTabAreaWidth(tabPlacement, height);
>             }
> 
>             return basePreferredTabAreaWidth(tabPlacement, height);
>         }
> 
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return basePreferredTabAreaWidth(tabPlacement, height);
>         }
> 
>     }
> 
>     class TabbedPaneScrollLayout extends TabbedPaneLayout {
>         @Override
>         protected int basePreferredTabAreaWidth(int tabPlacement, int height) {
>             // TabbedPaneScrollLayout preferredTabAreaWidth implementation
>         }
>     }
> 
>     protected class AquaTruncatingTabbedPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
> 
>         @Override
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>         }
>     }
> 
>     protected class AquaTruncatingTabbedScrollPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
> 
>         @Override
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>         }
>     }
> -------------
> 
> I just have one more question. The TabbedPaneScrollLayout is only created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
> 
> Are there any real cases when the TabbedPaneScrollLayout is created?
> 
> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not look similar to Aqua L&F:
>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png <http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png>
> 
> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs navigation.
> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
> 
> Thanks,
> Alexandr.
> 
> On 18/03/16 14:21, Avik Niyogi wrote:
>> Hi Alexander,
>> Thank you for the inputs. I agree with you and did feel the need for removing duplicate code as well. But as per an earlier review input, changes to the super call lay outing is not accepted. This was the only other feasible solution. Created redundant code in this process, but would be maintaining with requirements with code impact to superclasses.
>> Please provide any insight to a probable compensate to mitigate this dichotomy of code expectation. Thank you in advance.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>> 
>>> 
>>> It is not usually a good idea to have a duplicated code which should be updated every time in several places.
>>> 
>>> Is it possible to move the  methods used both in AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with different names and then reused?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 17/03/16 17:17, Avik Niyogi wrote:
>>>> Hi Alexander,
>>>> The issue only applies for ScrollingTabbedPane and hence this fix.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy < <mailto:alexandr.scherbatiy at oracle.com>alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>> 
>>>>> 
>>>>> Does the same issue affects the AquaTabbedPaneContrastUI?
>>>>> 
>>>>> Thanks,
>>>>> Alexandr.
>>>>> 
>>>>> On 14/03/16 09:04, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> A gentle reminder, please review code changes.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Please review code changes done as with inputs provided.
>>>>>>>  <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/>
>>>>>>> 
>>>>>>> Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
>>>>>>> In the new fix as provided, references to base class layout manager is removed in current solution.
>>>>>>> 
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>> 
>>>>>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> Hello Avik
>>>>>>>> 
>>>>>>>> Let me make it clear I don't approve the proposed fix
>>>>>>>> and ask you to do additional evaluation.
>>>>>>>> 
>>>>>>>> Every LookAndFeel is different and it doesn't make much sense
>>>>>>>> to compare Metal LaF with AquaLaf.
>>>>>>>> 
>>>>>>>> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
>>>>>>>> 
>>>>>>>> The bug you are fixing has the following subject 
>>>>>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>>>>>> 
>>>>>>>> Could you please fix exactly the problem with the minimal heights,
>>>>>>>> without changing the UI delegate class.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> alexp
>>>>>>>> 
>>>>>>>>> Gentle reminder. Please review this fix.
>>>>>>>>> 
>>>>>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>>>>>>>  and not TabbedPaneLayout() as which is the default.
>>>>>>>>>> 
>>>>>>>>>> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
>>>>>>>>>> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>>>>>>>>>> 
>>>>>>>>>> Fixing the minimum size in AquaTabbedPaneUI will fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>>>>>>>>> 
>>>>>>>>>> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
>>>>>>>>>> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>>>>>>>>>> 
>>>>>>>>>> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>>>>>>>>>> 
>>>>>>>>>> With Regards,
>>>>>>>>>> Avik Niyogi
>>>>>>>>>> 
>>>>>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hello Avik
>>>>>>>>>>> 
>>>>>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
>>>>>>>>>>> I don't think setting the layout manager from the base class is the right solution here.
>>>>>>>>>>> 
>>>>>>>>>>> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
>>>>>>>>>>> 
>>>>>>>>>>> Thanks
>>>>>>>>>>> alexp
>>>>>>>>>>> 
>>>>>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>> 
>>>>>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>>>>> 
>>>>>>>>>>>> Bug:
>>>>>>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8137169>https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>>>>>>>>>>> 
>>>>>>>>>>>> Webrev:
>>>>>>>>>>>> 
>>>>>>>>>>>>  <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>
>>>>>>>>>>>> 
>>>>>>>>>>>> Issue:
>>>>>>>>>>>> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cause:
>>>>>>>>>>>> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>>>>>> 
>>>>>>>>>>>> Fix:
>>>>>>>>>>>> Major linking calls to super class fix done within createLayoutManager().
>>>>>>>>>>>> 
>>>>>>>>>>>> With Regards,
>>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/945d2cd0/attachment.html>

From alexandr.scherbatiy at oracle.com  Mon Mar 21 06:01:13 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 21 Mar 2016 10:01:13 +0400
Subject: <Swing Dev> CFV: New Swing Group Member: Semyon Sadetsky
Message-ID: <56EF8E29.4070605@oracle.com>


I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to 
Membership in the Swing Group.

Semyon is active member of Swing group and contributed a lot of fixes 
which include Swing TimerQueue race condition improvement, UndoManager 
deadlock resolving, proposing and implementation a public API for 
internal Swing functionality which is part of Swing modularization 
support for JDK 9, and others (see Semyon?s list OpenJDK changesets [1])

Semyon proposed a big change for the Swing part of the JEP 283 ?Enable 
GTK 3 on Linux? [2] implementation [3].

Semyon not only provides fixes for Swing issues but also regularly 
reviews fixes suggested by other members.

Votes are due by Apr 5, 2016.

Only current Members of the Swing  Group [4] are eligible
to vote on this nomination.

For Lazy Consensus voting instructions, see [5].

Thanks,
Alexandr.

[1] 
http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ssadetsky%22%29
[2] http://openjdk.java.net/jeps/283
[3] http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005440.html
[4] http://openjdk.java.net/census#swing
[5] http://openjdk.java.net/groups/#member-vote


From avik.niyogi at oracle.com  Mon Mar 21 06:45:06 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 21 Mar 2016 12:15:06 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <D72D2B05-D686-4BDE-961D-008BA426B0DD@oracle.com>
References: <EB8A0826-B75D-4FB7-8BF0-41C1E7C40CBA@oracle.com>
	<567AA8BF.5030407@oracle.com>
	<F8D8FE05-3A26-40B4-98A2-3BF0724EE408@oracle.com>
	<56938303.8050907@oracle.com>
	<DAD2ACAB-5640-40E4-89B2-B1256EB53A5B@oracle.com>
	<569543A5.7040109@oracle.com>
	<B2381901-6398-4C69-8077-1144175E461C@oracle.com>
	<569651D3.4080604@oracle.com>
	<A14D4B21-B5D3-4A08-BDB8-0956008BF208@oracle.com>
	<56976EF0.5080204@oracle.com>
	<2A741D47-D5A4-41F6-B57B-EE98B84685F5@oracle.com>
	<5697DA64.40501@oracle.com>
	<9FC2C3E2-1118-4F40-9A31-C1B01C0FF94D@oracle.com>
	<4A7B5E21-686C-45B4-8821-4F0D2CEA2E42@oracle.com>
	<569E56DC.10908@oracle.com>
	<5FBB51B9-1C62-47D0-AAC7-35849350EA21@oracle.com>
	<52e60872-c7cb-4b04-b257-24d6b975ba22@default>
	<33152751-3DA9-40FB-9900-FA204D16DAF6@oracle.com>
	<a0f24f2d-5634-4365-95fb-bf07d440fb75@default>
	<569F68DD.3010705@oracle.com>
	<6398FB4E-663B-4DC6-97CE-19A0BB3574D4@oracle.com>
	<28266B2D-3427-4938-BC7D-9C62E1E43BC4@oracle.com>
	<A53CB1FD-28A4-4B22-BDF9-2268A122C764@oracle.co!
	m> <56ED367E.3050903@oracle.com>
	<D72D2B05-D686-4BDE-961D-008BA426B0DD@oracle.com>
Message-ID: <624D6C57-E5AE-429C-86B4-B4F67E11FD05@oracle.com>

Hi Sergey,
This bug fix has been committed and resolved. Does not require a review.

With Regards,
Avik Niyogi
> On 21-Mar-2016, at 10:42 am, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi Sergey,
> https://bugs.openjdk.java.net/browse/JDK-8151282 <https://bugs.openjdk.java.net/browse/JDK-8151282> is open and in progress.
> With Regards,
> Avik Niyogi
> 
>> On 19-Mar-2016, at 4:52 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>> 
>> I guess you need a separate CR for this, because JDK-8015748 was closed already.
>> 
>> On 21.01.16 6:49, Avik Niyogi wrote:
>>> Hi All,
>>> Please review my code change with inputs received:
>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/ <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/>
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 21-Jan-2016, at 8:30 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>
>>>> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>> wrote:
>>>> 
>>>> Hi Sergey,
>>>> The JTreg will pass, but the errors are posted to the log and not as
>>>> an interrupt as it would prematurely terminate execution of entire
>>>> test case for other look and feels if done so.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 21-Jan-2016, at 8:26 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>
>>>>> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>> wrote:
>>>>> 
>>>>> Hi Sergey,
>>>>> This is the *log* of the test *JProgressBarOrientationRobotTest.java*
>>>>> after doing a *make java.desktop* after commenting out my code
>>>>> changes in *AquaProgressBarUI.java* :
>>>>> 
>>>>> run:
>>>>> [Metal]: LTR orientation test passed
>>>>> [Metal]: RTL orientation test passed
>>>>> [Nimbus]: LTR orientation test passed
>>>>> [Nimbus]: RTL orientation test passed
>>>>> [CDE/Motif]: LTR orientation test passed
>>>>> [CDE/Motif]: RTL orientation test passed
>>>>> [Mac OS X]: LTR orientation test passed
>>>>> [Mac OS X]: [Error]: LTR orientation test failed
>>>>> [Mac OS X]: [Error]: LTR orientation test failed
>>>>> BUILD SUCCESSFUL (total time: 31 seconds)
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>> 
>>>>>> On 20-Jan-2016, at 4:30 pm, Alexander Scherbatiy
>>>>>> <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> The fix looks good to me.
>>>>>> 
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>> 
>>>>>> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>>>>>>> 
>>>>>>> Looks good to me.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Rajeev Chamyal
>>>>>>> 
>>>>>>> *From:*Avik Niyogi
>>>>>>> *Sent:* 20 January 2016 12:23
>>>>>>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>>>>>>> *Cc:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net> <mailto:swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>>
>>>>>>> *Subject:* Re: <Swing Dev> Review request for 8015748: JProgressbar
>>>>>>> with Aqua LaF ignores
>>>>>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>>>> call
>>>>>>> 
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Please review the code changes made as with inputs for the webrev:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/ <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/>
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/ <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/>>
>>>>>>> 
>>>>>>> With Regards,
>>>>>>> 
>>>>>>> Avik Niyogi
>>>>>>> 
>>>>>>>   On 20-Jan-2016, at 10:40 am, Rajeev Chamyal
>>>>>>>   <rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com> <mailto:rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com>>
>>>>>>> <mailto:rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com>>> wrote:
>>>>>>> 
>>>>>>>   Hello Avik,
>>>>>>> 
>>>>>>>   All exception caught during test should mark the test as failed.
>>>>>>>   For example not able to set any LAF should also be considered as
>>>>>>>   test failure.
>>>>>>> 
>>>>>>>   Regards,
>>>>>>> 
>>>>>>>   Rajeev Chamyal
>>>>>>> 
>>>>>>>   *From:*Avik Niyogi
>>>>>>>   *Sent:*20 January 2016 10:20
>>>>>>>   *To:*Rajeev Chamyal
>>>>>>>   *Cc:*Alexander Scherbatiy; Sergey Bylokhov
>>>>>>>   *Subject:*Re: <Swing Dev> Review request for 8015748: JProgressbar
>>>>>>>   with Aqua LaF ignores
>>>>>>>   JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>>>>   call
>>>>>>> 
>>>>>>>   Hi Rajeev and Sergey,
>>>>>>> 
>>>>>>>   A gentle reminder. Kindly request to complete the pending review
>>>>>>>   of my code changes in the webrev:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/>
>>>>>>>   <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/ <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>>
>>>>>>> 
>>>>>>>   Thank you in advance.
>>>>>>> 
>>>>>>>   With Regards,
>>>>>>> 
>>>>>>>   Avik Niyogi
>>>>>>> 
>>>>>>>       On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy
>>>>>>>       <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>       <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>        The fix looks good to me.
>>>>>>> 
>>>>>>>        Thanks,
>>>>>>>        Alexandr.
>>>>>>> 
>>>>>>> 
>>>>>>>       On 19/01/16 15:27, Avik Niyogi wrote:
>>>>>>> 
>>>>>>>           Hi All,
>>>>>>> 
>>>>>>>           A gentle reminder. Please review my code changes as
>>>>>>>           mentioned in the webrev below as available in the link in
>>>>>>>           the mail trail.
>>>>>>> 
>>>>>>>           With Regards,
>>>>>>> 
>>>>>>>           Avik Niyogi
>>>>>>> 
>>>>>>>               On 18-Jan-2016, at 11:34 am, Avik Niyogi
>>>>>>>               <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>
>>>>>>>               <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>> wrote:
>>>>>>> 
>>>>>>>               Hi All, Please find the changes as provided with
>>>>>>>               incorporation of inputs:
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/>
>>>>>>>               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/ <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>>
>>>>>>> 
>>>>>>>               With Regards,
>>>>>>> 
>>>>>>>               Avik Niyogi
>>>>>>> 
>>>>>>>                   On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov
>>>>>>>                   <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>                   <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>>>>>>> 
>>>>>>>                   Probably I missed something but why we need two
>>>>>>>                   tests? Note that the manual test is not marked as
>>>>>>>                   manual, which means that it will be run during the
>>>>>>>                   regular run?(even if -a option is provided to
>>>>>>>                   jtreg). Please check your other review requests
>>>>>>>                   for this issue.
>>>>>>> 
>>>>>>>                   moreover on my system
>>>>>>>                   JProgressBarOrientationManualTest.java simply
>>>>>>>                   passed, and JProgressBarOrientationRobotTest.java
>>>>>>>                   failed even after the fix. Please recheck.
>>>>>>> 
>>>>>>>                   On 14/01/16 13:11, Avik Niyogi wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>                       Hi All,
>>>>>>>                       Please find the changes as provided with
>>>>>>>                       incorporation of inputs:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/ <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/>
>>>>>>>                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.05/>
>>>>>>> 
>>>>>>>                       With Regards,
>>>>>>>                       Avik Niyogi
>>>>>>> 
>>>>>>> 
>>>>>>>                           On 14-Jan-2016, at 3:18 pm, Alexander
>>>>>>>                           Scherbatiy
>>>>>>>                           <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                           <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                           wrote:
>>>>>>> 
>>>>>>>                           On 1/14/2016 8:18 AM, Avik Niyogi wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>                               Hi All,
>>>>>>>                               Please find changes as provided with
>>>>>>>                               incorporation of inputs:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/
>>>>>>>                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>>>                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>>> 
>>>>>>> 
>>>>>>>                            It is better to restore the graphics
>>>>>>>                           transform after the progress
>>>>>>>                           bar is painted and before the paintString
>>>>>>>                           call because the a method
>>>>>>>                           that calls
>>>>>>>                           AquaProgressBarUI.paint(Graphics) can rely
>>>>>>>                           that the
>>>>>>>                           graphics transform is unchanged.
>>>>>>>                           In your fix the graphics transform is not
>>>>>>>                           restored if
>>>>>>>                           progressBar.isStringPainted() returns false.
>>>>>>> 
>>>>>>>                           Thanks,
>>>>>>>                           Alexandr.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>                               With Regards,
>>>>>>>                               Avik Niyogi
>>>>>>> 
>>>>>>> 
>>>>>>>                                   On 13-Jan-2016, at 7:02 pm,
>>>>>>>                                   Alexander Scherbatiy
>>>>>>>                                   <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                                   <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                   <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                   <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                                   wrote:
>>>>>>> 
>>>>>>>                                   On 1/13/2016 9:28 AM, Avik Niyogi
>>>>>>>                                   wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>                                       Hi All,
>>>>>>>                                       Please find changes as
>>>>>>>                                       provided with incorporation of
>>>>>>>                                       inputs:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.03/
>>>>>>>                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>>>                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>>>                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>>> 
>>>>>>> 
>>>>>>>                                   It looks like a string on a
>>>>>>>                                   vertical progress bar with the
>>>>>>>                                   right to
>>>>>>>                                   left orientation will be mirrored.
>>>>>>>                                   Did you try just restore the
>>>>>>>                                   scale/translate transform after the
>>>>>>>                                   painter.paint() call? Will it help
>>>>>>>                                   in such case?
>>>>>>> 
>>>>>>>                                   Thanks,
>>>>>>>                                   Alexandr.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>                                       With Regards,
>>>>>>>                                       Avik Niyogi
>>>>>>> 
>>>>>>> 
>>>>>>>                                           On 12-Jan-2016, at 11:49
>>>>>>>                                           pm, Alexander Scherbatiy
>>>>>>>                                           <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                                           wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>                                           - there was the comment
>>>>>>>                                           below that it is better to
>>>>>>>                                           revert the
>>>>>>>                                           transform back after the
>>>>>>>                                           painter.paint() call
>>>>>>>                                           - according to the comment
>>>>>>>                                           from the
>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-January/005262.html
>>>>>>> 
>>>>>>>                                           It is true that a filled
>>>>>>>                                           progress bar has different
>>>>>>>                                           colors because
>>>>>>>                                           of animation under Aqua L&F.
>>>>>>>                                           However, it is possible to
>>>>>>>                                           compare colors before a
>>>>>>>                                           progress bar
>>>>>>>                                           was filled and after that
>>>>>>>                                           to check that the progress
>>>>>>>                                           bar is filled
>>>>>>>                                           from the correct side.
>>>>>>>                                           For example let's set a
>>>>>>>                                           progress bar value to 0
>>>>>>>                                           and get its color
>>>>>>>                                           from 5/6 of the progress
>>>>>>>                                           bar width
>>>>>>>                                             progress bar:
>>>>>>>                                           [_________o__]  // get a
>>>>>>>                                           color at point o
>>>>>>>                                           Now set the progress bar
>>>>>>>                                           value to 30 and get a
>>>>>>>                                           color at the same
>>>>>>>                                           point.
>>>>>>>                                           If colors are the same
>>>>>>>                                           then  the progress bar is
>>>>>>>                                           filled from left
>>>>>>>                                           to the right [||||_____o__].
>>>>>>>                                           If colors are different
>>>>>>>                                           then the progress bar is
>>>>>>>                                           filled from the
>>>>>>>                                           right to the left
>>>>>>>                                           [________|o||] .
>>>>>>> 
>>>>>>>                                           Thanks,
>>>>>>>                                           Alexandr.
>>>>>>> 
>>>>>>> 
>>>>>>>                                           On 12/01/16 13:34, Avik
>>>>>>>                                           Niyogi wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>                                               Hi All,
>>>>>>> 
>>>>>>>                                               Please find the code
>>>>>>>                                               changes in fix as with
>>>>>>>                                               the inputs received
>>>>>>>                                               for the same.
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.02/
>>>>>>>                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>>>                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>>>                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>>> 
>>>>>>>                                               With Regards,
>>>>>>>                                               Avik Niyogi
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>                                                   On 11-Jan-2016, at
>>>>>>>                                                   3:55 pm, Semyon
>>>>>>>                                                   Sadetsky
>>>>>>>                                                   <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>
>>>>>>> <mailto:semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>
>>>>>>>                                                   <mailto:semyon.sadetsky at oracle.com><mailto:semyon.sadetsky at oracle.com>
>>>>>>>                                                   <mailto:semyon.sadetsky at oracle.com>
>>>>>>>                                                   <mailto:semyon.sadetsky at oracle.com>>
>>>>>>>                                                   wrote:
>>>>>>> 
>>>>>>>                                                   Hi Avik,
>>>>>>> 
>>>>>>>                                                   Shouldn't the
>>>>>>>                                                   graphics
>>>>>>>                                                   transformation be
>>>>>>>                                                   restored before the
>>>>>>>                                                   paintString() call?
>>>>>>> 
>>>>>>>                                                   It seems to me
>>>>>>>                                                   that left/right
>>>>>>>                                                   insets need to be
>>>>>>>                                                   swapped for
>>>>>>>                                                   right-to-left
>>>>>>>                                                   painting with
>>>>>>>                                                   mirroring graphics
>>>>>>>                                                   transformation.
>>>>>>> 
>>>>>>>                                                   --Semyon
>>>>>>> 
>>>>>>>                                                   On 1/5/2016 1:22
>>>>>>>                                                   PM, Avik Niyogi
>>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>                                                       Hi All,
>>>>>>>                                                       Please find
>>>>>>>                                                       webrev with
>>>>>>>                                                       inputs as
>>>>>>>                                                       provided:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.01/
>>>>>>>                                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>>>                                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>>>                                                       With Regards,
>>>>>>>                                                       Avik Niyogi
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>                                                           On
>>>>>>>                                                           23-Dec-2015,
>>>>>>>                                                           at 7:29
>>>>>>>                                                           pm,
>>>>>>>                                                           Alexander
>>>>>>>                                                           Scherbatiy
>>>>>>>                                                           <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                                           <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                                                           wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>                                                           - please
>>>>>>>                                                           check that
>>>>>>>                                                           the
>>>>>>>                                                           progress
>>>>>>>                                                           bar string
>>>>>>>                                                           (progressBar.setString()/setStringPainted())
>>>>>>>                                                           is painted
>>>>>>>                                                           correctly.
>>>>>>>                                                           - is it
>>>>>>>                                                           possible
>>>>>>>                                                           to write
>>>>>>>                                                           an
>>>>>>>                                                           automated
>>>>>>>                                                           test for
>>>>>>>                                                           the fix?
>>>>>>> 
>>>>>>>                                                           Thanks,
>>>>>>>                                                           Alexandr.
>>>>>>> 
>>>>>>>                                                           On
>>>>>>>                                                           12/21/2015
>>>>>>>                                                           11:47 AM,
>>>>>>>                                                           Avik
>>>>>>>                                                           Niyogi
>>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>                                                               Hi All,
>>>>>>> 
>>>>>>>                                                               Kindly
>>>>>>>                                                               review
>>>>>>>                                                               the
>>>>>>>                                                               bug
>>>>>>>                                                               fix
>>>>>>>                                                               for
>>>>>>> JDK 9.
>>>>>>> 
>>>>>>>                                                               *Bug:*
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8015748
>>>>>>> 
>>>>>>>                                                               *Webrev:*
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.00/
>>>>>>>                                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>>>                                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>>>                                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>>> 
>>>>>>>                                                               *Issue:*
>>>>>>>                                                               The
>>>>>>>                                                               manual
>>>>>>>                                                               test:
>>>>>>>                                                               Swing_JProgressbar/Manual/ProgressBarLAFTests/ProgressBarLAFTest1
>>>>>>>                                                               in
>>>>>>>                                                               testsuite
>>>>>>> http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/7/swing
>>>>>>>                                                               fails
>>>>>>> 
>>>>>>>                                                               *Cause:*
>>>>>>>                                                               Due to
>>>>>>>                                                               not
>>>>>>>                                                               honouring
>>>>>>>                                                               of
>>>>>>>                                                               RIGHT_TO_LEFT
>>>>>>>                                                               parameter
>>>>>>>                                                               for
>>>>>>>                                                               setOrientation
>>>>>>>                                                               method
>>>>>>>                                                               applied
>>>>>>> for
>>>>>>>                                                               a
>>>>>>>                                                               JProgressBar
>>>>>>>                                                               for the
>>>>>>>                                                               AquaLookAndFeel
>>>>>>>                                                               only,
>>>>>>>                                                               the
>>>>>>>                                                               progressBar
>>>>>>>                                                               does
>>>>>>>                                                               not
>>>>>>>                                                               have
>>>>>>>                                                               the
>>>>>>>                                                               ability
>>>>>>> to
>>>>>>>                                                               grow
>>>>>>>                                                               from
>>>>>>> right
>>>>>>>                                                               to
>>>>>>>                                                               left.
>>>>>>>                                                               This
>>>>>>>                                                               issue
>>>>>>>                                                               was
>>>>>>>                                                               verified
>>>>>>>                                                               to
>>>>>>>                                                               exist
>>>>>>>                                                               only in
>>>>>>>                                                               AquaLookAndFeel
>>>>>>>                                                               for
>>>>>>>                                                               JProgressBar.
>>>>>>> 
>>>>>>>                                                               *Fix:*
>>>>>>>                                                               Added
>>>>>>>                                                               implementation
>>>>>>>                                                               for
>>>>>>>                                                               the
>>>>>>>                                                               check
>>>>>>>                                                               of
>>>>>>>                                                               RIGHT_TO_LEFT
>>>>>>>                                                               ComponentOrientation
>>>>>>>                                                               and
>>>>>>>                                                               verified
>>>>>>>                                                               with
>>>>>>>                                                               other
>>>>>>>                                                               combination
>>>>>>>                                                               orientation
>>>>>>>                                                               with
>>>>>>>                                                               available
>>>>>>>                                                               Horizontal
>>>>>>>                                                               and
>>>>>>>                                                               Vertical
>>>>>>>                                                               orientations
>>>>>>>                                                               as
>>>>>>>                                                               provided
>>>>>>>                                                               from
>>>>>>>                                                               before.
>>>>>>> 
>>>>>>>                                                               With
>>>>>>>                                                               Regards,
>>>>>>>                                                               Avik
>>>>>>>                                                               Niyogi
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>                   --
>>>>>>>                   Best regards, Sergey.
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
>> -- 
>> Best regards, Sergey.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/1b0404af/attachment.html>

From avik.niyogi at oracle.com  Mon Mar 21 06:46:06 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 21 Mar 2016 12:16:06 +0530
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
	javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java
	fails with GTK LnF
In-Reply-To: <56EC68F6.5000106@oracle.com>
References: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
	<56E17C34.5030303@oracle.com>
	<8AE0341F-6D3A-4586-B7CC-38318B986450@oracle.com>
	<2DD39FDD-D8C9-47B6-BAAB-D1AEA0A22DF6@oracle.com>
	<56EC68F6.5000106@oracle.com>
Message-ID: <F78727F3-6931-4A40-A949-45EC3C716614@oracle.com>

Hi Sergey,
Please review the following code change.
With Regards,
Avik Niyogi
> On 19-Mar-2016, at 2:15 am, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 16:25, Avik Niyogi wrote:
>> Hi All,
>> Please review code changes made as per inputs provided.
>> 
>> http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/ <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.01/>
>> With Regards,
>> Avik Niyogi
>>> On 14-Mar-2016, at 10:53 am, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>> 
>>> Hi Sergey,
>>> Seems like it is a delay issue. Will submit test case with a waitForIdle() fix.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>> 
>>>> Hi, Avik.
>>>> A few questions.
>>>> - Why webrev contains the new file?
>>>> - You marked the test as a mac specific but it is iterates over a bunch of l&fs. It seems it should not be OS specific, but should check some specific l&fs (which support such icons): Metal, Nimbus, Aqua, Windows(???). So gtk/motif should be skipped.
>>>> 
>>>> On 08.03.16 8:10, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the bug fix for JDK 9.
>>>>> 
>>>>> *Bug:*
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8151282 <https://bugs.openjdk.java.net/browse/JDK-8151282>
>>>>> 
>>>>> *Webrev:*
>>>>> 
>>>>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_ <http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_>
>>>>> _
>>>>> _
>>>>> *Issue:*
>>>>> The test case failed for GTK LAF.
>>>>> 
>>>>> *Cause:*
>>>>> The test case was meant to be Mac specific and was missing a jtreg parameter
>>>>> 
>>>>> *Fix:*
>>>>> Minor change to test case with @requires tag added to set the fix.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>>> 
>>>> -- 
>>>> Best regards, Sergey.
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/d6ad0a81/attachment.html>

From avik.niyogi at oracle.com  Mon Mar 21 06:47:12 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 21 Mar 2016 12:17:12 +0530
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
	exception was raised entering Emoji into JTextArea
In-Reply-To: <56EAB22B.8010208@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com> <56E9A536.6090903@oracle.com>
	<E98C9197-A1A0-4C20-825F-5C36818064F0@oracle.com>
	<56EAB22B.8010208@oracle.com>
Message-ID: <6C1B06DD-6708-477F-A2AA-C384CCBE729C@oracle.com>

Hi Sergey,

Please review the following code changes.
With Regards,
Avik Niyogi
> On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> 
> The fix looks good to me.
> 
> Just a small note: it is better to remove comment "527         //" since it does not have a description.
> 
> Thanks,
> Alexandr.
> 
> On 17/03/16 17:21, Avik Niyogi wrote:
>> It can be made into a class method, but herein this case it is needed for that instance only and hence the need for instance method and referred with ?self?.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>> 
>>> 
>>> Could the -(NSMutableString *) parseString: method be declared as class method instead of instance?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 14/03/16 17:18, Sergey Bylokhov wrote:
>>>> Hi, Avik. 
>>>> Can you please take a look to these two tests before fixing this bug: 
>>>> 
>>>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
>>>> -------------------------------------------------- 
>>>> TEST: javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>>>> 
>>>> I remember they passed on jdk8, but it seems we have a regression in jdk9 and both of them fail. 
>>>> 
>>>> On 14.03.16 8:05, Avik Niyogi wrote: 
>>>>> Hi All, 
>>>>> A gentle reminder, please review my code changes. 
>>>>> 
>>>>> With Regards, 
>>>>> Avik Niyogi 
>>>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com> 
>>>>>> <mailto:avik.niyogi at oracle.com> <mailto:avik.niyogi at oracle.com>> wrote: 
>>>>>> 
>>>>>> Hi All, 
>>>>>> 
>>>>>> Kindly review the bug fix for JDK 9. 
>>>>>> 
>>>>>> *Bug:* 
>>>>>> 
>>>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_ <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
>>>>>> _ 
>>>>>> _ 
>>>>>> *Webrev:* 
>>>>>> 
>>>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ <http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_> 
>>>>>> 
>>>>>> *Issue:* 
>>>>>> Emoji selection in Character Viewer was causing exception in JNI 
>>>>>> 
>>>>>> *Cause:* 
>>>>>> Emojis are considered to be of different class type (namely, 
>>>>>> NSConcreteMutableAttributedString) from NSString which other 
>>>>>> characters are because of a surrogate pair for them. 
>>>>>> 
>>>>>> *Fix:* 
>>>>>> Major changes done for condition of emojis in JNI. Albeit rendering is 
>>>>>> not yet supported, they will appear as blank ?Missing font? notation. 
>>>>>> Also, added debug point in case of issue with glyph arrises. 
>>>>>> 
>>>>>> With Regards, 
>>>>>> Avik Niyogi 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/dca417c6/attachment.html>

From avik.niyogi at oracle.com  Mon Mar 21 06:50:15 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 21 Mar 2016 12:20:15 +0530
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
	exception was raised entering Emoji into JTextArea
In-Reply-To: <6C1B06DD-6708-477F-A2AA-C384CCBE729C@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com> <56E9A536.6090903@oracle.com>
	<E98C9197-A1A0-4C20-825F-5C36818064F0@oracle.com>
	<56EAB22B.8010208@oracle.com>
	<6C1B06DD-6708-477F-A2AA-C384CCBE729C@oracle.com>
Message-ID: <6FB602D3-1A5D-49E9-851A-B493231FC5BF@oracle.com>

Hi Rajeev,
Please review the following code changes.

With Regards,
Avik Niyogi
> On 21-Mar-2016, at 12:17 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi Sergey,
> 
> Please review the following code changes.
> With Regards,
> Avik Niyogi
>> On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>> 
>> 
>> The fix looks good to me.
>> 
>> Just a small note: it is better to remove comment "527         //" since it does not have a description.
>> 
>> Thanks,
>> Alexandr.
>> 
>> On 17/03/16 17:21, Avik Niyogi wrote:
>>> It can be made into a class method, but herein this case it is needed for that instance only and hence the need for instance method and referred with ?self?.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>> 
>>>> 
>>>> Could the -(NSMutableString *) parseString: method be declared as class method instead of instance?
>>>> 
>>>> Thanks,
>>>> Alexandr.
>>>> 
>>>> On 14/03/16 17:18, Sergey Bylokhov wrote:
>>>>> Hi, Avik. 
>>>>> Can you please take a look to these two tests before fixing this bug: 
>>>>> 
>>>>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
>>>>> -------------------------------------------------- 
>>>>> TEST: javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>>>>> 
>>>>> I remember they passed on jdk8, but it seems we have a regression in jdk9 and both of them fail. 
>>>>> 
>>>>> On 14.03.16 8:05, Avik Niyogi wrote: 
>>>>>> Hi All, 
>>>>>> A gentle reminder, please review my code changes. 
>>>>>> 
>>>>>> With Regards, 
>>>>>> Avik Niyogi 
>>>>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com> 
>>>>>>> <mailto:avik.niyogi at oracle.com> <mailto:avik.niyogi at oracle.com>> wrote: 
>>>>>>> 
>>>>>>> Hi All, 
>>>>>>> 
>>>>>>> Kindly review the bug fix for JDK 9. 
>>>>>>> 
>>>>>>> *Bug:* 
>>>>>>> 
>>>>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_ <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
>>>>>>> _ 
>>>>>>> _ 
>>>>>>> *Webrev:* 
>>>>>>> 
>>>>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ <http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_> 
>>>>>>> 
>>>>>>> *Issue:* 
>>>>>>> Emoji selection in Character Viewer was causing exception in JNI 
>>>>>>> 
>>>>>>> *Cause:* 
>>>>>>> Emojis are considered to be of different class type (namely, 
>>>>>>> NSConcreteMutableAttributedString) from NSString which other 
>>>>>>> characters are because of a surrogate pair for them. 
>>>>>>> 
>>>>>>> *Fix:* 
>>>>>>> Major changes done for condition of emojis in JNI. Albeit rendering is 
>>>>>>> not yet supported, they will appear as blank ?Missing font? notation. 
>>>>>>> Also, added debug point in case of issue with glyph arrises. 
>>>>>>> 
>>>>>>> With Regards, 
>>>>>>> Avik Niyogi 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/bdb33d9e/attachment.html>

From avik.niyogi at oracle.com  Mon Mar 21 06:55:20 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 21 Mar 2016 12:25:20 +0530
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
	exception was raised entering Emoji into JTextArea
In-Reply-To: <6FB602D3-1A5D-49E9-851A-B493231FC5BF@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com> <56E9A536.6090903@oracle.com>
	<E98C9197-A1A0-4C20-825F-5C36818064F0@oracle.com>
	<56EAB22B.8010208@oracle.com>
	<6C1B06DD-6708-477F-A2AA-C384CCBE729C@oracle.com>
	<6FB602D3-1A5D-49E9-851A-B493231FC5BF@oracle.com>
Message-ID: <A08399A2-C9CE-4175-9915-D3AC7FA586D5@oracle.com>

Hi Manajit,
Please review the following code changes.

With Regards,
Avik Niyogi
> On 21-Mar-2016, at 12:20 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi Rajeev,
> Please review the following code changes.
> 
> With Regards,
> Avik Niyogi
>> On 21-Mar-2016, at 12:17 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>> 
>> Hi Sergey,
>> 
>> Please review the following code changes.
>> With Regards,
>> Avik Niyogi
>>> On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>> 
>>> 
>>> The fix looks good to me.
>>> 
>>> Just a small note: it is better to remove comment "527         //" since it does not have a description.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 17/03/16 17:21, Avik Niyogi wrote:
>>>> It can be made into a class method, but herein this case it is needed for that instance only and hence the need for instance method and referred with ?self?.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>> 
>>>>> 
>>>>> Could the -(NSMutableString *) parseString: method be declared as class method instead of instance?
>>>>> 
>>>>> Thanks,
>>>>> Alexandr.
>>>>> 
>>>>> On 14/03/16 17:18, Sergey Bylokhov wrote:
>>>>>> Hi, Avik. 
>>>>>> Can you please take a look to these two tests before fixing this bug: 
>>>>>> 
>>>>>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
>>>>>> -------------------------------------------------- 
>>>>>> TEST: javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>>>>>> 
>>>>>> I remember they passed on jdk8, but it seems we have a regression in jdk9 and both of them fail. 
>>>>>> 
>>>>>> On 14.03.16 8:05, Avik Niyogi wrote: 
>>>>>>> Hi All, 
>>>>>>> A gentle reminder, please review my code changes. 
>>>>>>> 
>>>>>>> With Regards, 
>>>>>>> Avik Niyogi 
>>>>>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com> 
>>>>>>>> <mailto:avik.niyogi at oracle.com> <mailto:avik.niyogi at oracle.com>> wrote: 
>>>>>>>> 
>>>>>>>> Hi All, 
>>>>>>>> 
>>>>>>>> Kindly review the bug fix for JDK 9. 
>>>>>>>> 
>>>>>>>> *Bug:* 
>>>>>>>> 
>>>>>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_ <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
>>>>>>>> _ 
>>>>>>>> _ 
>>>>>>>> *Webrev:* 
>>>>>>>> 
>>>>>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ <http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_> 
>>>>>>>> 
>>>>>>>> *Issue:* 
>>>>>>>> Emoji selection in Character Viewer was causing exception in JNI 
>>>>>>>> 
>>>>>>>> *Cause:* 
>>>>>>>> Emojis are considered to be of different class type (namely, 
>>>>>>>> NSConcreteMutableAttributedString) from NSString which other 
>>>>>>>> characters are because of a surrogate pair for them. 
>>>>>>>> 
>>>>>>>> *Fix:* 
>>>>>>>> Major changes done for condition of emojis in JNI. Albeit rendering is 
>>>>>>>> not yet supported, they will appear as blank ?Missing font? notation. 
>>>>>>>> Also, added debug point in case of issue with glyph arrises. 
>>>>>>>> 
>>>>>>>> With Regards, 
>>>>>>>> Avik Niyogi 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/e7245964/attachment.html>

From rajeev.chamyal at oracle.com  Mon Mar 21 07:15:28 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Mon, 21 Mar 2016 00:15:28 -0700 (PDT)
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
 exception was raised entering Emoji into JTextArea
In-Reply-To: <6FB602D3-1A5D-49E9-851A-B493231FC5BF@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com> <56E9A536.6090903@oracle.com>
	<E98C9197-A1A0-4C20-825F-5C36818064F0@oracle.com>
	<56EAB22B.8010208@oracle.com>
	<6C1B06DD-6708-477F-A2AA-C384CCBE729C@oracle.com>
	<6FB602D3-1A5D-49E9-851A-B493231FC5BF@oracle.com>
Message-ID: <ecb3518f-a05c-427b-b132-c9373ab9e0ef@default>

Hello Avik,

?

I can?t comment on objective C code.

As far as test is concerned below are my comments.

?

1)????? UI should be created in Swing thread.

2)????? Switch case in ?actionPerformed should be refactored.

?

Regards,

Rajeev Chamyal

?

From: Avik Niyogi 
Sent: 21 March 2016 12:20
To: Sergey Bylokhov
Cc: swing-dev at openjdk.java.net; Alexander Scherbatiy; Rajeev Chamyal
Subject: Re: <Swing Dev> Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea

?

Hi Rajeev,

Please review the following code changes.

?

With Regards,

Avik Niyogi

On 21-Mar-2016, at 12:17 pm, Avik Niyogi <HYPERLINK "mailto:avik.niyogi at oracle.com"avik.niyogi at oracle.com> wrote:

?

Hi Sergey,

?

Please review the following code changes.

With Regards,

Avik Niyogi

On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

?


The fix looks good to me.

Just a small note: it is better to remove comment "527???????? //" since it does not have a description.

Thanks,
Alexandr.

On 17/03/16 17:21, Avik Niyogi wrote:

It can be made into a class method, but herein this case it is needed for that instance only and hence the need for instance method and referred with ?self?. 

?

With Regards,

Avik Niyogi

On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

?


Could the -(NSMutableString *) parseString: method be declared as class method instead of instance?

Thanks,
Alexandr.

On 14/03/16 17:18, Sergey Bylokhov wrote:

Hi, Avik. 
Can you please take a look to these two tests before fixing this bug: 

TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
-------------------------------------------------- 
TEST: javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java

I remember they passed on jdk8, but it seems we have a regression in jdk9 and both of them fail. 

On 14.03.16 8:05, Avik Niyogi wrote: 



Hi All, 
A gentle reminder, please review my code changes. 

With Regards, 
Avik Niyogi 



On 08-Mar-2016, at 9:39 pm, Avik Niyogi <HYPERLINK "mailto:avik.niyogi at oracle.com"avik.niyogi at oracle.com 
HYPERLINK "mailto:avik.niyogi at oracle.com"<mailto:avik.niyogi at oracle.com>> wrote: 

Hi All, 

Kindly review the bug fix for JDK 9. 

*Bug:* 

_https://bugs.openjdk.java.net/browse/JDK-8148555_ 
_ 
_ 
*Webrev:* 

_HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_"http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ 

*Issue:* 
Emoji selection in Character Viewer was causing exception in JNI 

*Cause:* 
Emojis are considered to be of different class type (namely, 
NSConcreteMutableAttributedString) from NSString which other 
characters are because of a surrogate pair for them. 

*Fix:* 
Major changes done for condition of emojis in JNI. Albeit rendering is 
not yet supported, they will appear as blank ?Missing font? notation. 
Also, added debug point in case of issue with glyph arrises. 

With Regards, 
Avik Niyogi 

?

?

?

?

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/45e6095f/attachment.html>

From prem.balakrishnan at oracle.com  Mon Mar 21 08:20:26 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Mon, 21 Mar 2016 01:20:26 -0700 (PDT)
Subject: <Swing Dev> Review Request for 6439354 : Win L&F: TitledBorder
 colors are not from desktop
Message-ID: <9dfecb85-567d-410c-b60a-9b8976521e55@default>

Hi,

Please review fix for JDK 9,

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

Webrev: http://cr.openjdk.java.net/~arapte/prem/6439354/webrev.00/

 

Issue:

Win L&F: TitledBorder colors are not from desktop

 

Cause:

"TitledBorder.border" is set to EtchedBorder with default highlight/shadow colors.

 

Fix:

"TitledBorder.border" is set to  EtchedBorder with Desktop  highlight/shadow colors.

 

Test: Manual Test (since windows theme to be set)

 

Regards,
Prem

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/57f96247/attachment.html>

From avik.niyogi at oracle.com  Mon Mar 21 08:31:34 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 21 Mar 2016 14:01:34 +0530
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
	exception was raised entering Emoji into JTextArea
In-Reply-To: <ecb3518f-a05c-427b-b132-c9373ab9e0ef@default>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com> <56E9A536.6090903@oracle.com>
	<E98C9197-A1A0-4C20-825F-5C36818064F0@oracle.com>
	<56EAB22B.8010208@oracle.com>
	<6C1B06DD-6708-477F-A2AA-C384CCBE729C@oracle.com>
	<6FB602D3-1A5D-49E9-851A-B493231FC5BF@oracle.com>
	<ecb3518f-a05c-427b-b132-c9373ab9e0ef@default>
Message-ID: <342FCF5C-274C-4325-9F61-748B2A974482@oracle.com>

Hi All,
Please review the below code changes as per the inputs received.
http://cr.openjdk.java.net/~aniyogi/8148555/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8148555/webrev.01/>


With Regards,
Avik Niyogi
> On 21-Mar-2016, at 12:45 pm, Rajeev Chamyal <rajeev.chamyal at oracle.com> wrote:
> 
> Hello Avik,
>  
> I can?t comment on objective C code.
> As far as test is concerned below are my comments.
>  
> 1)      UI should be created in Swing thread.
> 2)      Switch case in  actionPerformed should be refactored.
>  
> Regards,
> Rajeev Chamyal
>  
> From: Avik Niyogi 
> Sent: 21 March 2016 12:20
> To: Sergey Bylokhov
> Cc: swing-dev at openjdk.java.net; Alexander Scherbatiy; Rajeev Chamyal
> Subject: Re: <Swing Dev> Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea
>  
> Hi Rajeev,
> Please review the following code changes.
>  
> With Regards,
> Avik Niyogi
> On 21-Mar-2016, at 12:17 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>  
> Hi Sergey,
>  
> Please review the following code changes.
> With Regards,
> Avik Niyogi
> On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> 
> The fix looks good to me.
> 
> Just a small note: it is better to remove comment "527         //" since it does not have a description.
> 
> Thanks,
> Alexandr.
> 
> On 17/03/16 17:21, Avik Niyogi wrote:
> It can be made into a class method, but herein this case it is needed for that instance only and hence the need for instance method and referred with ?self?. 
>  
> With Regards,
> Avik Niyogi
> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> 
> Could the -(NSMutableString *) parseString: method be declared as class method instead of instance?
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 17:18, Sergey Bylokhov wrote:
> Hi, Avik. 
> Can you please take a look to these two tests before fixing this bug: 
> 
> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
> -------------------------------------------------- 
> TEST: javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
> 
> I remember they passed on jdk8, but it seems we have a regression in jdk9 and both of them fail. 
> 
> On 14.03.16 8:05, Avik Niyogi wrote: 
> 
> Hi All, 
> A gentle reminder, please review my code changes. 
> 
> With Regards, 
> Avik Niyogi 
> 
> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com> 
> <mailto:avik.niyogi at oracle.com> <mailto:avik.niyogi at oracle.com>> wrote: 
> 
> Hi All, 
> 
> Kindly review the bug fix for JDK 9. 
> 
> *Bug:* 
> 
> _https://bugs.openjdk.java.net/browse/JDK-8148555_ <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
> _ 
> _ 
> *Webrev:* 
> 
> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ <http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_> 
> 
> *Issue:* 
> Emoji selection in Character Viewer was causing exception in JNI 
> 
> *Cause:* 
> Emojis are considered to be of different class type (namely, 
> NSConcreteMutableAttributedString) from NSString which other 
> characters are because of a surrogate pair for them. 
> 
> *Fix:* 
> Major changes done for condition of emojis in JNI. Albeit rendering is 
> not yet supported, they will appear as blank ?Missing font? notation. 
> Also, added debug point in case of issue with glyph arrises. 
> 
> With Regards, 
> Avik Niyogi 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/4d1ba414/attachment.html>

From rajeev.chamyal at oracle.com  Mon Mar 21 10:46:09 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Mon, 21 Mar 2016 03:46:09 -0700 (PDT)
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
 exception was raised entering Emoji into JTextArea
In-Reply-To: <342FCF5C-274C-4325-9F61-748B2A974482@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com> <56E9A536.6090903@oracle.com>
	<E98C9197-A1A0-4C20-825F-5C36818064F0@oracle.com>
	<56EAB22B.8010208@oracle.com>
	<6C1B06DD-6708-477F-A2AA-C384CCBE729C@oracle.com>
	<6FB602D3-1A5D-49E9-851A-B493231FC5BF@oracle.com>
	<ecb3518f-a05c-427b-b132-c9373ab9e0ef@default>
	<342FCF5C-274C-4325-9F61-748B2A974482@oracle.com>
Message-ID: <21b73baf-da3b-4dae-88d1-cad913d99830@default>

Test code looks good to me.

?

Regards,

Rajeev Chamyal

?

From: Avik Niyogi 
Sent: 21 March 2016 14:02
To: Manajit Halder; Alexander Scherbatiy
Cc: swing-dev at openjdk.java.net; Rajeev Chamyal
Subject: Re: <Swing Dev> Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea

?

Hi All,

Please review the below code changes as per the inputs received.

http://cr.openjdk.java.net/~aniyogi/8148555/webrev.01/

?

?

With Regards,

Avik Niyogi

On 21-Mar-2016, at 12:45 pm, Rajeev Chamyal <HYPERLINK "mailto:rajeev.chamyal at oracle.com"rajeev.chamyal at oracle.com> wrote:

?

Hello Avik,

?

I can?t comment on objective C code.

As far as test is concerned below are my comments.

?

1)??????UI should be created in Swing thread.

2)??????Switch case in ?actionPerformed should be refactored.

?

Regards,

Rajeev Chamyal

?

From:?Avik Niyogi?
Sent:?21 March 2016 12:20
To:?Sergey Bylokhov
Cc:?HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Alexander Scherbatiy; Rajeev Chamyal
Subject:?Re: <Swing Dev> Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea

?

Hi Rajeev,

Please review the following code changes.

?

With Regards,

Avik Niyogi

On 21-Mar-2016, at 12:17 pm, Avik Niyogi <HYPERLINK "mailto:avik.niyogi at oracle.com"avik.niyogi at oracle.com> wrote:

?

Hi Sergey,

?

Please review the following code changes.

With Regards,

Avik Niyogi

On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

?


The fix looks good to me.

Just a small note: it is better to remove comment "527???????? //" since it does not have a description.

Thanks,
Alexandr.

On 17/03/16 17:21, Avik Niyogi wrote:

It can be made into a class method, but herein this case it is needed for that instance only and hence the need for instance method and referred with ?self?.?

?

With Regards,

Avik Niyogi

On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

?


Could the -(NSMutableString *) parseString: method be declared as class method instead of instance?

Thanks,
Alexandr.

On 14/03/16 17:18, Sergey Bylokhov wrote:

Hi, Avik.?
Can you please take a look to these two tests before fixing this bug:?

TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java?
--------------------------------------------------?
TEST: javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java

I remember they passed on jdk8, but it seems we have a regression in jdk9 and both of them fail.?

On 14.03.16 8:05, Avik Niyogi wrote:?




Hi All,?
A gentle reminder, please review my code changes.?

With Regards,?
Avik Niyogi?




On 08-Mar-2016, at 9:39 pm, Avik Niyogi <HYPERLINK "mailto:avik.niyogi at oracle.com"avik.niyogi at oracle.com?
HYPERLINK "mailto:avik.niyogi at oracle.com"<mailto:avik.niyogi at oracle.com>> wrote:?

Hi All,?

Kindly review the bug fix for JDK 9.?

*Bug:*?

_https://bugs.openjdk.java.net/browse/JDK-8148555_?
_?
_?
*Webrev:*?

_HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_"http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_?

*Issue:*?
Emoji selection in Character Viewer was causing exception in JNI?

*Cause:*?
Emojis are considered to be of different class type (namely,?
NSConcreteMutableAttributedString) from NSString which other?
characters are because of a surrogate pair for them.?

*Fix:*?
Major changes done for condition of emojis in JNI. Albeit rendering is?
not yet supported, they will appear as blank ?Missing font? notation.?
Also, added debug point in case of issue with glyph arrises.?

With Regards,?
Avik Niyogi?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/b2759acb/attachment.html>

From manajit.halder at oracle.com  Mon Mar 21 10:52:03 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 21 Mar 2016 16:22:03 +0530
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
	exception was raised entering Emoji into JTextArea
In-Reply-To: <21b73baf-da3b-4dae-88d1-cad913d99830@default>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com> <56E9A536.6090903@oracle.com>
	<E98C9197-A1A0-4C20-825F-5C36818064F0@oracle.com>
	<56EAB22B.8010208@oracle.com>
	<6C1B06DD-6708-477F-A2AA-C384CCBE729C@oracle.com>
	<6FB602D3-1A5D-49E9-851A-B493231FC5BF@oracle.com>
	<ecb3518f-a05c-427b-b132-c9373ab9e0ef@default>
	<342FCF5C-274C-4325-9F61-748B2A974482@oracle.com>
	<21b73baf-da3b-4dae-88d1-cad913d99830@default>
Message-ID: <5483AC96-53AB-4CF4-8B17-ED00BEDB0D04@oracle.com>

Hi Avik,

Changes looks good to me.

Regards,
Manajit

> On 21-Mar-2016, at 4:16 pm, Rajeev Chamyal <rajeev.chamyal at oracle.com> wrote:
> 
> Test code looks good to me.
>  
> Regards,
> Rajeev Chamyal
>  
> From: Avik Niyogi 
> Sent: 21 March 2016 14:02
> To: Manajit Halder; Alexander Scherbatiy
> Cc: swing-dev at openjdk.java.net; Rajeev Chamyal
> Subject: Re: <Swing Dev> Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea
>  
> Hi All,
> Please review the below code changes as per the inputs received.
> http://cr.openjdk.java.net/~aniyogi/8148555/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8148555/webrev.01/>
>  
>  
> With Regards,
> Avik Niyogi
> On 21-Mar-2016, at 12:45 pm, Rajeev Chamyal <rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com>> wrote:
>  
> Hello Avik,
>  
> I can?t comment on objective C code.
> As far as test is concerned below are my comments.
>  
> 1)      UI should be created in Swing thread.
> 2)      Switch case in  actionPerformed should be refactored.
>  
> Regards,
> Rajeev Chamyal
>  
> From: Avik Niyogi 
> Sent: 21 March 2016 12:20
> To: Sergey Bylokhov
> Cc: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>; Alexander Scherbatiy; Rajeev Chamyal
> Subject: Re: <Swing Dev> Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea
>  
> Hi Rajeev,
> Please review the following code changes.
>  
> With Regards,
> Avik Niyogi
> On 21-Mar-2016, at 12:17 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>  
> Hi Sergey,
>  
> Please review the following code changes.
> With Regards,
> Avik Niyogi
> On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> 
> The fix looks good to me.
> 
> Just a small note: it is better to remove comment "527         //" since it does not have a description.
> 
> Thanks,
> Alexandr.
> 
> On 17/03/16 17:21, Avik Niyogi wrote:
> It can be made into a class method, but herein this case it is needed for that instance only and hence the need for instance method and referred with ?self?. 
>  
> With Regards,
> Avik Niyogi
> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> 
> Could the -(NSMutableString *) parseString: method be declared as class method instead of instance?
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 17:18, Sergey Bylokhov wrote:
> Hi, Avik. 
> Can you please take a look to these two tests before fixing this bug: 
> 
> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
> -------------------------------------------------- 
> TEST: javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
> 
> I remember they passed on jdk8, but it seems we have a regression in jdk9 and both of them fail. 
> 
> On 14.03.16 8:05, Avik Niyogi wrote: 
> 
> 
> Hi All, 
> A gentle reminder, please review my code changes. 
> 
> With Regards, 
> Avik Niyogi 
> 
> 
> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com> 
> <mailto:avik.niyogi at oracle.com> <mailto:avik.niyogi at oracle.com>> wrote: 
> 
> Hi All, 
> 
> Kindly review the bug fix for JDK 9. 
> 
> *Bug:* 
> 
> _https://bugs.openjdk.java.net/browse/JDK-8148555_ <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
> _ 
> _ 
> *Webrev:* 
> 
> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ <http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_> 
> 
> *Issue:* 
> Emoji selection in Character Viewer was causing exception in JNI 
> 
> *Cause:* 
> Emojis are considered to be of different class type (namely, 
> NSConcreteMutableAttributedString) from NSString which other 
> characters are because of a surrogate pair for them. 
> 
> *Fix:* 
> Major changes done for condition of emojis in JNI. Albeit rendering is 
> not yet supported, they will appear as blank ?Missing font? notation. 
> Also, added debug point in case of issue with glyph arrises. 
> 
> With Regards, 
> Avik Niyogi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/f6ad8177/attachment.html>

From semyon.sadetsky at oracle.com  Mon Mar 21 13:26:29 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 21 Mar 2016 16:26:29 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56ED7507.1090204@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
Message-ID: <56EFF685.1090702@oracle.com>



On 3/19/2016 6:49 PM, Sergey Bylokhov wrote:
> On 18.03.16 15:37, Semyon Sadetsky wrote:
>> On 3/17/2016 2:46 PM, Sergey Bylokhov wrote:
>>> Small notes:
>>>  - It will be good to move the code which reads the system properties
>>> to the static init block, otherwise we can be in trouble if these
>>> properties will be changed at runtime.
>> I don't' see any troubles with this. Can you describe the scenario you
>> meant?
>> I think the properties changing at run-time is useful because it gives
>> better control over GTK load. For example, developer may change the
>> order to GTK3->GTK2.
>
> Yes the users can change the property at the beginning of the program 
> or via command line, but it is not good thing to allow to change it 
> after unix toolkit is loaded. For example isNativeGTKAvailable() can 
> check one version of the library, and loadGTK() can try to load 
> another version, because getEnabledGtkVersion() will return different 
> values. It belongs to all places where getEnabledGtkVersion() is used.
This is the only suspicious scenario but it is unlikely possible. 
isNativeGTKAvailable() and initialize() are called in the same 
setLookAndFeel() method. I doubt that somebody will find it sensible to 
change the jdk.gtk.version concurrently with the setLookAndFeel() call.
Even if this happens and GTK becames unavailable the initialize() will 
throw the same UnsupportedLookAndFeelException exception as in 
isNativeGTKAvailable() check, so the behavior will correspond to the 
specification.
>
>>>  - Is it necessary to use ordinal? can we replace it with some
>>> specific data?(the same for the indexed access in .values()[..])
>> In general I'm good. But what specific data you propose?
>
> And javadoc for ordinal:
> "Most programmers will have no use for this method. It is designed for 
> use by sophisticated enum-based data structures, such as EnumSet and 
> EnumMap."
>
> Quote from the internet:
> "This is not recommended to use ordinal() (Effective Java, Item 31) as 
> it relies on the order of the enum values in client's code determine 
> the ordinal, and any change could lead to bad values being mapped.
>
> Instead, it would be better to have users implement a method that 
> would return a unique ID for an enum value. For instance, with an 
> Identifiable interface that has a unique method id(), that the user 
> would have to implement for every enum value."
>
These are related to user's code.
In JDK internal code there are plenty usages of ordinal(). In this 
specific case it is only necessary for transferring the value to the 
internal native code. But the API never returns ordinal values to user.

--Semyon
>>
>> --Semyon
>>>
>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>> Hi Phil,
>>>>
>>>> Thank for review. You will find my reply below in the text.
>>>>
>>>> The updated webrev is
>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>> It also contains:
>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more 
>>>> but we
>>>> can do this later as a separate bug.
>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>>>> appearance changes.
>>>>
>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>> There is a lot to read here. I think I need to patch and try it but
>>>>> first ...
>>>>>
>>>>> Two high level questions :
>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>>> yet a dependency on GTK and its dependency on xlibraries seems to 
>>>>> mean
>>>>> that you can't load GTK in this case.
>>>>> BTW I think it may be painful to get them to layout in such a case
>>>>> but that's another issue.
>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>
>>>>> 2) Have you tried a hi-dpi system ?
>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>
>>>>> 3) Have you submitted a JPRT job ? It is essential to know that this
>>>>> builds cleanly on the "official" compilation environment.
>>>> I will do this before the push. I think it will be OK because I did 
>>>> not
>>>> use any new C constructs and the new libraries are linked dynamically.
>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>>> regression test suite ?
>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
>>>> With GTK3 the result was the same except for some unstable tests. 
>>>> Unity
>>>> desktop has new window decorations like borderless windows which are
>>>> resized by dragging the outer window shadow, invisible overlay
>>>> scrollbars, etc. Many tests written for old window decorations fails.
>>>>>
>>>>> Minor comments :
>>>>>
>>>>> GTKEngine.java
>>>>>
>>>>>  494         Container parent = context.getComponent().getParent();
>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>  496             if (parent != null && parent.getParent() instanceof
>>>>> JComboBox) {
>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>  499                 }
>>>>>  500             }
>>>>>  501         }
>>>>>
>>>>> GTKPainter.java
>>>>>
>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>>>  748                 y += 1;
>>>>>  749                 h -= 2;
>>>>>  750             } else {
>>>>>  751                 x += 1;
>>>>>  752                 w -= 2;
>>>>>  753             }
>>>>>  754         }
>>>>>
>>>>> I don't know where these numbers come from or what coordinate system
>>>>> is being used here but it seems you are changing them for gtk 2.2 as
>>>>> well as 3
>>>>> Can you speak to this ?
>>>> It is an appearance tuning for GTK3. I didn't change it for GTK2, 
>>>> why do
>>>> you think so?
>>>> This was used before my fix as well, for example
>>>>
>>>>                      if (containerParent instanceof JComboBox) {
>>>>                          x += (focusSize + 2);
>>>>                          y += (focusSize + 1);
>>>>                          w -= (2 * focusSize + 1);
>>>>                          h -= (2 * focusSize + 2);
>>>>                      } else {
>>>>                          x += focusSize;
>>>>                          y += focusSize;
>>>>                          w -= 2 * focusSize;
>>>>                          h -= 2 * focusSize;
>>>>                      }
>>>>
>>>> The only place where I changed the existing GTK2 appearance is:
>>>>
>>>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth",
>>>> "slider-length");
>>>>
>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>
>>>>> GTKStyle.java
>>>>>
>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>
>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>
>>>>>
>>>>> we prefer a space between "if" and "("
>>>> Accepted.
>>>>>
>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>
>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>
>>>>>
>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>> char*. NULL means that the version is compatible.
>>>>>
>>>>>  393
>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>>>>  394                 dialog), TRUE);
>>>>>
>>>>>
>>>>> You didn't add this but it is awfully specific about the GTK version
>>>>> and
>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>> Accepted.
>>>>>
>>>>> It is interesting that some equivalent looking Java level dialog
>>>>> checking in XToolkit.java
>>>>> checked for 3.0 too ..
>>>>>
>>>>> swing_GTKEngine.c :
>>>>>
>>>>>   30 /* Static buffer for conversion from java.lang.String to 
>>>>> UTF-8 */
>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>
>>>>> So the variable name should be spelt conversionBuffer.
>>>> Accepted.
>>>>>
>>>>> awt_UNIXToolkit.c
>>>>>
>>>>> < 287 free(ret);
>>>>>
>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>> you now expect a boolean return as discussed above and
>>>>> so in that case NULL looks odd here (line 260) too.
>>>> The JNI exported method returns boolean while the GTK method returns
>>>> char*. free() is deleted intentionally according to the GTK docs it
>>>> belongs to the library and should not be freed by user code.
>>>>>
>>>>> gtk3_interface.h :
>>>>>
>>>>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>>>>
>>>>> I don't think that is completely accurate :-) And I should have
>>>>> reviewed this yesterday [1].
>>>> :) This is glib's definition I just copied.
>>>>
>>>> --Semyon
>>>>>
>>>>> -phil.
>>>>>
>>>>> [1] http://www.piday.org/
>>>>>
>>>>>
>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK9:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>
>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>> Also the new system property is added to request specific GTK 
>>>>>> version
>>>>>> swing.gtk.version.
>>>>>>
>>>>>> --Semyon
>>>>>
>>>>
>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/fc565fe4/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Mar 21 13:52:10 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 16:52:10 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56EFF685.1090702@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
	<56EFF685.1090702@oracle.com>
Message-ID: <56EFFC8A.1010306@oracle.com>

On 21.03.16 16:26, Semyon Sadetsky wrote:
>
>
> On 3/19/2016 6:49 PM, Sergey Bylokhov wrote:
>> On 18.03.16 15:37, Semyon Sadetsky wrote:
>>> On 3/17/2016 2:46 PM, Sergey Bylokhov wrote:
>>>> Small notes:
>>>>  - It will be good to move the code which reads the system properties
>>>> to the static init block, otherwise we can be in trouble if these
>>>> properties will be changed at runtime.
>>> I don't' see any troubles with this. Can you describe the scenario you
>>> meant?
>>> I think the properties changing at run-time is useful because it gives
>>> better control over GTK load. For example, developer may change the
>>> order to GTK3->GTK2.
>>
>> Yes the users can change the property at the beginning of the program
>> or via command line, but it is not good thing to allow to change it
>> after unix toolkit is loaded. For example isNativeGTKAvailable() can
>> check one version of the library, and loadGTK() can try to load
>> another version, because getEnabledGtkVersion() will return different
>> values. It belongs to all places where getEnabledGtkVersion() is used.
> This is the only suspicious scenario but it is unlikely possible.
> isNativeGTKAvailable() and initialize() are called in the same
> setLookAndFeel() method. I doubt that somebody will find it sensible to
> change the jdk.gtk.version concurrently with the setLookAndFeel() call.
> Even if this happens and GTK becames unavailable the initialize() will
> throw the same UnsupportedLookAndFeelException exception as in
> isNativeGTKAvailable() check, so the behavior will correspond to the
> specification.

But for example getEnabledGtkVersion() is called in the 
XDesktopPeer.java also. Note that XDesktopPeer and UnixToolkit 
synchronized differently but but tries to init gtk. It will be safer to 
remove this possible missconfiguration.

>>
>>>>  - Is it necessary to use ordinal? can we replace it with some
>>>> specific data?(the same for the indexed access in .values()[..])
>>> In general I'm good. But what specific data you propose?
>>
>> And javadoc for ordinal:
>> "Most programmers will have no use for this method. It is designed for
>> use by sophisticated enum-based data structures, such as EnumSet and
>> EnumMap."
>>
>> Quote from the internet:
>> "This is not recommended to use ordinal() (Effective Java, Item 31) as
>> it relies on the order of the enum values in client's code determine
>> the ordinal, and any change could lead to bad values being mapped.
>>
>> Instead, it would be better to have users implement a method that
>> would return a unique ID for an enum value. For instance, with an
>> Identifiable interface that has a unique method id(), that the user
>> would have to implement for every enum value."
>>
> These are related to user's code.
> In JDK internal code there are plenty usages of ordinal(). In this
> specific case it is only necessary for transferring the value to the
> internal native code. But the API never returns ordinal values to user.

Transferring such unstable data to the native is more dangerous than to 
the user.

>
> --Semyon
>>>
>>> --Semyon
>>>>
>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>> Hi Phil,
>>>>>
>>>>> Thank for review. You will find my reply below in the text.
>>>>>
>>>>> The updated webrev is
>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>> It also contains:
>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more
>>>>> but we
>>>>> can do this later as a separate bug.
>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>>>>> appearance changes.
>>>>>
>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>> There is a lot to read here. I think I need to patch and try it but
>>>>>> first ...
>>>>>>
>>>>>> Two high level questions :
>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>>>> yet a dependency on GTK and its dependency on xlibraries seems to
>>>>>> mean
>>>>>> that you can't load GTK in this case.
>>>>>> BTW I think it may be painful to get them to layout in such a case
>>>>>> but that's another issue.
>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>
>>>>>> 2) Have you tried a hi-dpi system ?
>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>
>>>>>> 3) Have you submitted a JPRT job ? It is essential to know that this
>>>>>> builds cleanly on the "official" compilation environment.
>>>>> I will do this before the push. I think it will be OK because I did
>>>>> not
>>>>> use any new C constructs and the new libraries are linked dynamically.
>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>>>> regression test suite ?
>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as well.
>>>>> With GTK3 the result was the same except for some unstable tests.
>>>>> Unity
>>>>> desktop has new window decorations like borderless windows which are
>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>> scrollbars, etc. Many tests written for old window decorations fails.
>>>>>>
>>>>>> Minor comments :
>>>>>>
>>>>>> GTKEngine.java
>>>>>>
>>>>>>  494         Container parent = context.getComponent().getParent();
>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>  496             if (parent != null && parent.getParent() instanceof
>>>>>> JComboBox) {
>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>  499                 }
>>>>>>  500             }
>>>>>>  501         }
>>>>>>
>>>>>> GTKPainter.java
>>>>>>
>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>>>>  748                 y += 1;
>>>>>>  749                 h -= 2;
>>>>>>  750             } else {
>>>>>>  751                 x += 1;
>>>>>>  752                 w -= 2;
>>>>>>  753             }
>>>>>>  754         }
>>>>>>
>>>>>> I don't know where these numbers come from or what coordinate system
>>>>>> is being used here but it seems you are changing them for gtk 2.2 as
>>>>>> well as 3
>>>>>> Can you speak to this ?
>>>>> It is an appearance tuning for GTK3. I didn't change it for GTK2,
>>>>> why do
>>>>> you think so?
>>>>> This was used before my fix as well, for example
>>>>>
>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>                          x += (focusSize + 2);
>>>>>                          y += (focusSize + 1);
>>>>>                          w -= (2 * focusSize + 1);
>>>>>                          h -= (2 * focusSize + 2);
>>>>>                      } else {
>>>>>                          x += focusSize;
>>>>>                          y += focusSize;
>>>>>                          w -= 2 * focusSize;
>>>>>                          h -= 2 * focusSize;
>>>>>                      }
>>>>>
>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>
>>>>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth",
>>>>> "slider-length");
>>>>>
>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>
>>>>>> GTKStyle.java
>>>>>>
>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>
>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>
>>>>>>
>>>>>> we prefer a space between "if" and "("
>>>>> Accepted.
>>>>>>
>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>
>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>
>>>>>>
>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>> char*. NULL means that the version is compatible.
>>>>>>
>>>>>>  393
>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>>>>>  394                 dialog), TRUE);
>>>>>>
>>>>>>
>>>>>> You didn't add this but it is awfully specific about the GTK version
>>>>>> and
>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>> Accepted.
>>>>>>
>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>> checking in XToolkit.java
>>>>>> checked for 3.0 too ..
>>>>>>
>>>>>> swing_GTKEngine.c :
>>>>>>
>>>>>>   30 /* Static buffer for conversion from java.lang.String to
>>>>>> UTF-8 */
>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>
>>>>>> So the variable name should be spelt conversionBuffer.
>>>>> Accepted.
>>>>>>
>>>>>> awt_UNIXToolkit.c
>>>>>>
>>>>>> < 287 free(ret);
>>>>>>
>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>> you now expect a boolean return as discussed above and
>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>> The JNI exported method returns boolean while the GTK method returns
>>>>> char*. free() is deleted intentionally according to the GTK docs it
>>>>> belongs to the library and should not be freed by user code.
>>>>>>
>>>>>> gtk3_interface.h :
>>>>>>
>>>>>>   36 #define G_PI 3.1415926535897932384626433832795028841971693993751
>>>>>>
>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>> reviewed this yesterday [1].
>>>>> :) This is glib's definition I just copied.
>>>>>
>>>>> --Semyon
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> [1] http://www.piday.org/
>>>>>>
>>>>>>
>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review fix for JDK9:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>
>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>> Also the new system property is added to request specific GTK
>>>>>>> version
>>>>>>> swing.gtk.version.
>>>>>>>
>>>>>>> --Semyon
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Mar 21 13:54:04 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 16:54:04 +0300
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
 exception was raised entering Emoji into JTextArea
In-Reply-To: <56E6BA0A.10301@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com>
Message-ID: <56EFFCFC.5060102@oracle.com>

Please take a look to my comment below before pushing this fix.

On 14.03.16 16:18, Sergey Bylokhov wrote:
> Hi, Avik.
> Can you please take a look to these two tests before fixing this bug:
>
> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
> --------------------------------------------------
> TEST:
> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>
>
> I remember they passed on jdk8, but it seems we have a regression in
> jdk9 and both of them fail.
>
> On 14.03.16 8:05, Avik Niyogi wrote:
>> Hi All,
>> A gentle reminder, please review my code changes.
>>
>> With Regards,
>> Avik Niyogi
>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com
>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>
>>> Hi All,
>>>
>>> Kindly review the bug fix for JDK 9.
>>>
>>> *Bug:*
>>>
>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_
>>> _
>>> _
>>> *Webrev:*
>>>
>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_
>>>
>>> *Issue:*
>>> Emoji selection in Character Viewer was causing exception in JNI
>>>
>>> *Cause:*
>>> Emojis are considered to be of different class type (namely,
>>> NSConcreteMutableAttributedString) from NSString which other
>>> characters are because of a surrogate pair for them.
>>>
>>> *Fix:*
>>> Major changes done for condition of emojis in JNI. Albeit rendering is
>>> not yet supported, they will appear as blank ?Missing font? notation.
>>> Also, added debug point in case of issue with glyph arrises.
>>>
>>> With Regards,
>>> Avik Niyogi
>>
>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Mar 21 14:01:10 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 17:01:10 +0300
Subject: <Swing Dev> Review Request for 6439354 : Win L&F: TitledBorder
 colors are not from desktop
In-Reply-To: <9dfecb85-567d-410c-b60a-9b8976521e55@default>
References: <9dfecb85-567d-410c-b60a-9b8976521e55@default>
Message-ID: <56EFFEA6.7040408@oracle.com>

Hi, Prem.
In the test the Swing components accessed on non-EDT thread. Probably 
the test can be simplified further?

On 21.03.16 11:20, Prem Balakrishnan wrote:
> Hi*,*
>
> Please review fix for JDK 9,
>
> *Bug: *https://bugs.openjdk.java.net/browse/JDK-6439354 **
>
> *Webrev: *http://cr.openjdk.java.net/~arapte/prem/6439354/webrev.00/
>
> *Issue:*
>
> Win L&F: TitledBorder colors are not from desktop
>
> *Cause:*
>
> "TitledBorder.border" is set to EtchedBorder with default
> highlight/shadow colors.
>
> *Fix:*
>
> "TitledBorder.border" is set to  EtchedBorder with Desktop
>   highlight/shadow colors.
>
> **
>
> *Test: *Manual Test (since windows theme to be set)**
>
> **
>
> Regards,
> Prem
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Mar 21 14:02:10 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 17:02:10 +0300
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
 exception was raised entering Emoji into JTextArea
In-Reply-To: <510815E4-CD6E-4C40-ABC9-C39EEF224169@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com>
	<510815E4-CD6E-4C40-ABC9-C39EEF224169@oracle.com>
Message-ID: <56EFFEE2.6050801@oracle.com>

Looks fine then.

On 18.03.16 8:46, Avik Niyogi wrote:
> Hi Sergey,
> I have tested the test cases as mentioned.
> 1) They are not related to the current fix
> 2) ScreenMenuBarInputTwice.java issue is not reproducible.
> 3) There is a test bug in ActionListenerCalledTwiceTest.java, hence a
> new test case called ScreenMenuBarInputTwice.java
> was created to encompass actual expectations from Java on OS X as per
> native behaviour.
>
> Please review my current fix as available in the mail trail. Thank you
> in advance.
>
> With Regards,
> Avik Niyogi
>
>
>> On 14-Mar-2016, at 6:48 pm, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Avik.
>> Can you please take a look to these two tests before fixing this bug:
>>
>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
>> --------------------------------------------------
>> TEST:
>> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>>
>> I remember they passed on jdk8, but it seems we have a regression in
>> jdk9 and both of them fail.
>>
>> On 14.03.16 8:05, Avik Niyogi wrote:
>>> Hi All,
>>> A gentle reminder, please review my code changes.
>>>
>>> With Regards,
>>> Avik Niyogi
>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com
>>>> <mailto:avik.niyogi at oracle.com>
>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> Kindly review the bug fix for JDK 9.
>>>>
>>>> *Bug:*
>>>>
>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_
>>>> _
>>>> _
>>>> *Webrev:*
>>>>
>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_
>>>>
>>>> *Issue:*
>>>> Emoji selection in Character Viewer was causing exception in JNI
>>>>
>>>> *Cause:*
>>>> Emojis are considered to be of different class type (namely,
>>>> NSConcreteMutableAttributedString) from NSString which other
>>>> characters are because of a surrogate pair for them.
>>>>
>>>> *Fix:*
>>>> Major changes done for condition of emojis in JNI. Albeit rendering is
>>>> not yet supported, they will appear as blank ?Missing font? notation.
>>>> Also, added debug point in case of issue with glyph arrises.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Mon Mar 21 14:08:53 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 21 Mar 2016 18:08:53 +0400
Subject: <Swing Dev> Review Request of 8148555: [macosx] An uncaught
 exception was raised entering Emoji into JTextArea
In-Reply-To: <56EFFEE2.6050801@oracle.com>
References: <55E80A1D-BDFB-4023-A493-68BAFBF50305@oracle.com>
	<0CF72FCE-8CBA-449B-B67C-1122CC00AADF@oracle.com>
	<56E6BA0A.10301@oracle.com>
	<510815E4-CD6E-4C40-ABC9-C39EEF224169@oracle.com>
	<56EFFEE2.6050801@oracle.com>
Message-ID: <56F00075.2080900@oracle.com>


   The fix looks good to me.

  Thanks,
  Alexandr.

On 21/03/16 18:02, Sergey Bylokhov wrote:
> Looks fine then.
>
> On 18.03.16 8:46, Avik Niyogi wrote:
>> Hi Sergey,
>> I have tested the test cases as mentioned.
>> 1) They are not related to the current fix
>> 2) ScreenMenuBarInputTwice.java issue is not reproducible.
>> 3) There is a test bug in ActionListenerCalledTwiceTest.java, hence a
>> new test case called ScreenMenuBarInputTwice.java
>> was created to encompass actual expectations from Java on OS X as per
>> native behaviour.
>>
>> Please review my current fix as available in the mail trail. Thank you
>> in advance.
>>
>> With Regards,
>> Avik Niyogi
>>
>>
>>> On 14-Mar-2016, at 6:48 pm, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>
>>> Hi, Avik.
>>> Can you please take a look to these two tests before fixing this bug:
>>>
>>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
>>> --------------------------------------------------
>>> TEST:
>>> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java 
>>>
>>>
>>> I remember they passed on jdk8, but it seems we have a regression in
>>> jdk9 and both of them fail.
>>>
>>> On 14.03.16 8:05, Avik Niyogi wrote:
>>>> Hi All,
>>>> A gentle reminder, please review my code changes.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niyogi at oracle.com
>>>>> <mailto:avik.niyogi at oracle.com>
>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Kindly review the bug fix for JDK 9.
>>>>>
>>>>> *Bug:*
>>>>>
>>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_
>>>>> _
>>>>> _
>>>>> *Webrev:*
>>>>>
>>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_
>>>>>
>>>>> *Issue:*
>>>>> Emoji selection in Character Viewer was causing exception in JNI
>>>>>
>>>>> *Cause:*
>>>>> Emojis are considered to be of different class type (namely,
>>>>> NSConcreteMutableAttributedString) from NSString which other
>>>>> characters are because of a surrogate pair for them.
>>>>>
>>>>> *Fix:*
>>>>> Major changes done for condition of emojis in JNI. Albeit 
>>>>> rendering is
>>>>> not yet supported, they will appear as blank ?Missing font? notation.
>>>>> Also, added debug point in case of issue with glyph arrises.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>



From Sergey.Bylokhov at oracle.com  Mon Mar 21 14:35:38 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 17:35:38 +0300
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <D72D2B05-D686-4BDE-961D-008BA426B0DD@oracle.com>
References: <EB8A0826-B75D-4FB7-8BF0-41C1E7C40CBA@oracle.com>
	<56938303.8050907@oracle.com>
	<DAD2ACAB-5640-40E4-89B2-B1256EB53A5B@oracle.com>
	<569543A5.7040109@oracle.com>
	<B2381901-6398-4C69-8077-1144175E461C@oracle.com>
	<569651D3.4080604@oracle.com>
	<A14D4B21-B5D3-4A08-BDB8-0956008BF208@oracle.com>
	<56976EF0.5080204@oracle.com>
	<2A741D47-D5A4-41F6-B57B-EE98B84685F5@oracle.com>
	<5697DA64.40501@oracle.com>
	<9FC2C3E2-1118-4F40-9A31-C1B01C0FF94D@oracle.com>
	<4A7B5E21-686C-45B4-8821-4F0D2CEA2E42@oracle.com>
	<569E56DC.10908@oracle.com>
	<5FBB51B9-1C62-47D0-AAC7-35849350EA21@oracle.com>
	<52e60872-c7cb-4b04-b257-24d6b975ba22@default>
	<33152751-3DA9-40FB-9900-FA204D16DAF6@oracle.com>
	<a0f24f2d-5634-4365-95fb-bf07d440fb75@default>
	<569F68DD.3010705@oracle.com>
	<6398FB4E-663B-4DC6-97CE-19A0BB3574D4@oracle.com>
	<28266B2D-3427-4938-BC7D-9C62E1E43BC4@oracle.com>
	<A53CB1FD-28A4-4B22-BDF9-2268A122C764@oracle.com>
	<56ED367E.3050903@oracle.com>
	<D72D2B05-D686-4BDE-961D-008BA426B0DD@oracle.com>
Message-ID: <56F006BA.8000007@oracle.com>

On 21.03.16 8:12, Avik Niyogi wrote:
> Hi Sergey,
> https://bugs.openjdk.java.net/browse/JDK-8151282 is open and in progress.

How the this test(JProgressBarOrientationRobotTest) is related to 
JDK-8151282?

> With Regards,
> Avik Niyogi
>
>> On 19-Mar-2016, at 4:52 pm, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> I guess you need a separate CR for this, because JDK-8015748 was
>> closed already.
>>
>> On 21.01.16 6:49, Avik Niyogi wrote:
>>> Hi All,
>>> Please review my code change with inputs received:
>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/
>>> With Regards,
>>> Avik Niyogi
>>>
>>>> On 21-Jan-2016, at 8:30 am, Avik Niyogi <avik.niyogi at oracle.com
>>>> <mailto:avik.niyogi at oracle.com>
>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>
>>>> Hi Sergey,
>>>> The JTreg will pass, but the errors are posted to the log and not as
>>>> an interrupt as it would prematurely terminate execution of entire
>>>> test case for other look and feels if done so.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>
>>>>> On 21-Jan-2016, at 8:26 am, Avik Niyogi <avik.niyogi at oracle.com
>>>>> <mailto:avik.niyogi at oracle.com>
>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>
>>>>> Hi Sergey,
>>>>> This is the *log* of the test *JProgressBarOrientationRobotTest.java*
>>>>> after doing a *make java.desktop* after commenting out my code
>>>>> changes in *AquaProgressBarUI.java* :
>>>>>
>>>>> run:
>>>>> [Metal]: LTR orientation test passed
>>>>> [Metal]: RTL orientation test passed
>>>>> [Nimbus]: LTR orientation test passed
>>>>> [Nimbus]: RTL orientation test passed
>>>>> [CDE/Motif]: LTR orientation test passed
>>>>> [CDE/Motif]: RTL orientation test passed
>>>>> [Mac OS X]: LTR orientation test passed
>>>>> [Mac OS X]: [Error]: LTR orientation test failed
>>>>> [Mac OS X]: [Error]: LTR orientation test failed
>>>>> BUILD SUCCESSFUL (total time: 31 seconds)
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>
>>>>>> On 20-Jan-2016, at 4:30 pm, Alexander Scherbatiy
>>>>>> <alexandr.scherbatiy at oracle.com
>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>>
>>>>>>
>>>>>> The fix looks good to me.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>>>>>>>
>>>>>>> Looks good to me.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Rajeev Chamyal
>>>>>>>
>>>>>>> *From:*Avik Niyogi
>>>>>>> *Sent:* 20 January 2016 12:23
>>>>>>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>>>>>>> *Cc:*swing-dev at openjdk.java.net
>>>>>>> <mailto:swing-dev at openjdk.java.net><mailto:swing-dev at openjdk.java.net>
>>>>>>> *Subject:* Re: <Swing Dev> Review request for 8015748: JProgressbar
>>>>>>> with Aqua LaF ignores
>>>>>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>>>> call
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review the code changes made as with inputs for the webrev:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/>
>>>>>>>
>>>>>>> With Regards,
>>>>>>>
>>>>>>> Avik Niyogi
>>>>>>>
>>>>>>>   On 20-Jan-2016, at 10:40 am, Rajeev Chamyal
>>>>>>>   <rajeev.chamyal at oracle.com
>>>>>>> <mailto:rajeev.chamyal at oracle.com><mailto:rajeev.chamyal at oracle.com>
>>>>>>> <mailto:rajeev.chamyal at oracle.com>> wrote:
>>>>>>>
>>>>>>>   Hello Avik,
>>>>>>>
>>>>>>>   All exception caught during test should mark the test as failed.
>>>>>>>   For example not able to set any LAF should also be considered as
>>>>>>>   test failure.
>>>>>>>
>>>>>>>   Regards,
>>>>>>>
>>>>>>>   Rajeev Chamyal
>>>>>>>
>>>>>>>   *From:*Avik Niyogi
>>>>>>>   *Sent:*20 January 2016 10:20
>>>>>>>   *To:*Rajeev Chamyal
>>>>>>>   *Cc:*Alexander Scherbatiy; Sergey Bylokhov
>>>>>>>   *Subject:*Re: <Swing Dev> Review request for 8015748: JProgressbar
>>>>>>>   with Aqua LaF ignores
>>>>>>>   JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>>>>   call
>>>>>>>
>>>>>>>   Hi Rajeev and Sergey,
>>>>>>>
>>>>>>>   A gentle reminder. Kindly request to complete the pending review
>>>>>>>   of my code changes in the webrev:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/
>>>>>>>   <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>>>>>>>
>>>>>>>   Thank you in advance.
>>>>>>>
>>>>>>>   With Regards,
>>>>>>>
>>>>>>>   Avik Niyogi
>>>>>>>
>>>>>>>       On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy
>>>>>>>       <alexandr.scherbatiy at oracle.com
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>       <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>        The fix looks good to me.
>>>>>>>
>>>>>>>        Thanks,
>>>>>>>        Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>       On 19/01/16 15:27, Avik Niyogi wrote:
>>>>>>>
>>>>>>>           Hi All,
>>>>>>>
>>>>>>>           A gentle reminder. Please review my code changes as
>>>>>>>           mentioned in the webrev below as available in the link in
>>>>>>>           the mail trail.
>>>>>>>
>>>>>>>           With Regards,
>>>>>>>
>>>>>>>           Avik Niyogi
>>>>>>>
>>>>>>>               On 18-Jan-2016, at 11:34 am, Avik Niyogi
>>>>>>>               <avik.niyogi at oracle.com
>>>>>>> <mailto:avik.niyogi at oracle.com><mailto:avik.niyogi at oracle.com>
>>>>>>>               <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>>
>>>>>>>               Hi All, Please find the changes as provided with
>>>>>>>               incorporation of inputs:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/
>>>>>>>               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>>>>>>>
>>>>>>>               With Regards,
>>>>>>>
>>>>>>>               Avik Niyogi
>>>>>>>
>>>>>>>                   On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov
>>>>>>>                   <Sergey.Bylokhov at oracle.com
>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>>                   <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>>>
>>>>>>>                   Probably I missed something but why we need two
>>>>>>>                   tests? Note that the manual test is not marked as
>>>>>>>                   manual, which means that it will be run during the
>>>>>>>                   regular run?(even if -a option is provided to
>>>>>>>                   jtreg). Please check your other review requests
>>>>>>>                   for this issue.
>>>>>>>
>>>>>>>                   moreover on my system
>>>>>>>                   JProgressBarOrientationManualTest.java simply
>>>>>>>                   passed, and JProgressBarOrientationRobotTest.java
>>>>>>>                   failed even after the fix. Please recheck.
>>>>>>>
>>>>>>>                   On 14/01/16 13:11, Avik Niyogi wrote:
>>>>>>>
>>>>>>>
>>>>>>>                       Hi All,
>>>>>>>                       Please find the changes as provided with
>>>>>>>                       incorporation of inputs:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/
>>>>>>>                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.05/>
>>>>>>>
>>>>>>>                       With Regards,
>>>>>>>                       Avik Niyogi
>>>>>>>
>>>>>>>
>>>>>>>                           On 14-Jan-2016, at 3:18 pm, Alexander
>>>>>>>                           Scherbatiy
>>>>>>>                           <alexandr.scherbatiy at oracle.com
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                           <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                           wrote:
>>>>>>>
>>>>>>>                           On 1/14/2016 8:18 AM, Avik Niyogi wrote:
>>>>>>>
>>>>>>>
>>>>>>>                               Hi All,
>>>>>>>                               Please find changes as provided with
>>>>>>>                               incorporation of inputs:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/
>>>>>>>                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>>>                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
>>>>>>>
>>>>>>>
>>>>>>>                            It is better to restore the graphics
>>>>>>>                           transform after the progress
>>>>>>>                           bar is painted and before the paintString
>>>>>>>                           call because the a method
>>>>>>>                           that calls
>>>>>>>                           AquaProgressBarUI.paint(Graphics) can rely
>>>>>>>                           that the
>>>>>>>                           graphics transform is unchanged.
>>>>>>>                           In your fix the graphics transform is not
>>>>>>>                           restored if
>>>>>>>                           progressBar.isStringPainted() returns
>>>>>>> false.
>>>>>>>
>>>>>>>                           Thanks,
>>>>>>>                           Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                               With Regards,
>>>>>>>                               Avik Niyogi
>>>>>>>
>>>>>>>
>>>>>>>                                   On 13-Jan-2016, at 7:02 pm,
>>>>>>>                                   Alexander Scherbatiy
>>>>>>>                                   <alexandr.scherbatiy at oracle.com
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                   <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                   <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                   <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                                   wrote:
>>>>>>>
>>>>>>>                                   On 1/13/2016 9:28 AM, Avik Niyogi
>>>>>>>                                   wrote:
>>>>>>>
>>>>>>>
>>>>>>>                                       Hi All,
>>>>>>>                                       Please find changes as
>>>>>>>                                       provided with incorporation of
>>>>>>>                                       inputs:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.03/
>>>>>>>                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>>>                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>>>                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>>>>>
>>>>>>>
>>>>>>>                                   It looks like a string on a
>>>>>>>                                   vertical progress bar with the
>>>>>>>                                   right to
>>>>>>>                                   left orientation will be mirrored.
>>>>>>>                                   Did you try just restore the
>>>>>>>                                   scale/translate transform after the
>>>>>>>                                   painter.paint() call? Will it help
>>>>>>>                                   in such case?
>>>>>>>
>>>>>>>                                   Thanks,
>>>>>>>                                   Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                                       With Regards,
>>>>>>>                                       Avik Niyogi
>>>>>>>
>>>>>>>
>>>>>>>                                           On 12-Jan-2016, at 11:49
>>>>>>>                                           pm, Alexander Scherbatiy
>>>>>>>                                           <alexandr.scherbatiy at oracle.com
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                           <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                                           wrote:
>>>>>>>
>>>>>>>
>>>>>>>                                           - there was the comment
>>>>>>>                                           below that it is better to
>>>>>>>                                           revert the
>>>>>>>                                           transform back after the
>>>>>>>                                           painter.paint() call
>>>>>>>                                           - according to the comment
>>>>>>>                                           from the
>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-January/005262.html
>>>>>>>
>>>>>>>                                           It is true that a filled
>>>>>>>                                           progress bar has different
>>>>>>>                                           colors because
>>>>>>>                                           of animation under Aqua
>>>>>>> L&F.
>>>>>>>                                           However, it is possible to
>>>>>>>                                           compare colors before a
>>>>>>>                                           progress bar
>>>>>>>                                           was filled and after that
>>>>>>>                                           to check that the progress
>>>>>>>                                           bar is filled
>>>>>>>                                           from the correct side.
>>>>>>>                                           For example let's set a
>>>>>>>                                           progress bar value to 0
>>>>>>>                                           and get its color
>>>>>>>                                           from 5/6 of the progress
>>>>>>>                                           bar width
>>>>>>>                                             progress bar:
>>>>>>>                                           [_________o__]  // get a
>>>>>>>                                           color at point o
>>>>>>>                                           Now set the progress bar
>>>>>>>                                           value to 30 and get a
>>>>>>>                                           color at the same
>>>>>>>                                           point.
>>>>>>>                                           If colors are the same
>>>>>>>                                           then  the progress bar is
>>>>>>>                                           filled from left
>>>>>>>                                           to the right
>>>>>>> [||||_____o__].
>>>>>>>                                           If colors are different
>>>>>>>                                           then the progress bar is
>>>>>>>                                           filled from the
>>>>>>>                                           right to the left
>>>>>>>                                           [________|o||] .
>>>>>>>
>>>>>>>                                           Thanks,
>>>>>>>                                           Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>                                           On 12/01/16 13:34, Avik
>>>>>>>                                           Niyogi wrote:
>>>>>>>
>>>>>>>
>>>>>>>                                               Hi All,
>>>>>>>
>>>>>>>                                               Please find the code
>>>>>>>                                               changes in fix as with
>>>>>>>                                               the inputs received
>>>>>>>                                               for the same.
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.02/
>>>>>>>                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>>>                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>>>                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>>>
>>>>>>>                                               With Regards,
>>>>>>>                                               Avik Niyogi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                                                   On 11-Jan-2016, at
>>>>>>>                                                   3:55 pm, Semyon
>>>>>>>                                                   Sadetsky
>>>>>>>                                                   <semyon.sadetsky at oracle.com
>>>>>>> <mailto:semyon.sadetsky at oracle.com>
>>>>>>> <mailto:semyon.sadetsky at oracle.com>
>>>>>>>                                                   <mailto:semyon.sadetsky at oracle.com><mailto:semyon.sadetsky at oracle.com>
>>>>>>>                                                   <mailto:semyon.sadetsky at oracle.com>
>>>>>>>                                                   <mailto:semyon.sadetsky at oracle.com>>
>>>>>>>                                                   wrote:
>>>>>>>
>>>>>>>                                                   Hi Avik,
>>>>>>>
>>>>>>>                                                   Shouldn't the
>>>>>>>                                                   graphics
>>>>>>>                                                   transformation be
>>>>>>>                                                   restored before the
>>>>>>>                                                   paintString() call?
>>>>>>>
>>>>>>>                                                   It seems to me
>>>>>>>                                                   that left/right
>>>>>>>                                                   insets need to be
>>>>>>>                                                   swapped for
>>>>>>>                                                   right-to-left
>>>>>>>                                                   painting with
>>>>>>>                                                   mirroring graphics
>>>>>>>                                                   transformation.
>>>>>>>
>>>>>>>                                                   --Semyon
>>>>>>>
>>>>>>>                                                   On 1/5/2016 1:22
>>>>>>>                                                   PM, Avik Niyogi
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>                                                       Hi All,
>>>>>>>                                                       Please find
>>>>>>>                                                       webrev with
>>>>>>>                                                       inputs as
>>>>>>>                                                       provided:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.01/
>>>>>>>                                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>>>                                                       <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/>
>>>>>>>                                                       With Regards,
>>>>>>>                                                       Avik Niyogi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                                                           On
>>>>>>>                                                           23-Dec-2015,
>>>>>>>                                                           at 7:29
>>>>>>>                                                           pm,
>>>>>>>                                                           Alexander
>>>>>>>                                                           Scherbatiy
>>>>>>>                                                           <alexandr.scherbatiy at oracle.com
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                                           <mailto:alexandr.scherbatiy at oracle.com>
>>>>>>>                                                           <mailto:alexandr.scherbatiy at oracle.com>>
>>>>>>>                                                           wrote:
>>>>>>>
>>>>>>>
>>>>>>>                                                           - please
>>>>>>>                                                           check that
>>>>>>>                                                           the
>>>>>>>                                                           progress
>>>>>>>                                                           bar string
>>>>>>>                                                           (progressBar.setString()/setStringPainted())
>>>>>>>                                                           is painted
>>>>>>>                                                           correctly.
>>>>>>>                                                           - is it
>>>>>>>                                                           possible
>>>>>>>                                                           to write
>>>>>>>                                                           an
>>>>>>>                                                           automated
>>>>>>>                                                           test for
>>>>>>>                                                           the fix?
>>>>>>>
>>>>>>>                                                           Thanks,
>>>>>>>                                                           Alexandr.
>>>>>>>
>>>>>>>                                                           On
>>>>>>>                                                           12/21/2015
>>>>>>>                                                           11:47 AM,
>>>>>>>                                                           Avik
>>>>>>>                                                           Niyogi
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>                                                               Hi All,
>>>>>>>
>>>>>>>                                                               Kindly
>>>>>>>                                                               review
>>>>>>>                                                               the
>>>>>>>                                                               bug
>>>>>>>                                                               fix
>>>>>>>                                                               for
>>>>>>> JDK 9.
>>>>>>>
>>>>>>>                                                               *Bug:*
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8015748
>>>>>>>
>>>>>>>                                                               *Webrev:*
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.00/
>>>>>>>                                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>>>                                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>>>                                                               <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>>>
>>>>>>>                                                               *Issue:*
>>>>>>>                                                               The
>>>>>>>                                                               manual
>>>>>>>                                                               test:
>>>>>>>                                                               Swing_JProgressbar/Manual/ProgressBarLAFTests/ProgressBarLAFTest1
>>>>>>>                                                               in
>>>>>>>                                                               testsuite
>>>>>>> http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/7/swing
>>>>>>>                                                               fails
>>>>>>>
>>>>>>>                                                               *Cause:*
>>>>>>>                                                               Due to
>>>>>>>                                                               not
>>>>>>>                                                               honouring
>>>>>>>                                                               of
>>>>>>>                                                               RIGHT_TO_LEFT
>>>>>>>                                                               parameter
>>>>>>>                                                               for
>>>>>>>                                                               setOrientation
>>>>>>>                                                               method
>>>>>>>                                                               applied
>>>>>>> for
>>>>>>>                                                               a
>>>>>>>                                                               JProgressBar
>>>>>>>                                                               for the
>>>>>>>                                                               AquaLookAndFeel
>>>>>>>                                                               only,
>>>>>>>                                                               the
>>>>>>>                                                               progressBar
>>>>>>>                                                               does
>>>>>>>                                                               not
>>>>>>>                                                               have
>>>>>>>                                                               the
>>>>>>>                                                               ability
>>>>>>> to
>>>>>>>                                                               grow
>>>>>>>                                                               from
>>>>>>> right
>>>>>>>                                                               to
>>>>>>>                                                               left.
>>>>>>>                                                               This
>>>>>>>                                                               issue
>>>>>>>                                                               was
>>>>>>>                                                               verified
>>>>>>>                                                               to
>>>>>>>                                                               exist
>>>>>>>                                                               only in
>>>>>>>                                                               AquaLookAndFeel
>>>>>>>                                                               for
>>>>>>>                                                               JProgressBar.
>>>>>>>
>>>>>>>                                                               *Fix:*
>>>>>>>                                                               Added
>>>>>>>                                                               implementation
>>>>>>>                                                               for
>>>>>>>                                                               the
>>>>>>>                                                               check
>>>>>>>                                                               of
>>>>>>>                                                               RIGHT_TO_LEFT
>>>>>>>                                                               ComponentOrientation
>>>>>>>                                                               and
>>>>>>>                                                               verified
>>>>>>>                                                               with
>>>>>>>                                                               other
>>>>>>>                                                               combination
>>>>>>>                                                               orientation
>>>>>>>                                                               with
>>>>>>>                                                               available
>>>>>>>                                                               Horizontal
>>>>>>>                                                               and
>>>>>>>                                                               Vertical
>>>>>>>                                                               orientations
>>>>>>>                                                               as
>>>>>>>                                                               provided
>>>>>>>                                                               from
>>>>>>>                                                               before.
>>>>>>>
>>>>>>>                                                               With
>>>>>>>                                                               Regards,
>>>>>>>                                                               Avik
>>>>>>>                                                               Niyogi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                   --
>>>>>>>                   Best regards, Sergey.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Mar 21 14:37:27 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 17:37:27 +0300
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with
 GTK LnF
In-Reply-To: <F78727F3-6931-4A40-A949-45EC3C716614@oracle.com>
References: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
	<56E17C34.5030303@oracle.com>
	<8AE0341F-6D3A-4586-B7CC-38318B986450@oracle.com>
	<2DD39FDD-D8C9-47B6-BAAB-D1AEA0A22DF6@oracle.com>
	<56EC68F6.5000106@oracle.com>
	<F78727F3-6931-4A40-A949-45EC3C716614@oracle.com>
Message-ID: <56F00727.8060703@oracle.com>

Hi, Avik.
How this test can fail? I do not see any raised exceptions?

On 21.03.16 9:46, Avik Niyogi wrote:
> Hi Sergey,
> Please review the following code change.
> With Regards,
> Avik Niyogi
>> On 19-Mar-2016, at 2:15 am, Alexander Scherbatiy
>> <alexandr.scherbatiy at oracle.com
>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>
>> The fix looks good to me.
>>
>> Thanks,
>> Alexandr.
>>
>> On 14/03/16 16:25, Avik Niyogi wrote:
>>> Hi All,
>>> Please review code changes made as per inputs provided.
>>>
>>> http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.01/>
>>> With Regards,
>>> Avik Niyogi
>>>> On 14-Mar-2016, at 10:53 am, Avik Niyogi
>>>> <<mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com> wrote:
>>>>
>>>> Hi Sergey,
>>>> Seems like it is a delay issue. Will submit test case with a
>>>> waitForIdle() fix.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>
>>>>> Hi, Avik.
>>>>> A few questions.
>>>>> - Why webrev contains the new file?
>>>>> - You marked the test as a mac specific but it is iterates over a
>>>>> bunch of l&fs. It seems it should not be OS specific, but should
>>>>> check some specific l&fs (which support such icons): Metal, Nimbus,
>>>>> Aqua, Windows(???). So gtk/motif should be skipped.
>>>>>
>>>>> On 08.03.16 8:10, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>
>>>>>> *Bug:*
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151282
>>>>>>
>>>>>> *Webrev:*
>>>>>>
>>>>>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
>>>>>> _
>>>>>> _
>>>>>> *Issue:*
>>>>>> The test case failed for GTK LAF.
>>>>>>
>>>>>> *Cause:*
>>>>>> The test case was meant to be Mac specific and was missing a jtreg
>>>>>> parameter
>>>>>>
>>>>>> *Fix:*
>>>>>> Minor change to test case with @requires tag added to set the fix.
>>>>>>
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>
>>>>>
>>>>> --
>>>>> Best regards, Sergey.
>>>>
>>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Mar 21 14:37:34 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 17:37:34 +0300
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with
 GTK LnF
In-Reply-To: <F78727F3-6931-4A40-A949-45EC3C716614@oracle.com>
References: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
	<56E17C34.5030303@oracle.com>
	<8AE0341F-6D3A-4586-B7CC-38318B986450@oracle.com>
	<2DD39FDD-D8C9-47B6-BAAB-D1AEA0A22DF6@oracle.com>
	<56EC68F6.5000106@oracle.com>
	<F78727F3-6931-4A40-A949-45EC3C716614@oracle.com>
Message-ID: <56F0072E.9070800@oracle.com>

Hi, Avik.
How this test can fail? I do not see any raised exceptions.

On 21.03.16 9:46, Avik Niyogi wrote:
> Hi Sergey,
> Please review the following code change.
> With Regards,
> Avik Niyogi
>> On 19-Mar-2016, at 2:15 am, Alexander Scherbatiy
>> <alexandr.scherbatiy at oracle.com
>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>
>> The fix looks good to me.
>>
>> Thanks,
>> Alexandr.
>>
>> On 14/03/16 16:25, Avik Niyogi wrote:
>>> Hi All,
>>> Please review code changes made as per inputs provided.
>>>
>>> http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.01/>
>>> With Regards,
>>> Avik Niyogi
>>>> On 14-Mar-2016, at 10:53 am, Avik Niyogi
>>>> <<mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com> wrote:
>>>>
>>>> Hi Sergey,
>>>> Seems like it is a delay issue. Will submit test case with a
>>>> waitForIdle() fix.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>
>>>>> Hi, Avik.
>>>>> A few questions.
>>>>> - Why webrev contains the new file?
>>>>> - You marked the test as a mac specific but it is iterates over a
>>>>> bunch of l&fs. It seems it should not be OS specific, but should
>>>>> check some specific l&fs (which support such icons): Metal, Nimbus,
>>>>> Aqua, Windows(???). So gtk/motif should be skipped.
>>>>>
>>>>> On 08.03.16 8:10, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>
>>>>>> *Bug:*
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151282
>>>>>>
>>>>>> *Webrev:*
>>>>>>
>>>>>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
>>>>>> _
>>>>>> _
>>>>>> *Issue:*
>>>>>> The test case failed for GTK LAF.
>>>>>>
>>>>>> *Cause:*
>>>>>> The test case was meant to be Mac specific and was missing a jtreg
>>>>>> parameter
>>>>>>
>>>>>> *Fix:*
>>>>>> Minor change to test case with @requires tag added to set the fix.
>>>>>>
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>
>>>>>
>>>>> --
>>>>> Best regards, Sergey.
>>>>
>>>
>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Mon Mar 21 14:41:48 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 21 Mar 2016 18:41:48 +0400
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56EC2389.3020507@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
Message-ID: <56F0082C.5020503@oracle.com>


On 18/03/16 19:49, Alexander Scherbatiy wrote:
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>
>   - Public TextUIDrawing interface is added to the javax.swing.plaf 
> package
>   - TextUIDrawing methods description does not mention component 
> properties to be more general
>   - TextUIDrawing methods are made default
>   - L&F sets an instance of the TextUIDrawing to look and feel 
> defaults using "uiDrawing.text" property
>   - ComponentUI class is not changed
>   - Each ComponentUI reads TextUIDrawing from UI defaults
>   - There is an interesting issue described in
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>     which is related to the fact that MetalLabelUI returns a static 
> field from createUI() method.
>     TitleBorder creates a JLabel but does not put it to any component 
> hierarchy. In this case SwingUtilities.updateComponentTreeUI() method 
> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI 
> field and sets a new LabelUI for ordinary labels. The TitleBorder 
> label UI is not changed in this case and it still uses the 
> metalLabelUI field which is not initialized.
>     It seems that other applications can also use components just for 
> drawing and have the same issue.
>     For this case the textUIDrawing field is not cleared in the 
> uninstallDefaults but just set to a static default value which should 
> not lead to memory leaks.

   I used JMH for an average time measuring of a test method which calls 
text UI drawing class from a SynthLookAndFeel method:
------------
     @Benchmark
     @BenchmarkMode(Mode.SampleTime)
     @OutputTimeUnit(TimeUnit.MICROSECONDS)
     public void testDrawMethod() throws Exception {
         int N = 10000;
         JComponent component = new JLabel(TEXT);
         SynthGraphicsUtils synthGrapicsUtils = new SynthGraphicsUtils();
         ...
         for (int i = 0; i < N; i++) {
             synthGrapicsUtils.computeStringWidth(synthContext, font, 
fontMetrics, TEXT);
             synthGrapicsUtils.paintText(synthContext, g, TEXT, 10, 10, 0);
         }
     }
   ------------

   Here is the full code of the tested method: 
http://cr.openjdk.java.net/~alexsch/8132119/jmh/test.00/TextUIDrawingBenchmark.java

  I used 3 samples with different JDK:
  Sample 1: JDK without fixes
  Sample 2: JDK where instance of TextUIDrawing class is placed in base 
ComponentUI class.
  Sample 3: JDK where instance of TextUIDrawing is loaded for each 
necessary UI class from UIManager "uiDrawing.text" property.

  In the Sample 2 SynthGraphicsUtils retrieves a TextUIDrawing instance 
from the provided JComponent.getUI() class.
  In the Sample 3 SynthGraphicsUtils gets a TextUIDrawing instance from 
UIManager property.

  The calculated average time in microseconds is:
  Sample 1: 20976.041 ? 60.181
  Sample 2: 21556.180 ? 89.476
  Sample 3: 23607.186 ? 62.319

  If just roughly use a formula like:
    method_time = initialization_time + loop_count * 
(time_for_same_operation + time_for different_operations)
  it is possible to get a time estimation for different operation like: 
(method_time2 - method_time1) / loop_count

  Such time difference calculation gives:
  0.08 microseconds for Sample 2
  0.26 microseconds for Sample 3

  Thanks,
  Alexandr.

>
>   Thanks,
>   Alexandr.
>
> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>> Hi Alexandr,
>>>
>>>> Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>> ....
>>>> - public TextUIDrawing interface is added to the javax.swing.plaf 
>>>> package
>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>> ComponentUI class
>>>> - L&F sets an instance of the TextUIDrawing to look and feel 
>>>> defaults using
>>>> "uiDrawing.text" property
>>>> - Look and Feel delegates use the instance of the TextUIDrawing for 
>>>> text
>>>> drawing and measuring
>>> Some thoughts on the current design/implementation:
>>>
>>> By adding a field to the ComponentUI class the current 
>>> implementation increases
>>> memory consumption for all Swing applications. And you get the 
>>> feeling that
>>> there are different implementations of TextUIDrawing per ComponentUI 
>>> instances.
>>> Personally I can't imagine to have different implementations of
>>> TextUIDrawing for
>>> a given LookAndFeel. If I would design/implement it, then I would
>>> implement it as
>>> a property of the LookAndFeel class (similar to LayoutStyle) and not
>>> the ComponentUI.
>>> Developers can use then the following code to obtain the instance of
>>> TextUIDrawing:
>>>
>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>> short cut for the line above.
>>   LayoutStyle keeps its instance per App context. The same is for the 
>> LookAndFeel
>>   when it is got through UIManager.getLookAndFeel() call.
>>   It means that accessing an instance of a TextUIDrawing will leads 
>> to a time consumption.
>>
>>   There are 3 main ways of the SwingUtilities2.drawString(...) usage:
>>   1. ComponentUI classes
>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>   3. Public utilities methods (like WindowsGraphicsUtils.paintText())
>>
>>   For the cases 1 and 2 it is possible to load and store the 
>> UIDrawing instance during installUI()/updateUI() calls to decrease a 
>> time access to it.
>>
>>   For the case 3 it is necessary to get LookAndFeel instance each 
>> time (which is taken from an App context)
>>   or use the passed JComponent object. It requires to have a public 
>> method and the associated variable for each instance of 
>> JComponent/ComponentUI/... class.
>>> You can use this methods then in JDK too.
>>>
>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>> more useful methods,
>>> e.g. a method to create a composite font, a method to convert DLUs 
>>> to pixels.
>>   UIDrawing name may look like it should be used for any UI drawing, 
>> not only for text ones. I am afraid that it can be misleading.
>>
>>   Thanks,
>>   Alexandr.
>>
>>>
>>> Best regards,
>>> Andrej Golovnin
>>
>



From Sergey.Bylokhov at oracle.com  Mon Mar 21 14:47:58 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 17:47:58 +0300
Subject: <Swing Dev> [9] Review request for 8151015: JTextArea.insert()
 does not behave as expected with invalid position
In-Reply-To: <56E9A0A5.8070102@oracle.com>
References: <56E6EB5C.7000305@oracle.com> <56E9A0A5.8070102@oracle.com>
Message-ID: <56F0099E.7050705@oracle.com>

Should the test also cover the html based string(and cover the changes 
in HTMLDocument)?

On 16.03.16 21:06, Alexander Scherbatiy wrote:
>
> The fix looks good to me.
>
> Just a small comment: if it is a new test it probably should not contain
> 1998 year in the copyright.
>
> Thanks,
> Alexandr.
>
> On 14/03/16 20:48, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8151015
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8151015/webrev.00/
>>
>> It is regression of 4496801. The fix for 4496801 was wrong and the
>> correct fix should be taking into account the implied character at the
>> end of the document. Reverting 4496801 fixes 8151015. Also the correct
>> fix for 4496801 is provided.
>>
>> --Semyon
>


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Mon Mar 21 15:21:21 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 21 Mar 2016 18:21:21 +0300
Subject: <Swing Dev> [9] Review request for 8152159 LabelUI is not
 updated for TitledBorder
In-Reply-To: <56EC48FE.8010008@oracle.com>
References: <56EBC351.3090206@oracle.com> <56EC216D.9030104@oracle.com>
	<56EC48FE.8010008@oracle.com>
Message-ID: <56F01171.8010001@oracle.com>

Looks good.

--Semyon

On 3/18/2016 9:29 PM, Alexander Scherbatiy wrote:
> On 18/03/16 19:40, Semyon Sadetsky wrote:
>> Hi Alexander,
>>
>> Maybe it would be more optimal to update UI in a property change 
>> listener added to the UIManager?
>>
>>     public void propertyChange(PropertyChangeEvent e) {
>>         if ("lookAndFeel" == e.getPropertyName()) {
>>               label.updateUI();
>>         }
>>     }
>>
>
>   Thank you for the review.
>
>   Could you review the updated fix:
> http://cr.openjdk.java.net/~alexsch/8152159/webrev.01/
>
>   - property change listener is used to get a notification bot L&F or 
> LabelUI change
>   - the test is updated to check the LabelUI change
>
>  Thanks,
>  Alexandr.
>> --Semyon
>>
>> On 3/18/2016 11:58 AM, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8152159
>>>   webrev: http://cr.openjdk.java.net/~alexsch/8152159/webrev.00
>>>
>>>
>>>   The TitledBorder label is only used for painting and does not 
>>> belong  to any component hierarchy so it is not updated by 
>>> SwingUtilities.updateComponentTreeUI() method.
>>>   The fix updates the  TitledBorder label UI when the label is 
>>> requested.
>>>
>>>   Thanks,
>>>   Alexandr.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/c510eaf6/attachment.html>

From alexandr.scherbatiy at oracle.com  Mon Mar 21 15:54:09 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 21 Mar 2016 19:54:09 +0400
Subject: <Swing Dev> [OpenJDK 2D-Dev] [9] Review request for 8151303
 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it
In-Reply-To: <56E839DC.2040904@oracle.com>
References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com>
	<56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com>
	<56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com>
	<56E839DC.2040904@oracle.com>
Message-ID: <56F01921.6060305@oracle.com>


The one more thing is that image filters should also be updated to use 
them with multi-resolution images.
For example, consider the case:
----------
     Image mrImage = getMultiResolutionImage();
     ImageProducer mriProducer = new 
FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, 0, w, h));
     Toolkit.getDefaultToolkit().createImage(mriProducer);
----------

The crop image filter applied to each resolution variant just cuts 
images with the same size.
It seems that there should be added API which allows to set a scale for 
a provided image filter to be properly used with the given resolution 
variant.

I have created a separated issue for multi-resolution images filtering 
support:
   JDK-8152309 Seamless way of using image filters with multi-resolution 
images
   https://bugs.openjdk.java.net/browse/JDK-8152309

Thanks,
Alexandr.

On 15/03/16 20:35, Alexander Scherbatiy wrote:
> On 15/03/16 18:06, Sergey Bylokhov wrote:
>> On 15.03.16 17:01, Alexander Scherbatiy wrote:
>>
>>>   One update will be that FilteredImageSource should implement
>>> MultiResolutionImageProducer even it is used for non multi-resolution
>>> images.
>>>
>>>    The MRI can be created using two general ways: using fixed number of
>>> resolution variants or generating a resolution variant with necessary
>>> quality on demand.
>>>
>>>   The current implementation is rely on that MRToolkitImage contains a
>>> fixed number of resolution variants. In this case MediaTracker can
>>> iterate over resolution variants and load them all.
>>>
>>>   Using MultiResolutionImageProducer leads that MRToolkitImage will not
>>> know about number of resolution variants in case when they are 
>>> generated
>>> on the fly and there will be no way to load all of them by 
>>> MediaTracker.
>>
>> Just an idea to thinking about, can we save this filter to the MRI 
>> itself and apply it after some resolution variant will be created on 
>> the fly?
>
> Do you mean that it helps to leave the code in the AquaUtils class 
> unchanged:
> ---------------
>  124     static Image generateLightenedImage(final Image image, final 
> int percent) {
>  125         final GrayFilter filter = new GrayFilter(true, percent);
>  126         final ImageProducer prod = new 
> FilteredImageSource(image.getSource(), filter);
>  127         return Toolkit.getDefaultToolkit().createImage(prod);
>  128     }
> ---------------
>
>   or it is just an a better way for a filtered multi-resolution image 
> generation?
>
>   Thanks,
>   Alexandr.
>>
>>>
>>> As I see, the way to solve it is only using MRI.getResolutionVariants()
>>> method for the MultiResolutionImageProducer creation. So the result of
>>> the call
>>>     toolkit.createImage(new FilteredImageSource(mrImage.getSource(),
>>> filter));
>>>   will be a MRToolkitImage which is based on fixed number of filtered
>>> resolution variants from the original MRI.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>> ...jim
>>>>
>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote:
>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote:
>>>>>> Probably we should enhance 
>>>>>> ImageProducer/Tk.createImage/ImageFilter to
>>>>>> support this functionality? It seems that the number of usage of 
>>>>>> this
>>>>>> check "image instanceof MultiResolutionImage" will grow over time.
>>>>>     ImageProducer produces pixels for an image and is not able to 
>>>>> take
>>>>> an information about the image resolution variants.
>>>>>
>>>>>   May be we can add Toolkit.createImage(Image image, ImageFilter
>>>>> imageFilter) method which takes MultiResolutionImage into account to
>>>>> cover the common case where filtered image is created.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>> I think that at least our own API should support 
>>>>>> MultiResolutionImage
>>>>>> w/o such checks, otherwise the user will need to do the same.
>>>>>>
>>>>>> cc 2d-dev
>>>>>>
>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the fix:
>>>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8151303
>>>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00
>>>>>>>
>>>>>>>    The AquaUtils does not take into account MultiResolutionImage 
>>>>>>> for
>>>>>>> selected/disabled/lightened images generation.
>>>>>>>    The fix also leaves the MultiResolutionCachedImage check because
>>>>>>> the
>>>>>>> base system icon size can be differ from the requested painted 
>>>>>>> size.
>>>>>>>
>>>>>>>    Thanks,
>>>>>>>    Alexandr.
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>



From semyon.sadetsky at oracle.com  Mon Mar 21 16:46:20 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 21 Mar 2016 19:46:20 +0300
Subject: <Swing Dev> [9] Review request for 8146301: Enter key does not
 work in a deserialized JFileChooser
In-Reply-To: <56EAD36E.8090108@oracle.com>
References: <56EAC145.6050209@oracle.com> <56EAD36E.8090108@oracle.com>
Message-ID: <56F0255C.4090800@oracle.com>

yes. This a generic code issue.

On 3/17/2016 6:55 PM, Sergey Bylokhov wrote:
> Does the test is passed on all platforms?
>
> On 17.03.16 17:37, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8146301
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8146301/webrev.00/
>>
>> This is a regression of JDK-8021253 in which explicit setting the
>> default button was moved to the hierarchy listener but this listener
>> disappears after serialization/deserialization cycle because it is not
>> serializable. The solution is to make it serializable.
>>
>> --Semyon
>
>



From Sergey.Bylokhov at oracle.com  Mon Mar 21 17:09:17 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 20:09:17 +0300
Subject: <Swing Dev> [9] Review request for 8146301: Enter key does not
 work in a deserialized JFileChooser
In-Reply-To: <56F0255C.4090800@oracle.com>
References: <56EAC145.6050209@oracle.com> <56EAD36E.8090108@oracle.com>
	<56F0255C.4090800@oracle.com>
Message-ID: <56F02ABD.3020604@oracle.com>

On 21.03.16 19:46, Semyon Sadetsky wrote:
> yes. This a generic code issue.

It is failed on OSX even after the fix, please double check.

>
> On 3/17/2016 6:55 PM, Sergey Bylokhov wrote:
>> Does the test is passed on all platforms?
>>
>> On 17.03.16 17:37, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146301
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8146301/webrev.00/
>>>
>>> This is a regression of JDK-8021253 in which explicit setting the
>>> default button was moved to the hierarchy listener but this listener
>>> disappears after serialization/deserialization cycle because it is not
>>> serializable. The solution is to make it serializable.
>>>
>>> --Semyon
>>
>>
>


-- 
Best regards, Sergey.


From alexander.zvegintsev at oracle.com  Mon Mar 21 17:59:08 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 21 Mar 2016 20:59:08 +0300
Subject: <Swing Dev> CFV: New Swing Group Member: Semyon Sadetsky
In-Reply-To: <56EF8E29.4070605@oracle.com>
References: <56EF8E29.4070605@oracle.com>
Message-ID: <56F0366C.6010102@oracle.com>

Vote: yes

--
Thanks,
Alexander.

On 21.03.2016 9:01, Alexander Scherbatiy wrote:
>
> I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to 
> Membership in the Swing Group.
>
> Semyon is active member of Swing group and contributed a lot of fixes 
> which include Swing TimerQueue race condition improvement, UndoManager 
> deadlock resolving, proposing and implementation a public API for 
> internal Swing functionality which is part of Swing modularization 
> support for JDK 9, and others (see Semyon?s list OpenJDK changesets [1])
>
> Semyon proposed a big change for the Swing part of the JEP 283 ?Enable 
> GTK 3 on Linux? [2] implementation [3].
>
> Semyon not only provides fixes for Swing issues but also regularly 
> reviews fixes suggested by other members.
>
> Votes are due by Apr 5, 2016.
>
> Only current Members of the Swing  Group [4] are eligible
> to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [5].
>
> Thanks,
> Alexandr.
>
> [1] 
> http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ssadetsky%22%29
> [2] http://openjdk.java.net/jeps/283
> [3] 
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005440.html
> [4] http://openjdk.java.net/census#swing
> [5] http://openjdk.java.net/groups/#member-vote



From semyon.sadetsky at oracle.com  Mon Mar 21 18:05:47 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 21 Mar 2016 21:05:47 +0300
Subject: <Swing Dev> [9] Review request for 8146301: Enter key does not
 work in a deserialized JFileChooser
In-Reply-To: <56F02ABD.3020604@oracle.com>
References: <56EAC145.6050209@oracle.com> <56EAD36E.8090108@oracle.com>
	<56F0255C.4090800@oracle.com> <56F02ABD.3020604@oracle.com>
Message-ID: <56F037FB.802@oracle.com>

On 3/21/2016 8:09 PM, Sergey Bylokhov wrote:
> On 21.03.16 19:46, Semyon Sadetsky wrote:
>> yes. This a generic code issue.
>
> It is failed on OSX even after the fix, please double check.
This problem is unrelated to the current issue. I have filed a separate 
bug: https://bugs.openjdk.java.net/browse/JDK-8152332.
>
>>
>> On 3/17/2016 6:55 PM, Sergey Bylokhov wrote:
>>> Does the test is passed on all platforms?
>>>
>>> On 17.03.16 17:37, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146301
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8146301/webrev.00/
>>>>
>>>> This is a regression of JDK-8021253 in which explicit setting the
>>>> default button was moved to the hierarchy listener but this listener
>>>> disappears after serialization/deserialization cycle because it is not
>>>> serializable. The solution is to make it serializable.
>>>>
>>>> --Semyon
>>>
>>>
>>
>
>



From james.graham at oracle.com  Mon Mar 21 18:31:39 2016
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 21 Mar 2016 11:31:39 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [9] Review request for 8151303
 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it
In-Reply-To: <56F01921.6060305@oracle.com>
References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com>
	<56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com>
	<56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com>
	<56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com>
Message-ID: <56F03E0B.1080703@oracle.com>

We could do that for our own filters, but any random custom filter could 
run into the same issue, so it might not make sense to upgrade the 
existing filter mechanism to always attempt to do MR filtering.  We 
could either create a parallel set of MR-aware filter mechanisms (such 
as the previously suggested new method on Toolkit, or a new MR-aware 
version of FilteredImageSource for instance) and leave the existing 
mechanism as clearly documented as MR-unaware.  Another idea is to tag a 
filter with an interface that indicates that it is MR aware?  In any 
case, some thought needs to be given to feeding an MR image to a filter 
that (potentially or demonstrably) cannot deal with MR images.

Alternately, we could then recommend that the old image filtering code 
isn't combined with multi-resolution images.  It seems to me that the 
programmer is mostly in control over this happening since they've either 
manually created the MR image using the custiom MR image mechanism or 
they've supplied media with multiple resolution files (i.e. "@2x").  Is 
that really the case?

Whether it is a new filtering mechanism that must be adopted or simply 
declaring the old filtering mechanism as "obsolete with respect to MR 
images"...

That recommendation then "restricts forward" in that, for example, since 
Swing relies on the old mechanism, Swing then becomes "not recommended 
for use with MR images", or "not MR aware".  That's probably not a 
restriction we want to promote so it should be viewed as a temporary 
restriction reality and a bug that we'll fix soon, whether by using some 
other mechanism to achieve the desired affects, or creating a new 
MR-aware filtering mechanism and using it in Swing.

Similarly, other 3rd party libraries that accept images and do anything 
more than display them will have to be upgraded as well before they 
become "MR aware" or "MR accepting" or whatever term applies here...

			...jim

On 3/21/16 8:54 AM, Alexander Scherbatiy wrote:
>
> The one more thing is that image filters should also be updated to use
> them with multi-resolution images.
> For example, consider the case:
> ----------
>      Image mrImage = getMultiResolutionImage();
>      ImageProducer mriProducer = new
> FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, 0, w, h));
>      Toolkit.getDefaultToolkit().createImage(mriProducer);
> ----------
>
> The crop image filter applied to each resolution variant just cuts
> images with the same size.
> It seems that there should be added API which allows to set a scale for
> a provided image filter to be properly used with the given resolution
> variant.
>
> I have created a separated issue for multi-resolution images filtering
> support:
>    JDK-8152309 Seamless way of using image filters with multi-resolution
> images
>    https://bugs.openjdk.java.net/browse/JDK-8152309
>
> Thanks,
> Alexandr.
>
> On 15/03/16 20:35, Alexander Scherbatiy wrote:
>> On 15/03/16 18:06, Sergey Bylokhov wrote:
>>> On 15.03.16 17:01, Alexander Scherbatiy wrote:
>>>
>>>>   One update will be that FilteredImageSource should implement
>>>> MultiResolutionImageProducer even it is used for non multi-resolution
>>>> images.
>>>>
>>>>    The MRI can be created using two general ways: using fixed number of
>>>> resolution variants or generating a resolution variant with necessary
>>>> quality on demand.
>>>>
>>>>   The current implementation is rely on that MRToolkitImage contains a
>>>> fixed number of resolution variants. In this case MediaTracker can
>>>> iterate over resolution variants and load them all.
>>>>
>>>>   Using MultiResolutionImageProducer leads that MRToolkitImage will not
>>>> know about number of resolution variants in case when they are
>>>> generated
>>>> on the fly and there will be no way to load all of them by
>>>> MediaTracker.
>>>
>>> Just an idea to thinking about, can we save this filter to the MRI
>>> itself and apply it after some resolution variant will be created on
>>> the fly?
>>
>> Do you mean that it helps to leave the code in the AquaUtils class
>> unchanged:
>> ---------------
>>  124     static Image generateLightenedImage(final Image image, final
>> int percent) {
>>  125         final GrayFilter filter = new GrayFilter(true, percent);
>>  126         final ImageProducer prod = new
>> FilteredImageSource(image.getSource(), filter);
>>  127         return Toolkit.getDefaultToolkit().createImage(prod);
>>  128     }
>> ---------------
>>
>>   or it is just an a better way for a filtered multi-resolution image
>> generation?
>>
>>   Thanks,
>>   Alexandr.
>>>
>>>>
>>>> As I see, the way to solve it is only using MRI.getResolutionVariants()
>>>> method for the MultiResolutionImageProducer creation. So the result of
>>>> the call
>>>>     toolkit.createImage(new FilteredImageSource(mrImage.getSource(),
>>>> filter));
>>>>   will be a MRToolkitImage which is based on fixed number of filtered
>>>> resolution variants from the original MRI.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>> ...jim
>>>>>
>>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote:
>>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote:
>>>>>>> Probably we should enhance
>>>>>>> ImageProducer/Tk.createImage/ImageFilter to
>>>>>>> support this functionality? It seems that the number of usage of
>>>>>>> this
>>>>>>> check "image instanceof MultiResolutionImage" will grow over time.
>>>>>>     ImageProducer produces pixels for an image and is not able to
>>>>>> take
>>>>>> an information about the image resolution variants.
>>>>>>
>>>>>>   May be we can add Toolkit.createImage(Image image, ImageFilter
>>>>>> imageFilter) method which takes MultiResolutionImage into account to
>>>>>> cover the common case where filtered image is created.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>> I think that at least our own API should support
>>>>>>> MultiResolutionImage
>>>>>>> w/o such checks, otherwise the user will need to do the same.
>>>>>>>
>>>>>>> cc 2d-dev
>>>>>>>
>>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the fix:
>>>>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8151303
>>>>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00
>>>>>>>>
>>>>>>>>    The AquaUtils does not take into account MultiResolutionImage
>>>>>>>> for
>>>>>>>> selected/disabled/lightened images generation.
>>>>>>>>    The fix also leaves the MultiResolutionCachedImage check because
>>>>>>>> the
>>>>>>>> base system icon size can be differ from the requested painted
>>>>>>>> size.
>>>>>>>>
>>>>>>>>    Thanks,
>>>>>>>>    Alexandr.
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
>


From semyon.sadetsky at oracle.com  Mon Mar 21 19:00:15 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 21 Mar 2016 22:00:15 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56EFFC8A.1010306@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
	<56EFF685.1090702@oracle.com> <56EFFC8A.1010306@oracle.com>
Message-ID: <56F044BF.2000609@oracle.com>



On 3/21/2016 4:52 PM, Sergey Bylokhov wrote:
> On 21.03.16 16:26, Semyon Sadetsky wrote:
>>
>>
>> On 3/19/2016 6:49 PM, Sergey Bylokhov wrote:
>>> On 18.03.16 15:37, Semyon Sadetsky wrote:
>>>> On 3/17/2016 2:46 PM, Sergey Bylokhov wrote:
>>>>> Small notes:
>>>>>  - It will be good to move the code which reads the system properties
>>>>> to the static init block, otherwise we can be in trouble if these
>>>>> properties will be changed at runtime.
>>>> I don't' see any troubles with this. Can you describe the scenario you
>>>> meant?
>>>> I think the properties changing at run-time is useful because it gives
>>>> better control over GTK load. For example, developer may change the
>>>> order to GTK3->GTK2.
>>>
>>> Yes the users can change the property at the beginning of the program
>>> or via command line, but it is not good thing to allow to change it
>>> after unix toolkit is loaded. For example isNativeGTKAvailable() can
>>> check one version of the library, and loadGTK() can try to load
>>> another version, because getEnabledGtkVersion() will return different
>>> values. It belongs to all places where getEnabledGtkVersion() is used.
>> This is the only suspicious scenario but it is unlikely possible.
>> isNativeGTKAvailable() and initialize() are called in the same
>> setLookAndFeel() method. I doubt that somebody will find it sensible to
>> change the jdk.gtk.version concurrently with the setLookAndFeel() call.
>> Even if this happens and GTK becames unavailable the initialize() will
>> throw the same UnsupportedLookAndFeelException exception as in
>> isNativeGTKAvailable() check, so the behavior will correspond to the
>> specification.
>
> But for example getEnabledGtkVersion() is called in the 
> XDesktopPeer.java also. Note that XDesktopPeer and UnixToolkit 
> synchronized differently but but tries to init gtk. It will be safer 
> to remove this possible missconfiguration.
XDesktopPeer loads GTK version. Upon GTK lib was load successfully the 
value of the jdk.gtk.version property doesn't make sense anymore. I 
don't see misconfiguration here.
>
>>>
>>>>>  - Is it necessary to use ordinal? can we replace it with some
>>>>> specific data?(the same for the indexed access in .values()[..])
>>>> In general I'm good. But what specific data you propose?
>>>
>>> And javadoc for ordinal:
>>> "Most programmers will have no use for this method. It is designed for
>>> use by sophisticated enum-based data structures, such as EnumSet and
>>> EnumMap."
>>>
>>> Quote from the internet:
>>> "This is not recommended to use ordinal() (Effective Java, Item 31) as
>>> it relies on the order of the enum values in client's code determine
>>> the ordinal, and any change could lead to bad values being mapped.
>>>
>>> Instead, it would be better to have users implement a method that
>>> would return a unique ID for an enum value. For instance, with an
>>> Identifiable interface that has a unique method id(), that the user
>>> would have to implement for every enum value."
>>>
>> These are related to user's code.
>> In JDK internal code there are plenty usages of ordinal(). In this
>> specific case it is only necessary for transferring the value to the
>> internal native code. But the API never returns ordinal values to user.
>
> Transferring such unstable data to the native is more dangerous than 
> to the user.
Didn't get why is it unstable? This is a constant data.
>
>>
>> --Semyon
>>>>
>>>> --Semyon
>>>>>
>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>> Hi Phil,
>>>>>>
>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>
>>>>>> The updated webrev is
>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>> It also contains:
>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more
>>>>>> but we
>>>>>> can do this later as a separate bug.
>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>>>>>> appearance changes.
>>>>>>
>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>> There is a lot to read here. I think I need to patch and try it but
>>>>>>> first ...
>>>>>>>
>>>>>>> Two high level questions :
>>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>>>>> yet a dependency on GTK and its dependency on xlibraries seems to
>>>>>>> mean
>>>>>>> that you can't load GTK in this case.
>>>>>>> BTW I think it may be painful to get them to layout in such a case
>>>>>>> but that's another issue.
>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>
>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>>
>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know that 
>>>>>>> this
>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>> I will do this before the push. I think it will be OK because I did
>>>>>> not
>>>>>> use any new C constructs and the new libraries are linked 
>>>>>> dynamically.
>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>>>>> regression test suite ?
>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as 
>>>>>> well.
>>>>>> With GTK3 the result was the same except for some unstable tests.
>>>>>> Unity
>>>>>> desktop has new window decorations like borderless windows which are
>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>> scrollbars, etc. Many tests written for old window decorations 
>>>>>> fails.
>>>>>>>
>>>>>>> Minor comments :
>>>>>>>
>>>>>>> GTKEngine.java
>>>>>>>
>>>>>>>  494         Container parent = context.getComponent().getParent();
>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>  496             if (parent != null && parent.getParent() 
>>>>>>> instanceof
>>>>>>> JComboBox) {
>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>  499                 }
>>>>>>>  500             }
>>>>>>>  501         }
>>>>>>>
>>>>>>> GTKPainter.java
>>>>>>>
>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>>>>>  748                 y += 1;
>>>>>>>  749                 h -= 2;
>>>>>>>  750             } else {
>>>>>>>  751                 x += 1;
>>>>>>>  752                 w -= 2;
>>>>>>>  753             }
>>>>>>>  754         }
>>>>>>>
>>>>>>> I don't know where these numbers come from or what coordinate 
>>>>>>> system
>>>>>>> is being used here but it seems you are changing them for gtk 
>>>>>>> 2.2 as
>>>>>>> well as 3
>>>>>>> Can you speak to this ?
>>>>>> It is an appearance tuning for GTK3. I didn't change it for GTK2,
>>>>>> why do
>>>>>> you think so?
>>>>>> This was used before my fix as well, for example
>>>>>>
>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>                          x += (focusSize + 2);
>>>>>>                          y += (focusSize + 1);
>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>                      } else {
>>>>>>                          x += focusSize;
>>>>>>                          y += focusSize;
>>>>>>                          w -= 2 * focusSize;
>>>>>>                          h -= 2 * focusSize;
>>>>>>                      }
>>>>>>
>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>
>>>>>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth",
>>>>>> "slider-length");
>>>>>>
>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>
>>>>>>> GTKStyle.java
>>>>>>>
>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>
>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>
>>>>>>>
>>>>>>> we prefer a space between "if" and "("
>>>>>> Accepted.
>>>>>>>
>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>
>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>
>>>>>>>
>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>>> char*. NULL means that the version is compatible.
>>>>>>>
>>>>>>>  393
>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>>
>>>>>>>  394                 dialog), TRUE);
>>>>>>>
>>>>>>>
>>>>>>> You didn't add this but it is awfully specific about the GTK 
>>>>>>> version
>>>>>>> and
>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>> Accepted.
>>>>>>>
>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>> checking in XToolkit.java
>>>>>>> checked for 3.0 too ..
>>>>>>>
>>>>>>> swing_GTKEngine.c :
>>>>>>>
>>>>>>>   30 /* Static buffer for conversion from java.lang.String to
>>>>>>> UTF-8 */
>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>
>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>> Accepted.
>>>>>>>
>>>>>>> awt_UNIXToolkit.c
>>>>>>>
>>>>>>> < 287 free(ret);
>>>>>>>
>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>> you now expect a boolean return as discussed above and
>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>> The JNI exported method returns boolean while the GTK method returns
>>>>>> char*. free() is deleted intentionally according to the GTK docs it
>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>
>>>>>>> gtk3_interface.h :
>>>>>>>
>>>>>>>   36 #define G_PI 
>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>
>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>> reviewed this yesterday [1].
>>>>>> :) This is glib's definition I just copied.
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> [1] http://www.piday.org/
>>>>>>>
>>>>>>>
>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review fix for JDK9:
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>
>>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>> Also the new system property is added to request specific GTK
>>>>>>>> version
>>>>>>>> swing.gtk.version.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Mon Mar 21 19:20:42 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 22:20:42 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56F044BF.2000609@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
	<56EFF685.1090702@oracle.com> <56EFFC8A.1010306@oracle.com>
	<56F044BF.2000609@oracle.com>
Message-ID: <56F0498A.4090802@oracle.com>

On 21.03.16 22:00, Semyon Sadetsky wrote:
>> But for example getEnabledGtkVersion() is called in the
>> XDesktopPeer.java also. Note that XDesktopPeer and UnixToolkit
>> synchronized differently but but tries to init gtk. It will be safer
>> to remove this possible missconfiguration.
> XDesktopPeer loads GTK version. Upon GTK lib was load successfully the
> value of the jdk.gtk.version property doesn't make sense anymore. I
> don't see misconfiguration here.

XDesktopPeer can start load one version and Unix toolkit can start to 
load another one, because getEnabledGtkVersion() will  return a 
different values. This is a standard approach to read properties in th e 
beginning(like sun.java2d.openg/d3d/xrender, awt.image.incrementaldraw, 
awt.image.redrawrate) and so on.

>>
>> Transferring such unstable data to the native is more dangerous than
>> to the user.
> Didn't get why is it unstable? This is a constant data.

Because the values will be changed if the order of elements in the enum 
will be changed or the new value will be added.

>>
>>>
>>> --Semyon
>>>>>
>>>>> --Semyon
>>>>>>
>>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>>> Hi Phil,
>>>>>>>
>>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>>
>>>>>>> The updated webrev is
>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>>> It also contains:
>>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more
>>>>>>> but we
>>>>>>> can do this later as a separate bug.
>>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>>>>>>> appearance changes.
>>>>>>>
>>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>>> There is a lot to read here. I think I need to patch and try it but
>>>>>>>> first ...
>>>>>>>>
>>>>>>>> Two high level questions :
>>>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>>>>>> yet a dependency on GTK and its dependency on xlibraries seems to
>>>>>>>> mean
>>>>>>>> that you can't load GTK in this case.
>>>>>>>> BTW I think it may be painful to get them to layout in such a case
>>>>>>>> but that's another issue.
>>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>>
>>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>>>
>>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know that
>>>>>>>> this
>>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>>> I will do this before the push. I think it will be OK because I did
>>>>>>> not
>>>>>>> use any new C constructs and the new libraries are linked
>>>>>>> dynamically.
>>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>>>>>> regression test suite ?
>>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as
>>>>>>> well.
>>>>>>> With GTK3 the result was the same except for some unstable tests.
>>>>>>> Unity
>>>>>>> desktop has new window decorations like borderless windows which are
>>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>>> scrollbars, etc. Many tests written for old window decorations
>>>>>>> fails.
>>>>>>>>
>>>>>>>> Minor comments :
>>>>>>>>
>>>>>>>> GTKEngine.java
>>>>>>>>
>>>>>>>>  494         Container parent = context.getComponent().getParent();
>>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>>  496             if (parent != null && parent.getParent()
>>>>>>>> instanceof
>>>>>>>> JComboBox) {
>>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>>  499                 }
>>>>>>>>  500             }
>>>>>>>>  501         }
>>>>>>>>
>>>>>>>> GTKPainter.java
>>>>>>>>
>>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>>>>>>  748                 y += 1;
>>>>>>>>  749                 h -= 2;
>>>>>>>>  750             } else {
>>>>>>>>  751                 x += 1;
>>>>>>>>  752                 w -= 2;
>>>>>>>>  753             }
>>>>>>>>  754         }
>>>>>>>>
>>>>>>>> I don't know where these numbers come from or what coordinate
>>>>>>>> system
>>>>>>>> is being used here but it seems you are changing them for gtk
>>>>>>>> 2.2 as
>>>>>>>> well as 3
>>>>>>>> Can you speak to this ?
>>>>>>> It is an appearance tuning for GTK3. I didn't change it for GTK2,
>>>>>>> why do
>>>>>>> you think so?
>>>>>>> This was used before my fix as well, for example
>>>>>>>
>>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>>                          x += (focusSize + 2);
>>>>>>>                          y += (focusSize + 1);
>>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>>                      } else {
>>>>>>>                          x += focusSize;
>>>>>>>                          y += focusSize;
>>>>>>>                          w -= 2 * focusSize;
>>>>>>>                          h -= 2 * focusSize;
>>>>>>>                      }
>>>>>>>
>>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>>
>>>>>>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth",
>>>>>>> "slider-length");
>>>>>>>
>>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>>
>>>>>>>> GTKStyle.java
>>>>>>>>
>>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>>
>>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>>
>>>>>>>>
>>>>>>>> we prefer a space between "if" and "("
>>>>>>> Accepted.
>>>>>>>>
>>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>>
>>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>>
>>>>>>>>
>>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>>>> char*. NULL means that the version is compatible.
>>>>>>>>
>>>>>>>>  393
>>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>>>>>>>
>>>>>>>>  394                 dialog), TRUE);
>>>>>>>>
>>>>>>>>
>>>>>>>> You didn't add this but it is awfully specific about the GTK
>>>>>>>> version
>>>>>>>> and
>>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>>> Accepted.
>>>>>>>>
>>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>>> checking in XToolkit.java
>>>>>>>> checked for 3.0 too ..
>>>>>>>>
>>>>>>>> swing_GTKEngine.c :
>>>>>>>>
>>>>>>>>   30 /* Static buffer for conversion from java.lang.String to
>>>>>>>> UTF-8 */
>>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>>
>>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>>> Accepted.
>>>>>>>>
>>>>>>>> awt_UNIXToolkit.c
>>>>>>>>
>>>>>>>> < 287 free(ret);
>>>>>>>>
>>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>>> you now expect a boolean return as discussed above and
>>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>>> The JNI exported method returns boolean while the GTK method returns
>>>>>>> char*. free() is deleted intentionally according to the GTK docs it
>>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>>
>>>>>>>> gtk3_interface.h :
>>>>>>>>
>>>>>>>>   36 #define G_PI
>>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>>
>>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>>> reviewed this yesterday [1].
>>>>>>> :) This is glib's definition I just copied.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> [1] http://www.piday.org/
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>>
>>>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>>> Also the new system property is added to request specific GTK
>>>>>>>>> version
>>>>>>>>> swing.gtk.version.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Mon Mar 21 19:30:05 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 21 Mar 2016 22:30:05 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56F0498A.4090802@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
	<56EFF685.1090702@oracle.com> <56EFFC8A.1010306@oracle.com>
	<56F044BF.2000609@oracle.com> <56F0498A.4090802@oracle.com>
Message-ID: <56F04BBD.1030102@oracle.com>



On 3/21/2016 10:20 PM, Sergey Bylokhov wrote:
> On 21.03.16 22:00, Semyon Sadetsky wrote:
>>> But for example getEnabledGtkVersion() is called in the
>>> XDesktopPeer.java also. Note that XDesktopPeer and UnixToolkit
>>> synchronized differently but but tries to init gtk. It will be safer
>>> to remove this possible missconfiguration.
>> XDesktopPeer loads GTK version. Upon GTK lib was load successfully the
>> value of the jdk.gtk.version property doesn't make sense anymore. I
>> don't see misconfiguration here.
>
> XDesktopPeer can start load one version and Unix toolkit can start to 
> load another one, because getEnabledGtkVersion() will  return a 
> different values. This is a standard approach to read properties in th 
> e beginning(like sun.java2d.openg/d3d/xrender, 
> awt.image.incrementaldraw, awt.image.redrawrate) and so on.
This is an another issue unrelated to the property.  XDesktopPeer should 
use the same synchronization monitor for GTK init.
>
>>>
>>> Transferring such unstable data to the native is more dangerous than
>>> to the user.
>> Didn't get why is it unstable? This is a constant data.
>
> Because the values will be changed if the order of elements in the 
> enum will be changed or the new value will be added.
If you meant future code changes, they should be changed synchronously. 
This approach is used everywhere in GTK implementation since there 
plenty different constants that need to be transferred between java and 
the native code.
>
>>>
>>>>
>>>> --Semyon
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>>>> Hi Phil,
>>>>>>>>
>>>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>>>
>>>>>>>> The updated webrev is
>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>>>> It also contains:
>>>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more
>>>>>>>> but we
>>>>>>>> can do this later as a separate bug.
>>>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 
>>>>>>>> 3.10) and
>>>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have 
>>>>>>>> some
>>>>>>>> appearance changes.
>>>>>>>>
>>>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>>>> There is a lot to read here. I think I need to patch and try 
>>>>>>>>> it but
>>>>>>>>> first ...
>>>>>>>>>
>>>>>>>>> Two high level questions :
>>>>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>>>> are supposed to be able to draw off-screen in headless mode .. 
>>>>>>>>> and
>>>>>>>>> yet a dependency on GTK and its dependency on xlibraries seems to
>>>>>>>>> mean
>>>>>>>>> that you can't load GTK in this case.
>>>>>>>>> BTW I think it may be painful to get them to layout in such a 
>>>>>>>>> case
>>>>>>>>> but that's another issue.
>>>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>>>
>>>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>>>>
>>>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know that
>>>>>>>>> this
>>>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>>>> I will do this before the push. I think it will be OK because I 
>>>>>>>> did
>>>>>>>> not
>>>>>>>> use any new C constructs and the new libraries are linked
>>>>>>>> dynamically.
>>>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of 
>>>>>>>>> the
>>>>>>>>> regression test suite ?
>>>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as
>>>>>>>> well.
>>>>>>>> With GTK3 the result was the same except for some unstable tests.
>>>>>>>> Unity
>>>>>>>> desktop has new window decorations like borderless windows 
>>>>>>>> which are
>>>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>>>> scrollbars, etc. Many tests written for old window decorations
>>>>>>>> fails.
>>>>>>>>>
>>>>>>>>> Minor comments :
>>>>>>>>>
>>>>>>>>> GTKEngine.java
>>>>>>>>>
>>>>>>>>>  494         Container parent = 
>>>>>>>>> context.getComponent().getParent();
>>>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>>>  496             if (parent != null && parent.getParent()
>>>>>>>>> instanceof
>>>>>>>>> JComboBox) {
>>>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>>>  499                 }
>>>>>>>>>  500             }
>>>>>>>>>  501         }
>>>>>>>>>
>>>>>>>>> GTKPainter.java
>>>>>>>>>
>>>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>>>  747             if (slider.getOrientation() == 
>>>>>>>>> JSlider.VERTICAL) {
>>>>>>>>>  748                 y += 1;
>>>>>>>>>  749                 h -= 2;
>>>>>>>>>  750             } else {
>>>>>>>>>  751                 x += 1;
>>>>>>>>>  752                 w -= 2;
>>>>>>>>>  753             }
>>>>>>>>>  754         }
>>>>>>>>>
>>>>>>>>> I don't know where these numbers come from or what coordinate
>>>>>>>>> system
>>>>>>>>> is being used here but it seems you are changing them for gtk
>>>>>>>>> 2.2 as
>>>>>>>>> well as 3
>>>>>>>>> Can you speak to this ?
>>>>>>>> It is an appearance tuning for GTK3. I didn't change it for GTK2,
>>>>>>>> why do
>>>>>>>> you think so?
>>>>>>>> This was used before my fix as well, for example
>>>>>>>>
>>>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>>>                          x += (focusSize + 2);
>>>>>>>>                          y += (focusSize + 1);
>>>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>>>                      } else {
>>>>>>>>                          x += focusSize;
>>>>>>>>                          y += focusSize;
>>>>>>>>                          w -= 2 * focusSize;
>>>>>>>>                          h -= 2 * focusSize;
>>>>>>>>                      }
>>>>>>>>
>>>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>>>
>>>>>>>> 1121 CLASS_SPECIFIC_MAP.put("Slider.thumbWidth",
>>>>>>>> "slider-length");
>>>>>>>>
>>>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>>>
>>>>>>>>> GTKStyle.java
>>>>>>>>>
>>>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>>>
>>>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> we prefer a space between "if" and "("
>>>>>>>> Accepted.
>>>>>>>>>
>>>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>>>
>>>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>>>>> char*. NULL means that the version is compatible.
>>>>>>>>>
>>>>>>>>>  393
>>>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  394                 dialog), TRUE);
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You didn't add this but it is awfully specific about the GTK
>>>>>>>>> version
>>>>>>>>> and
>>>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>>>> Accepted.
>>>>>>>>>
>>>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>>>> checking in XToolkit.java
>>>>>>>>> checked for 3.0 too ..
>>>>>>>>>
>>>>>>>>> swing_GTKEngine.c :
>>>>>>>>>
>>>>>>>>>   30 /* Static buffer for conversion from java.lang.String to
>>>>>>>>> UTF-8 */
>>>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>>>
>>>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>>>> Accepted.
>>>>>>>>>
>>>>>>>>> awt_UNIXToolkit.c
>>>>>>>>>
>>>>>>>>> < 287 free(ret);
>>>>>>>>>
>>>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>>>> you now expect a boolean return as discussed above and
>>>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>>>> The JNI exported method returns boolean while the GTK method 
>>>>>>>> returns
>>>>>>>> char*. free() is deleted intentionally according to the GTK 
>>>>>>>> docs it
>>>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>>>
>>>>>>>>> gtk3_interface.h :
>>>>>>>>>
>>>>>>>>>   36 #define G_PI
>>>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>>>
>>>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>>>> reviewed this yesterday [1].
>>>>>>>> :) This is glib's definition I just copied.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>> [1] http://www.piday.org/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>>
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>>>
>>>>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, 
>>>>>>>>>> AWT
>>>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>>>> Also the new system property is added to request specific GTK
>>>>>>>>>> version
>>>>>>>>>> swing.gtk.version.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Mon Mar 21 19:56:45 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 22:56:45 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56F04BBD.1030102@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
	<56EFF685.1090702@oracle.com> <56EFFC8A.1010306@oracle.com>
	<56F044BF.2000609@oracle.com> <56F0498A.4090802@oracle.com>
	<56F04BBD.1030102@oracle.com>
Message-ID: <56F051FD.3000203@oracle.com>

On 21.03.16 22:30, Semyon Sadetsky wrote:
>
>
> On 3/21/2016 10:20 PM, Sergey Bylokhov wrote:
>> On 21.03.16 22:00, Semyon Sadetsky wrote:
>>>> But for example getEnabledGtkVersion() is called in the
>>>> XDesktopPeer.java also. Note that XDesktopPeer and UnixToolkit
>>>> synchronized differently but but tries to init gtk. It will be safer
>>>> to remove this possible missconfiguration.
>>> XDesktopPeer loads GTK version. Upon GTK lib was load successfully the
>>> value of the jdk.gtk.version property doesn't make sense anymore. I
>>> don't see misconfiguration here.
>>
>> XDesktopPeer can start load one version and Unix toolkit can start to
>> load another one, because getEnabledGtkVersion() will  return a
>> different values. This is a standard approach to read properties in th
>> e beginning(like sun.java2d.openg/d3d/xrender,
>> awt.image.incrementaldraw, awt.image.redrawrate) and so on.
> This is an another issue unrelated to the property.  XDesktopPeer should
> use the same synchronization monitor for GTK init.

This does not solve the problem when check/init/load will try to use the 
different versions. I guess I provided enough arguments to initialize 
these data only once.

>>
>>>>
>>>> Transferring such unstable data to the native is more dangerous than
>>>> to the user.
>>> Didn't get why is it unstable? This is a constant data.
>>
>> Because the values will be changed if the order of elements in the
>> enum will be changed or the new value will be added.
> If you meant future code changes, they should be changed synchronously.
> This approach is used everywhere in GTK implementation since there
> plenty different constants that need to be transferred between java and
> the native code.

It will be better to make it obvious and not to depends on some order. I 
am curious where you find it widely used. At least in the client I found 
only one usage.

>>
>>>>
>>>>>
>>>>> --Semyon
>>>>>>>
>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>>>>> Hi Phil,
>>>>>>>>>
>>>>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>>>>
>>>>>>>>> The updated webrev is
>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>>>>> It also contains:
>>>>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more
>>>>>>>>> but we
>>>>>>>>> can do this later as a separate bug.
>>>>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK
>>>>>>>>> 3.10) and
>>>>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have
>>>>>>>>> some
>>>>>>>>> appearance changes.
>>>>>>>>>
>>>>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>>>>> There is a lot to read here. I think I need to patch and try
>>>>>>>>>> it but
>>>>>>>>>> first ...
>>>>>>>>>>
>>>>>>>>>> Two high level questions :
>>>>>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>>>>> are supposed to be able to draw off-screen in headless mode ..
>>>>>>>>>> and
>>>>>>>>>> yet a dependency on GTK and its dependency on xlibraries seems to
>>>>>>>>>> mean
>>>>>>>>>> that you can't load GTK in this case.
>>>>>>>>>> BTW I think it may be painful to get them to layout in such a
>>>>>>>>>> case
>>>>>>>>>> but that's another issue.
>>>>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>>>>
>>>>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>>>>>
>>>>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know that
>>>>>>>>>> this
>>>>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>>>>> I will do this before the push. I think it will be OK because I
>>>>>>>>> did
>>>>>>>>> not
>>>>>>>>> use any new C constructs and the new libraries are linked
>>>>>>>>> dynamically.
>>>>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of
>>>>>>>>>> the
>>>>>>>>>> regression test suite ?
>>>>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as
>>>>>>>>> well.
>>>>>>>>> With GTK3 the result was the same except for some unstable tests.
>>>>>>>>> Unity
>>>>>>>>> desktop has new window decorations like borderless windows
>>>>>>>>> which are
>>>>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>>>>> scrollbars, etc. Many tests written for old window decorations
>>>>>>>>> fails.
>>>>>>>>>>
>>>>>>>>>> Minor comments :
>>>>>>>>>>
>>>>>>>>>> GTKEngine.java
>>>>>>>>>>
>>>>>>>>>>  494         Container parent =
>>>>>>>>>> context.getComponent().getParent();
>>>>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>>>>  496             if (parent != null && parent.getParent()
>>>>>>>>>> instanceof
>>>>>>>>>> JComboBox) {
>>>>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>>>>  499                 }
>>>>>>>>>>  500             }
>>>>>>>>>>  501         }
>>>>>>>>>>
>>>>>>>>>> GTKPainter.java
>>>>>>>>>>
>>>>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>>>>  747             if (slider.getOrientation() ==
>>>>>>>>>> JSlider.VERTICAL) {
>>>>>>>>>>  748                 y += 1;
>>>>>>>>>>  749                 h -= 2;
>>>>>>>>>>  750             } else {
>>>>>>>>>>  751                 x += 1;
>>>>>>>>>>  752                 w -= 2;
>>>>>>>>>>  753             }
>>>>>>>>>>  754         }
>>>>>>>>>>
>>>>>>>>>> I don't know where these numbers come from or what coordinate
>>>>>>>>>> system
>>>>>>>>>> is being used here but it seems you are changing them for gtk
>>>>>>>>>> 2.2 as
>>>>>>>>>> well as 3
>>>>>>>>>> Can you speak to this ?
>>>>>>>>> It is an appearance tuning for GTK3. I didn't change it for GTK2,
>>>>>>>>> why do
>>>>>>>>> you think so?
>>>>>>>>> This was used before my fix as well, for example
>>>>>>>>>
>>>>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>>>>                          x += (focusSize + 2);
>>>>>>>>>                          y += (focusSize + 1);
>>>>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>>>>                      } else {
>>>>>>>>>                          x += focusSize;
>>>>>>>>>                          y += focusSize;
>>>>>>>>>                          w -= 2 * focusSize;
>>>>>>>>>                          h -= 2 * focusSize;
>>>>>>>>>                      }
>>>>>>>>>
>>>>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>>>>
>>>>>>>>> 1121 CLASS_SPECIFIC_MAP.put("Slider.thumbWidth",
>>>>>>>>> "slider-length");
>>>>>>>>>
>>>>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>>>>
>>>>>>>>>> GTKStyle.java
>>>>>>>>>>
>>>>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>>>>
>>>>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> we prefer a space between "if" and "("
>>>>>>>>> Accepted.
>>>>>>>>>>
>>>>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>>>>
>>>>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>>>>>> char*. NULL means that the version is compatible.
>>>>>>>>>>
>>>>>>>>>>  393
>>>>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  394                 dialog), TRUE);
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You didn't add this but it is awfully specific about the GTK
>>>>>>>>>> version
>>>>>>>>>> and
>>>>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>>>>> Accepted.
>>>>>>>>>>
>>>>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>>>>> checking in XToolkit.java
>>>>>>>>>> checked for 3.0 too ..
>>>>>>>>>>
>>>>>>>>>> swing_GTKEngine.c :
>>>>>>>>>>
>>>>>>>>>>   30 /* Static buffer for conversion from java.lang.String to
>>>>>>>>>> UTF-8 */
>>>>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>>>>
>>>>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>>>>> Accepted.
>>>>>>>>>>
>>>>>>>>>> awt_UNIXToolkit.c
>>>>>>>>>>
>>>>>>>>>> < 287 free(ret);
>>>>>>>>>>
>>>>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>>>>> you now expect a boolean return as discussed above and
>>>>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>>>>> The JNI exported method returns boolean while the GTK method
>>>>>>>>> returns
>>>>>>>>> char*. free() is deleted intentionally according to the GTK
>>>>>>>>> docs it
>>>>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>>>>
>>>>>>>>>> gtk3_interface.h :
>>>>>>>>>>
>>>>>>>>>>   36 #define G_PI
>>>>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>>>>
>>>>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>>>>> reviewed this yesterday [1].
>>>>>>>>> :) This is glib's definition I just copied.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>> -phil.
>>>>>>>>>>
>>>>>>>>>> [1] http://www.piday.org/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>>>
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF,
>>>>>>>>>>> AWT
>>>>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>>>>> Also the new system property is added to request specific GTK
>>>>>>>>>>> version
>>>>>>>>>>> swing.gtk.version.
>>>>>>>>>>>
>>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Mon Mar 21 20:38:13 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 21 Mar 2016 23:38:13 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56F051FD.3000203@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
	<56EFF685.1090702@oracle.com> <56EFFC8A.1010306@oracle.com>
	<56F044BF.2000609@oracle.com> <56F0498A.4090802@oracle.com>
	<56F04BBD.1030102@oracle.com> <56F051FD.3000203@oracle.com>
Message-ID: <56F05BB5.2080209@oracle.com>



On 3/21/2016 10:56 PM, Sergey Bylokhov wrote:
> On 21.03.16 22:30, Semyon Sadetsky wrote:
>>
>>
>> On 3/21/2016 10:20 PM, Sergey Bylokhov wrote:
>>> On 21.03.16 22:00, Semyon Sadetsky wrote:
>>>>> But for example getEnabledGtkVersion() is called in the
>>>>> XDesktopPeer.java also. Note that XDesktopPeer and UnixToolkit
>>>>> synchronized differently but but tries to init gtk. It will be safer
>>>>> to remove this possible missconfiguration.
>>>> XDesktopPeer loads GTK version. Upon GTK lib was load successfully the
>>>> value of the jdk.gtk.version property doesn't make sense anymore. I
>>>> don't see misconfiguration here.
>>>
>>> XDesktopPeer can start load one version and Unix toolkit can start to
>>> load another one, because getEnabledGtkVersion() will  return a
>>> different values. This is a standard approach to read properties in th
>>> e beginning(like sun.java2d.openg/d3d/xrender,
>>> awt.image.incrementaldraw, awt.image.redrawrate) and so on.
>> This is an another issue unrelated to the property. XDesktopPeer should
>> use the same synchronization monitor for GTK init.
>
> This does not solve the problem when check/init/load will try to use 
> the different versions. I guess I provided enough arguments to 
> initialize these data only once.
I've already explained that GTK library cannot be loaded twice, only one 
version may be loaded regardless of the property value.
>
>>>
>>>>>
>>>>> Transferring such unstable data to the native is more dangerous than
>>>>> to the user.
>>>> Didn't get why is it unstable? This is a constant data.
>>>
>>> Because the values will be changed if the order of elements in the
>>> enum will be changed or the new value will be added.
>> If you meant future code changes, they should be changed synchronously.
>> This approach is used everywhere in GTK implementation since there
>> plenty different constants that need to be transferred between java and
>> the native code.
>
> It will be better to make it obvious and not to depends on some order. 
> I am curious where you find it widely used. At least in the client I 
> found only one usage.
I can help you. Look at GTKEngine.java: WidgetType, StateType, Settings, 
ShadowType, Orientation, PositionType, etc...
>
>>>
>>>>>
>>>>>>
>>>>>> --Semyon
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>>>>>> Hi Phil,
>>>>>>>>>>
>>>>>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>>>>>
>>>>>>>>>> The updated webrev is
>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>>>>>> It also contains:
>>>>>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require 
>>>>>>>>>> more
>>>>>>>>>> but we
>>>>>>>>>> can do this later as a separate bug.
>>>>>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK
>>>>>>>>>> 3.10) and
>>>>>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have
>>>>>>>>>> some
>>>>>>>>>> appearance changes.
>>>>>>>>>>
>>>>>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>>>>>> There is a lot to read here. I think I need to patch and try
>>>>>>>>>>> it but
>>>>>>>>>>> first ...
>>>>>>>>>>>
>>>>>>>>>>> Two high level questions :
>>>>>>>>>>> 1) Have you verified that this behaves properly (or no worse 
>>>>>>>>>>> than
>>>>>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>>>>>> are supposed to be able to draw off-screen in headless mode ..
>>>>>>>>>>> and
>>>>>>>>>>> yet a dependency on GTK and its dependency on xlibraries 
>>>>>>>>>>> seems to
>>>>>>>>>>> mean
>>>>>>>>>>> that you can't load GTK in this case.
>>>>>>>>>>> BTW I think it may be painful to get them to layout in such a
>>>>>>>>>>> case
>>>>>>>>>>> but that's another issue.
>>>>>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>>>>>
>>>>>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>>>>>> Yes I have. It is identical to the existing GTK2 based 
>>>>>>>>>> appearance.
>>>>>>>>>>>
>>>>>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know that
>>>>>>>>>>> this
>>>>>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>>>>>> I will do this before the push. I think it will be OK because I
>>>>>>>>>> did
>>>>>>>>>> not
>>>>>>>>>> use any new C constructs and the new libraries are linked
>>>>>>>>>> dynamically.
>>>>>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of
>>>>>>>>>>> the
>>>>>>>>>>> regression test suite ?
>>>>>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as
>>>>>>>>>> well.
>>>>>>>>>> With GTK3 the result was the same except for some unstable 
>>>>>>>>>> tests.
>>>>>>>>>> Unity
>>>>>>>>>> desktop has new window decorations like borderless windows
>>>>>>>>>> which are
>>>>>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>>>>>> scrollbars, etc. Many tests written for old window decorations
>>>>>>>>>> fails.
>>>>>>>>>>>
>>>>>>>>>>> Minor comments :
>>>>>>>>>>>
>>>>>>>>>>> GTKEngine.java
>>>>>>>>>>>
>>>>>>>>>>>  494         Container parent =
>>>>>>>>>>> context.getComponent().getParent();
>>>>>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>>>>>  496             if (parent != null && parent.getParent()
>>>>>>>>>>> instanceof
>>>>>>>>>>> JComboBox) {
>>>>>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>>>>>  499                 }
>>>>>>>>>>>  500             }
>>>>>>>>>>>  501         }
>>>>>>>>>>>
>>>>>>>>>>> GTKPainter.java
>>>>>>>>>>>
>>>>>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>>>>>  747             if (slider.getOrientation() ==
>>>>>>>>>>> JSlider.VERTICAL) {
>>>>>>>>>>>  748                 y += 1;
>>>>>>>>>>>  749                 h -= 2;
>>>>>>>>>>>  750             } else {
>>>>>>>>>>>  751                 x += 1;
>>>>>>>>>>>  752                 w -= 2;
>>>>>>>>>>>  753             }
>>>>>>>>>>>  754         }
>>>>>>>>>>>
>>>>>>>>>>> I don't know where these numbers come from or what coordinate
>>>>>>>>>>> system
>>>>>>>>>>> is being used here but it seems you are changing them for gtk
>>>>>>>>>>> 2.2 as
>>>>>>>>>>> well as 3
>>>>>>>>>>> Can you speak to this ?
>>>>>>>>>> It is an appearance tuning for GTK3. I didn't change it for 
>>>>>>>>>> GTK2,
>>>>>>>>>> why do
>>>>>>>>>> you think so?
>>>>>>>>>> This was used before my fix as well, for example
>>>>>>>>>>
>>>>>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>>>>>                          x += (focusSize + 2);
>>>>>>>>>>                          y += (focusSize + 1);
>>>>>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>>>>>                      } else {
>>>>>>>>>>                          x += focusSize;
>>>>>>>>>>                          y += focusSize;
>>>>>>>>>>                          w -= 2 * focusSize;
>>>>>>>>>>                          h -= 2 * focusSize;
>>>>>>>>>>                      }
>>>>>>>>>>
>>>>>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>>>>>
>>>>>>>>>> 1121 CLASS_SPECIFIC_MAP.put("Slider.thumbWidth",
>>>>>>>>>> "slider-length");
>>>>>>>>>>
>>>>>>>>>>   in GTKStyle.java, because this property was omitted by 
>>>>>>>>>> mistake.
>>>>>>>>>>>
>>>>>>>>>>> GTKStyle.java
>>>>>>>>>>>
>>>>>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>>>>>
>>>>>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> we prefer a space between "if" and "("
>>>>>>>>>> Accepted.
>>>>>>>>>>>
>>>>>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>>>>>
>>>>>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It 
>>>>>>>>>> returns
>>>>>>>>>> char*. NULL means that the version is compatible.
>>>>>>>>>>>
>>>>>>>>>>>  393
>>>>>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  394                 dialog), TRUE);
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You didn't add this but it is awfully specific about the GTK
>>>>>>>>>>> version
>>>>>>>>>>> and
>>>>>>>>>>> I wonder if this test is doing what it should be doing on 
>>>>>>>>>>> GTK 3?
>>>>>>>>>> Accepted.
>>>>>>>>>>>
>>>>>>>>>>> It is interesting that some equivalent looking Java level 
>>>>>>>>>>> dialog
>>>>>>>>>>> checking in XToolkit.java
>>>>>>>>>>> checked for 3.0 too ..
>>>>>>>>>>>
>>>>>>>>>>> swing_GTKEngine.c :
>>>>>>>>>>>
>>>>>>>>>>>   30 /* Static buffer for conversion from java.lang.String to
>>>>>>>>>>> UTF-8 */
>>>>>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>>>>>
>>>>>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>>>>>> Accepted.
>>>>>>>>>>>
>>>>>>>>>>> awt_UNIXToolkit.c
>>>>>>>>>>>
>>>>>>>>>>> < 287 free(ret);
>>>>>>>>>>>
>>>>>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>>>>>> you now expect a boolean return as discussed above and
>>>>>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>>>>>> The JNI exported method returns boolean while the GTK method
>>>>>>>>>> returns
>>>>>>>>>> char*. free() is deleted intentionally according to the GTK
>>>>>>>>>> docs it
>>>>>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>>>>>
>>>>>>>>>>> gtk3_interface.h :
>>>>>>>>>>>
>>>>>>>>>>>   36 #define G_PI
>>>>>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>>>>>
>>>>>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>>>>>> reviewed this yesterday [1].
>>>>>>>>>> :) This is glib's definition I just copied.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>> -phil.
>>>>>>>>>>>
>>>>>>>>>>> [1] http://www.piday.org/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>>>>
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>>>>>> webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF,
>>>>>>>>>>>> AWT
>>>>>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>>>>>> Also the new system property is added to request specific GTK
>>>>>>>>>>>> version
>>>>>>>>>>>> swing.gtk.version.
>>>>>>>>>>>>
>>>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/69c7f1a7/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Mar 21 20:38:59 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Mar 2016 23:38:59 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56F0082C.5020503@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F0082C.5020503@oracle.com>
Message-ID: <56F05BE3.20601@oracle.com>

On 21.03.16 17:41, Alexander Scherbatiy wrote:
>
> On 18/03/16 19:49, Alexander Scherbatiy wrote:
>>
>> Could you review the updated fix:
>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>
>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>> package
>>   - TextUIDrawing methods description does not mention component
>> properties to be more general
>>   - TextUIDrawing methods are made default
>>   - L&F sets an instance of the TextUIDrawing to look and feel
>> defaults using "uiDrawing.text" property
>>   - ComponentUI class is not changed
>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>   - There is an interesting issue described in
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>>     which is related to the fact that MetalLabelUI returns a static
>> field from createUI() method.
>>     TitleBorder creates a JLabel but does not put it to any component
>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() method
>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>> label UI is not changed in this case and it still uses the
>> metalLabelUI field which is not initialized.
>>     It seems that other applications can also use components just for
>> drawing and have the same issue.
>>     For this case the textUIDrawing field is not cleared in the
>> uninstallDefaults but just set to a static default value which should
>> not lead to memory leaks.
>
>    I used JMH for an average time measuring of a test method which calls
> text UI drawing class from a SynthLookAndFeel method:
> ------------
>      @Benchmark
>      @BenchmarkMode(Mode.SampleTime)
>      @OutputTimeUnit(TimeUnit.MICROSECONDS)
>      public void testDrawMethod() throws Exception {
>          int N = 10000;
>          JComponent component = new JLabel(TEXT);
>          SynthGraphicsUtils synthGrapicsUtils = new SynthGraphicsUtils();
>          ...
>          for (int i = 0; i < N; i++) {
>              synthGrapicsUtils.computeStringWidth(synthContext, font,
> fontMetrics, TEXT);
>              synthGrapicsUtils.paintText(synthContext, g, TEXT, 10, 10, 0);
>          }
>      }
>    ------------
>
>    Here is the full code of the tested method:
> http://cr.openjdk.java.net/~alexsch/8132119/jmh/test.00/TextUIDrawingBenchmark.java
>
>
>   I used 3 samples with different JDK:
>   Sample 1: JDK without fixes
>   Sample 2: JDK where instance of TextUIDrawing class is placed in base
> ComponentUI class.
>   Sample 3: JDK where instance of TextUIDrawing is loaded for each
> necessary UI class from UIManager "uiDrawing.text" property.

can you please provide the second patch as well?

>
>   In the Sample 2 SynthGraphicsUtils retrieves a TextUIDrawing instance
> from the provided JComponent.getUI() class.
>   In the Sample 3 SynthGraphicsUtils gets a TextUIDrawing instance from
> UIManager property.
>
>   The calculated average time in microseconds is:
>   Sample 1: 20976.041 ? 60.181
>   Sample 2: 21556.180 ? 89.476
>   Sample 3: 23607.186 ? 62.319
>
>   If just roughly use a formula like:
>     method_time = initialization_time + loop_count *
> (time_for_same_operation + time_for different_operations)
>   it is possible to get a time estimation for different operation like:
> (method_time2 - method_time1) / loop_count
>
>   Such time difference calculation gives:
>   0.08 microseconds for Sample 2
>   0.26 microseconds for Sample 3
>
>   Thanks,
>   Alexandr.
>
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>> Hi Alexandr,
>>>>
>>>>> Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>> ....
>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>> package
>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>>> ComponentUI class
>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>> defaults using
>>>>> "uiDrawing.text" property
>>>>> - Look and Feel delegates use the instance of the TextUIDrawing for
>>>>> text
>>>>> drawing and measuring
>>>> Some thoughts on the current design/implementation:
>>>>
>>>> By adding a field to the ComponentUI class the current
>>>> implementation increases
>>>> memory consumption for all Swing applications. And you get the
>>>> feeling that
>>>> there are different implementations of TextUIDrawing per ComponentUI
>>>> instances.
>>>> Personally I can't imagine to have different implementations of
>>>> TextUIDrawing for
>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>> implement it as
>>>> a property of the LookAndFeel class (similar to LayoutStyle) and not
>>>> the ComponentUI.
>>>> Developers can use then the following code to obtain the instance of
>>>> TextUIDrawing:
>>>>
>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>> short cut for the line above.
>>>   LayoutStyle keeps its instance per App context. The same is for the
>>> LookAndFeel
>>>   when it is got through UIManager.getLookAndFeel() call.
>>>   It means that accessing an instance of a TextUIDrawing will leads
>>> to a time consumption.
>>>
>>>   There are 3 main ways of the SwingUtilities2.drawString(...) usage:
>>>   1. ComponentUI classes
>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>   3. Public utilities methods (like WindowsGraphicsUtils.paintText())
>>>
>>>   For the cases 1 and 2 it is possible to load and store the
>>> UIDrawing instance during installUI()/updateUI() calls to decrease a
>>> time access to it.
>>>
>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>> time (which is taken from an App context)
>>>   or use the passed JComponent object. It requires to have a public
>>> method and the associated variable for each instance of
>>> JComponent/ComponentUI/... class.
>>>> You can use this methods then in JDK too.
>>>>
>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>> more useful methods,
>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>> to pixels.
>>>   UIDrawing name may look like it should be used for any UI drawing,
>>> not only for text ones. I am afraid that it can be misleading.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>>
>>>> Best regards,
>>>> Andrej Golovnin
>>>
>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Mon Mar 21 21:09:37 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Mon, 21 Mar 2016 14:09:37 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56F05BE3.20601@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F0082C.5020503@oracle.com> <56F05BE3.20601@oracle.com>
Message-ID: <56F06311.8030909@oracle.com>

On 3/21/2016 1:38 PM, Sergey Bylokhov wrote:
> On 21.03.16 17:41, Alexander Scherbatiy wrote:
>>
>> On 18/03/16 19:49, Alexander Scherbatiy wrote:
>>>
>>> Could you review the updated fix:
>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>
>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>> package
>>>   - TextUIDrawing methods description does not mention component
>>> properties to be more general
>>>   - TextUIDrawing methods are made default
>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>> defaults using "uiDrawing.text" property
>>>   - ComponentUI class is not changed
>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>   - There is an interesting issue described in
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>>>     which is related to the fact that MetalLabelUI returns a static
>>> field from createUI() method.
>>>     TitleBorder creates a JLabel but does not put it to any component
>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() method
>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>> label UI is not changed in this case and it still uses the
>>> metalLabelUI field which is not initialized.
>>>     It seems that other applications can also use components just for
>>> drawing and have the same issue.
>>>     For this case the textUIDrawing field is not cleared in the
>>> uninstallDefaults but just set to a static default value which should
>>> not lead to memory leaks.
>>
>>    I used JMH for an average time measuring of a test method which calls
>> text UI drawing class from a SynthLookAndFeel method:
>> ------------
>>      @Benchmark
>>      @BenchmarkMode(Mode.SampleTime)
>>      @OutputTimeUnit(TimeUnit.MICROSECONDS)
>>      public void testDrawMethod() throws Exception {
>>          int N = 10000;
>>          JComponent component = new JLabel(TEXT);
>>          SynthGraphicsUtils synthGrapicsUtils = new 
>> SynthGraphicsUtils();
>>          ...
>>          for (int i = 0; i < N; i++) {
>>              synthGrapicsUtils.computeStringWidth(synthContext, font,
>> fontMetrics, TEXT);
>>              synthGrapicsUtils.paintText(synthContext, g, TEXT, 10, 
>> 10, 0);
>>          }
>>      }
>>    ------------
>>
>>    Here is the full code of the tested method:
>> http://cr.openjdk.java.net/~alexsch/8132119/jmh/test.00/TextUIDrawingBenchmark.java 
>>
>>
>>
>>   I used 3 samples with different JDK:
>>   Sample 1: JDK without fixes
>>   Sample 2: JDK where instance of TextUIDrawing class is placed in base
>> ComponentUI class.
>>   Sample 3: JDK where instance of TextUIDrawing is loaded for each
>> necessary UI class from UIManager "uiDrawing.text" property.
>
> can you please provide the second patch as well?

   Sample 2: http://cr.openjdk.java.net/~alexsch/8132119/webrev.07
   Sample 3: http://cr.openjdk.java.net/~alexsch/8132119/webrev.08

   Thanks,
   Alexandr.
>
>>
>>   In the Sample 2 SynthGraphicsUtils retrieves a TextUIDrawing instance
>> from the provided JComponent.getUI() class.
>>   In the Sample 3 SynthGraphicsUtils gets a TextUIDrawing instance from
>> UIManager property.
>>
>>   The calculated average time in microseconds is:
>>   Sample 1: 20976.041 ? 60.181
>>   Sample 2: 21556.180 ? 89.476
>>   Sample 3: 23607.186 ? 62.319
>>
>>   If just roughly use a formula like:
>>     method_time = initialization_time + loop_count *
>> (time_for_same_operation + time_for different_operations)
>>   it is possible to get a time estimation for different operation like:
>> (method_time2 - method_time1) / loop_count
>>
>>   Such time difference calculation gives:
>>   0.08 microseconds for Sample 2
>>   0.26 microseconds for Sample 3
>>
>>   Thanks,
>>   Alexandr.
>>
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>> Hi Alexandr,
>>>>>
>>>>>> Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>> ....
>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>> package
>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>>>> ComponentUI class
>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>> defaults using
>>>>>> "uiDrawing.text" property
>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing for
>>>>>> text
>>>>>> drawing and measuring
>>>>> Some thoughts on the current design/implementation:
>>>>>
>>>>> By adding a field to the ComponentUI class the current
>>>>> implementation increases
>>>>> memory consumption for all Swing applications. And you get the
>>>>> feeling that
>>>>> there are different implementations of TextUIDrawing per ComponentUI
>>>>> instances.
>>>>> Personally I can't imagine to have different implementations of
>>>>> TextUIDrawing for
>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>> implement it as
>>>>> a property of the LookAndFeel class (similar to LayoutStyle) and not
>>>>> the ComponentUI.
>>>>> Developers can use then the following code to obtain the instance of
>>>>> TextUIDrawing:
>>>>>
>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>> short cut for the line above.
>>>>   LayoutStyle keeps its instance per App context. The same is for the
>>>> LookAndFeel
>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>   It means that accessing an instance of a TextUIDrawing will leads
>>>> to a time consumption.
>>>>
>>>>   There are 3 main ways of the SwingUtilities2.drawString(...) usage:
>>>>   1. ComponentUI classes
>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>   3. Public utilities methods (like WindowsGraphicsUtils.paintText())
>>>>
>>>>   For the cases 1 and 2 it is possible to load and store the
>>>> UIDrawing instance during installUI()/updateUI() calls to decrease a
>>>> time access to it.
>>>>
>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>> time (which is taken from an App context)
>>>>   or use the passed JComponent object. It requires to have a public
>>>> method and the associated variable for each instance of
>>>> JComponent/ComponentUI/... class.
>>>>> You can use this methods then in JDK too.
>>>>>
>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>> more useful methods,
>>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>>> to pixels.
>>>>   UIDrawing name may look like it should be used for any UI drawing,
>>>> not only for text ones. I am afraid that it can be misleading.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>>
>>>>> Best regards,
>>>>> Andrej Golovnin
>>>>
>>>
>>
>
>



From semyon.sadetsky at oracle.com  Tue Mar 22 06:11:56 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 22 Mar 2016 09:11:56 +0300
Subject: <Swing Dev> [9] Review Request: 8144166 [macosx] Test
 java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java
 fails
In-Reply-To: <56E29283.9060906@oracle.com>
References: <56E1DA78.1080000@oracle.com> <56E265F6.5020800@oracle.com>
	<56E29283.9060906@oracle.com>
Message-ID: <56F0E22C.3090404@oracle.com>

On 3/11/2016 12:40 PM, Sergey Bylokhov wrote:
> On 11.03.16 9:30, Semyon Sadetsky wrote:
>> Hi Sergey,
>>
>> Could you explain why do you suppose that the icon cannot be requested
>> more then once between the frame minimize and restore?
>
> Every time when the frame is minimized the new 
> AquaInternalFrameDockIconUI is created. Every 
> AquaInternalFrameDockIconUI have its own ScaledImageLabel(which is 
> JLabel). At the beginning this label is initialized by the icon from 
> the cache, and this label is used until the frame is restored(cache is 
> not used).
What if user requests the dock icon to paint it somewhere else while the 
frame is hidden? Before the fix the user got the same icon image from 
the cache, but after the fix he gets another image because it is being 
re-created on each paint. So it becomes impossible to paint the same 
icon that is shown in the dock currently.
>
>>
>>  > The bug is in the last step. When the frame will be minimized in the
>> second time, it can have another content. But minimized icon
>>  > will show the miniature from the previous minimization...
>> Doesn't it contradict with :
>>  >    * If the frame will be resized/show the cache will be reset.
>> ?
>>
>> --Semyon
>>
>> On 3/10/2016 11:35 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk9.
>>>
>>> Problem description:
>>>  - CompEventOnHiddenComponent test was written not according the
>>> specification but according an assumption(performance related) - "the
>>> component should not post move/resize events if no listeners were
>>> registered". The test creates a JInternalFrame and adds
>>> ComponentListener to it. No events should come to the listeners,
>>> because the frame is not resized or moved by the test(except initial
>>> layout). Initial move/resize events are skipped usually, because
>>> during initialization there are no any listeners. But this is not the
>>> case in Aqua. AquaInternalFrameDockIconUI adds a listeners to the
>>> JInternalFrame during initialization -> move/resize events are posted
>>> -> the test adds own listeners -> events dispatched -> the test
>>> listeners called -> boom.
>>>
>>> According above description the bug could be closed as not a defect.
>>> But I found another related problem in the AquaInternalFrameDockIconUI.
>>>
>>>  - These component listeners in AquaInternalFrameDockIconUI are used
>>> to maintain the cache of image for the dock(the icon which is used
>>> when the internal frame is minimized). The logic is next:
>>>    * Before the frame will be minimized it draws to the special
>>> ImageIcon which will be used as an icon for the dock.
>>>    * After the frame is minimized and dock is showing the saved image
>>> will be used(and placed to the cache)
>>>    * If the frame will be resized/show the cache will be reset.
>>>    * When in the next time the same frame will be minimized the cached
>>> image will be used.
>>>
>>> The bug is in the last step. When the frame will be minimized in the
>>> second time, it can have another content. But minimized icon will show
>>> the miniature from the previous minimization. Note this is the only
>>> step where the cache is used.
>>>
>>> Solution:
>>> As a solution all cache related stuff were dropped. The new test was
>>> added.
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144166
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8144166/webrev.01
>>>
>>
>
>



From shaik.ahmad at oracle.com  Tue Mar 22 06:13:56 2016
From: shaik.ahmad at oracle.com (Ahmad Ahmad)
Date: Mon, 21 Mar 2016 23:13:56 -0700 (PDT)
Subject: <Swing Dev> RFR JDK-8143021: [TEST_BUG] Test
 javax/swing/JColorChooser/Test6541987.java fails for Ubuntu 15.10
Message-ID: <b5953f3f-8443-402a-8cd2-8d9c16b12aa1@default>

Hello,

 

Please review fix for JDK9 test bug.

 

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

Webrev: http://cr.openjdk.java.net/~srastogi/shaik/webrev.01/

 

Issue:

java.lang.Error: found visible window: frame0 

at Test6541987.main(Test6541987.java:64)

 

Cause:

Test is failing in Ubuntu OS as intermittently due to frame is visible but ideally all windows should be closed, introduced delay to solve the issue.

 

Fix:

Beside reported issue in the bug, When I tested on Mac OS, Test never passed due to ALT + H + 4 TABs still keep the focus in the slider and not on spinner but the actual test is all about ensuring JColorChooser disappears when pressing esc, keeping the focus on the spinner.

 

Test verified in Mac OS, Windows, OEL and Ubuntu.

 

Thanks & Regards

Shaik Ahmad

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160321/f49837ff/attachment.html>

From avik.niyogi at oracle.com  Tue Mar 22 07:38:31 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 22 Mar 2016 13:08:31 +0530
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
	javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java
	fails with GTK LnF
In-Reply-To: <56F0072E.9070800@oracle.com>
References: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
	<56E17C34.5030303@oracle.com>
	<8AE0341F-6D3A-4586-B7CC-38318B986450@oracle.com>
	<2DD39FDD-D8C9-47B6-BAAB-D1AEA0A22DF6@oracle.com>
	<56EC68F6.5000106@oracle.com>
	<F78727F3-6931-4A40-A949-45EC3C716614@oracle.com>
	<56F0072E.9070800@oracle.com>
Message-ID: <9704F43B-38E3-4E53-9801-039731984330@oracle.com>

Hi All,
Please find webrev with new code fix:
http://cr.openjdk.java.net/~aniyogi/8151282/webrev.02/ <http://cr.openjdk.java.net/~aniyogi/8151282/webrev.02/>

With Regards,
Avik Niyogi

> On 21-Mar-2016, at 8:07 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Avik.
> How this test can fail? I do not see any raised exceptions.
> 
> On 21.03.16 9:46, Avik Niyogi wrote:
>> Hi Sergey,
>> Please review the following code change.
>> With Regards,
>> Avik Niyogi
>>> On 19-Mar-2016, at 2:15 am, Alexander Scherbatiy
>>> <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>> <mailto:alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>> wrote:
>>> 
>>> The fix looks good to me.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 14/03/16 16:25, Avik Niyogi wrote:
>>>> Hi All,
>>>> Please review code changes made as per inputs provided.
>>>> 
>>>> http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/>
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.01/ <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.01/>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 14-Mar-2016, at 10:53 am, Avik Niyogi
>>>>> <<mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>> 
>>>>> Hi Sergey,
>>>>> Seems like it is a delay issue. Will submit test case with a
>>>>> waitForIdle() fix.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov
>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>>>>>> 
>>>>>> Hi, Avik.
>>>>>> A few questions.
>>>>>> - Why webrev contains the new file?
>>>>>> - You marked the test as a mac specific but it is iterates over a
>>>>>> bunch of l&fs. It seems it should not be OS specific, but should
>>>>>> check some specific l&fs (which support such icons): Metal, Nimbus,
>>>>>> Aqua, Windows(???). So gtk/motif should be skipped.
>>>>>> 
>>>>>> On 08.03.16 8:10, Avik Niyogi wrote:
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>> 
>>>>>>> *Bug:*
>>>>>>> 
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151282
>>>>>>> 
>>>>>>> *Webrev:*
>>>>>>> 
>>>>>>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
>>>>>>> _
>>>>>>> _
>>>>>>> *Issue:*
>>>>>>> The test case failed for GTK LAF.
>>>>>>> 
>>>>>>> *Cause:*
>>>>>>> The test case was meant to be Mac specific and was missing a jtreg
>>>>>>> parameter
>>>>>>> 
>>>>>>> *Fix:*
>>>>>>> Minor change to test case with @requires tag added to set the fix.
>>>>>>> 
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160322/e8aa906e/attachment.html>

From rajeev.chamyal at oracle.com  Tue Mar 22 08:35:37 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 22 Mar 2016 01:35:37 -0700 (PDT)
Subject: <Swing Dev> [9] Review request for JDK-8150225
 api/javax_swing/text/AbstractWriter/index_indent failed
In-Reply-To: <195b6aa5-1959-467e-826b-ce98377e392a@default>
References: <d57da090-134d-4840-87d5-fbfc73027061@default>
	<56DFF9BF.6080205@oracle.com>
	<195b6aa5-1959-467e-826b-ce98377e392a@default>
Message-ID: <53d0d59a-1266-4b0b-b2e8-d74ca78b8144@default>

Hello All,

Gentle reminder.
Please review the fix.

Bug : https://bugs.openjdk.java.net/browse/JDK-8150225 
Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/ 

Regards,
Rajeev Chamyal

-----Original Message-----
From: Rajeev Chamyal 
Sent: 09 March 2016 15:58
To: Sergey Bylokhov; Alexander Scherbatiy; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed

Hello Sergey,

I have run JCK tests for HTMLWriter and AbstractWriter with this fix and all passed.

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov
Sent: 09 March 2016 15:54
To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed

Hi, Rajeev.
Please confirm that there are no new issues in the jck after this fix.

On 09.03.16 12:18, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225
>
> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/
> <http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/>
>
> Issue : JCK conformance test failed due to fix for bug JDK-7104635
>
> Fix: Reverted the fix for JDK-7104635 and added a new method in 
> HTMLWriter.java to check if P tag is within Pre tag.
>
> Decrement indentation is skipped if P tag is with a Pre tag.
>
> Regards,
>
> Rajeev Chamyal
>


--
Best regards, Sergey.


From prem.balakrishnan at oracle.com  Tue Mar 22 08:56:38 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Tue, 22 Mar 2016 01:56:38 -0700 (PDT)
Subject: <Swing Dev> Review Request for 6439354 : Win L&F: TitledBorder
 colors are not from desktop
In-Reply-To: <56EFFEA6.7040408@oracle.com>
References: <9dfecb85-567d-410c-b60a-9b8976521e55@default>
	<56EFFEA6.7040408@oracle.com>
Message-ID: <34d597fe-a34e-4693-b2cb-3e4dbe0b746a@default>

Hi Sergey,

Updated test as per the review comments.

Webrev: http://cr.openjdk.java.net/~arapte/prem/6439354/webrev.01/ 

Regards,
Prem


-----Original Message-----
From: Sergey Bylokhov 
Sent: Monday, March 21, 2016 7:31 PM
To: Prem Balakrishnan; Semyon Sadetsky; Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net
Subject: Re: Review Request for 6439354 : Win L&F: TitledBorder colors are not from desktop

Hi, Prem.
In the test the Swing components accessed on non-EDT thread. Probably the test can be simplified further?

On 21.03.16 11:20, Prem Balakrishnan wrote:
> Hi*,*
>
> Please review fix for JDK 9,
>
> *Bug: *https://bugs.openjdk.java.net/browse/JDK-6439354 **
>
> *Webrev: *http://cr.openjdk.java.net/~arapte/prem/6439354/webrev.00/
>
> *Issue:*
>
> Win L&F: TitledBorder colors are not from desktop
>
> *Cause:*
>
> "TitledBorder.border" is set to EtchedBorder with default 
> highlight/shadow colors.
>
> *Fix:*
>
> "TitledBorder.border" is set to  EtchedBorder with Desktop
>   highlight/shadow colors.
>
> **
>
> *Test: *Manual Test (since windows theme to be set)**
>
> **
>
> Regards,
> Prem
>


--
Best regards, Sergey.


From rajeev.chamyal at oracle.com  Tue Mar 22 11:25:39 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 22 Mar 2016 04:25:39 -0700 (PDT)
Subject: <Swing Dev> Review request for JDK-8075084
 JOptionPane.showMessageDialog causes JScrollBar to move
In-Reply-To: <569678A3.6090500@oracle.com>
References: <556d6cec-a723-42a4-a96a-dc22b7d2f112@default>
	<565EAB0D.4070406@oracle.com>
	<745c79a4-6692-4b5c-9c81-ae10332c248d@default>
	<566961E8.1020806@oracle.com>
	<0101fe6a-0bfe-44e5-9bd4-4c470160024a@default>
	<56788E7A.4020601@oracle.com>
	<d1a90ca8-a85e-4ab5-9cd1-bc99ded86f81@default>
	<567D6D12.70806@oracle.com>
	<6a9ba228-fbfb-41d8-bb59-01f98f449a0a@default>
	<3396fa45-2f9d-4c1b-8d4c-dc30e1ce751e@default>
	<569678A3.6090500@oracle.com>
Message-ID: <fe80f065-ae27-49c5-815f-34708b85e91b@default>

Hello All,

Please review the re-worked fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8075084
Webrev : http://cr.openjdk.java.net/~rchamyal/8075084/webrev.03/

In the updated fix a global awt event listener has been added to BasicScrollBarUI to take actions on mouse events.
The awt event listener determines the state of arrow buttons and source of mouse events and based on these it stops the timer.

Regards,
Rajeev Chamyal


 -----Original Message-----
From: Alexander Scherbatiy 
Sent: 13 January 2016 21:48
To: Rajeev Chamyal
Cc: Sergey Bylokhov; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review request for JDK-8075084 JOptionPane.showMessageDialog causes JScrollBar to move

On 1/12/2016 5:28 PM, Rajeev Chamyal wrote:
> Hello All,
>
> Gentle reminder to review the fix.
> http://cr.openjdk.java.net/~rchamyal/8075084/webrev.02/

    My impression was that the scroll timer is started before an adjustment listener is executed. In this case the timer can track the open modal dialog and be stopped.
    It looks like the real situation is opposite and the scroll timer should track the closed modal dialog which is not reliable because it is possible to press and hold  a scroll thumb on another scrollbar and it will detect the closed modal dialog too.

    If I am correct for the first version of the fix the mouse release and exit events can be still missed if a modal dialog is shown outside the scroll bar.

    I do not have a good idea how the mouse exit event can be caught in this case when a modal dialog is shown.
    May be it possible to add a counter of mouse release events to the toolkit (or read it by AWTEventListener).
    If number of mouse release events are different before the scroll bar  adjustment listener is executed and after that it means that mouse was released on a modal dialog or missed by some other reason.

   Thanks,
   Alexandr.

>
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Rajeev Chamyal
> Sent: 27 December 2015 20:32
> To: Sergey Bylokhov
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> Review request for JDK-8075084 
> JOptionPane.showMessageDialog causes JScrollBar to move
>
> Hello Sergey,
>
> The first webrev version is implemented on similar lines as you suggested but it had issues as pointed my Alexandr in his review below.
> If the mouse pointer after clicking on modal dialog close lies outside the parent window then parent window is not getting any mouse events and BasicScrollBarUI::scrollByUnit method is again getting called recursively, Because of which the scroll bar pointer keeps on moving till the end of scrollbar.
> With this new implementation these issue are not seen.
>
> Regards,
> Rajeev Chamyal
>
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 25 December 2015 21:52
> To: Rajeev Chamyal; Alexander Scherbatiy
> Cc: Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8075084 
> JOptionPane.showMessageDialog causes JScrollBar to move
>
> Probably this bug can be fixed in a different way. Is it possible to check the state of the scroll bar in the timer? And if in some iteration the button became unpressed then stops itself(timer).
>
> On 23/12/15 12:29, Rajeev Chamyal wrote:
>> Hello Alexandr,
>>
>> The modal dialog can be application modal, document modal and toolkit modal.
>>        1) Application-modal dialog box blocks all windows from the same application, except windows from its child hierarchy
>>        2) Document-modal dialog box blocks all windows from the same document, except windows from its child hierarchy.
>>        3) Toolkit-modal dialog box blocks all windows that run in the 
>> same toolkit, except windows from its child hierarchy
>>
>> The current issue is reproducible with all modal dialog types. I have updated the condition in code to check for modal dialogs.
>>
>> http://cr.openjdk.java.net/~rchamyal/8075084/webrev.02/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexander Scherbatiy
>> Sent: 22 December 2015 05:13
>> To: Rajeev Chamyal
>> Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>> Subject: Re: Review request for JDK-8075084 
>> JOptionPane.showMessageDialog causes JScrollBar to move
>>
>> On 21/12/15 12:21, Rajeev Chamyal wrote:
>>> Hello Alexandr,
>>>
>>> I have updated the fix. Please review it.
>>> http://cr.openjdk.java.net/~rchamyal/8075084/webrev.01/
>>       When a modal dialog is shown does it block all windows or is it possible that a modal dialog blocks some windows and does not block others?
>>
>>     Thanks,
>>     Alexandr.
>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Alexander Scherbatiy
>>> Sent: 10 December 2015 16:59
>>> To: Rajeev Chamyal
>>> Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>>> Subject: Re: Review request for JDK-8075084 
>>> JOptionPane.showMessageDialog causes JScrollBar to move
>>>
>>> On 12/3/2015 11:08 AM, Rajeev Chamyal wrote:
>>>> Hello Alexandr,
>>>>
>>>> Thanks for the review.
>>>>
>>>> When we open a JOption dialog from AdjustmentListener the scroll 
>>>> bar arrow button is not receiving the mouse release event.
>>>>
>>>> As a result the JScrollBar: scrollTimer is not getting stopped and 
>>>> its becoming a recursive call.
>>>>
>>>        I tried to run the BuggyDialog sample form the issue description with the suggested fix.
>>>        I noticed a strange behavior when I press scroll down and click not on the JOptionPane OK button but on the close button.
>>>        The scroll bar continues scrolling in this case.
>>>
>>>        When a modal dialog is open it blocks others windows. Is it possible to check this event and stop the scroll timer in this case?
>>>
>>>       Thanks,
>>>       Alexandr.
>>>
>>>> Regards,
>>>>
>>>> Rajeev Chamyal
>>>>
>>>> *From:*Alexandr Scherbatiy
>>>> *Sent:* 02 December 2015 13:56
>>>> *To:* Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan; 
>>>> swing-dev at openjdk.java.net
>>>> *Subject:* Re: Review request for JDK-8075084 
>>>> JOptionPane.showMessageDialog causes JScrollBar to move
>>>>
>>>> On 11/11/2015 7:47 AM, Rajeev Chamyal wrote:
>>>>
>>>>        Hello All,
>>>>
>>>>        Please review the following fix for Jdk9:
>>>>
>>>>
>>>>
>>>>        Bug:https://bugs.openjdk.java.net/browse/JDK-8075084
>>>>
>>>>        Webrev:http://cr.openjdk.java.net/~rchamyal/8075084/webrev.00/
>>>>        <http://cr.openjdk.java.net/%7Erchamyal/8075084/webrev.00/>
>>>>
>>>>        Issue: On running the sample program attached in bug JDK-8075084
>>>>        user is expected to see a scrollbar and on clicking the scrollbar
>>>>        tracker or scrollbar up/down arrow buttons a JOption dialog should
>>>>        come once. The program works fine if scrollbar tracker is clicked
>>>>        i.e. JOption dialog comes only once. But on clicking up/down arrow
>>>>        buttons of scrollbar the JOption dialog keeps on coming repeatedly.
>>>>
>>>>        Cause: The mouse pressed event of scrollbar arrow buttons calls BasicScrollBarUI::scrollByUnit method which creates a property change event and calls scroll bar action listener which again calls BasicScrollBarUI::scrollByUnit. This is becoming a recursive call and causing the scrollbar slider to move repeatedly till it reaches the other end of scrollbar.
>>>>
>>>>       If I change the AdjustmentListener to not show the 
>>>> JOptionPane it is called only one time.
>>>>       What is the reason that showing JOptionPane causes that the 
>>>> AdjustmentListener is called one more time?
>>>>
>>>>       Thanks,
>>>>       Alexandr.
>>>>
>>>>
>>>>
>>>>
>>>>        Fix: Added checks in the BasicScrollBarUI action listener to stop the recursion.
>>>>
>>>>
>>>>
>>>>        Regards,
>>>>
>>>>        Rajeev Chamyal
>>>>
>
> --
> Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Tue Mar 22 15:07:17 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 22 Mar 2016 18:07:17 +0300
Subject: <Swing Dev> [9] Review Request: 8144166 [macosx] Test
 java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java
 fails
In-Reply-To: <56F0E22C.3090404@oracle.com>
References: <56E1DA78.1080000@oracle.com> <56E265F6.5020800@oracle.com>
	<56E29283.9060906@oracle.com> <56F0E22C.3090404@oracle.com>
Message-ID: <56F15FA5.8010900@oracle.com>

On 22.03.16 9:11, Semyon Sadetsky wrote:
> On 3/11/2016 12:40 PM, Sergey Bylokhov wrote:
>> On 11.03.16 9:30, Semyon Sadetsky wrote:
>>> Hi Sergey,
>>>
>>> Could you explain why do you suppose that the icon cannot be requested
>>> more then once between the frame minimize and restore?
>>
>> Every time when the frame is minimized the new
>> AquaInternalFrameDockIconUI is created. Every
>> AquaInternalFrameDockIconUI have its own ScaledImageLabel(which is
>> JLabel). At the beginning this label is initialized by the icon from
>> the cache, and this label is used until the frame is restored(cache is
>> not used).
> What if user requests the dock icon to paint it somewhere else while the
> frame is hidden? Before the fix the user got the same icon image from
> the cache, but after the fix he gets another image because it is being
> re-created on each paint.

After the fix the new image recreated only when the frame is minimized, 
after that the same icon will be used for every repaint action: Because 
we set this image as an icon for ScaledImageLabel and check it to null 
on each repaint:
189         public void paint(final Graphics g) {
190             if (getIcon() == null) updateIcon();

> So it becomes impossible to paint the same
> icon that is shown in the dock currently.

>>
>>>
>>>  > The bug is in the last step. When the frame will be minimized in the
>>> second time, it can have another content. But minimized icon
>>>  > will show the miniature from the previous minimization...
>>> Doesn't it contradict with :
>>>  >    * If the frame will be resized/show the cache will be reset.
>>> ?
>>>
>>> --Semyon
>>>
>>> On 3/10/2016 11:35 PM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk9.
>>>>
>>>> Problem description:
>>>>  - CompEventOnHiddenComponent test was written not according the
>>>> specification but according an assumption(performance related) - "the
>>>> component should not post move/resize events if no listeners were
>>>> registered". The test creates a JInternalFrame and adds
>>>> ComponentListener to it. No events should come to the listeners,
>>>> because the frame is not resized or moved by the test(except initial
>>>> layout). Initial move/resize events are skipped usually, because
>>>> during initialization there are no any listeners. But this is not the
>>>> case in Aqua. AquaInternalFrameDockIconUI adds a listeners to the
>>>> JInternalFrame during initialization -> move/resize events are posted
>>>> -> the test adds own listeners -> events dispatched -> the test
>>>> listeners called -> boom.
>>>>
>>>> According above description the bug could be closed as not a defect.
>>>> But I found another related problem in the AquaInternalFrameDockIconUI.
>>>>
>>>>  - These component listeners in AquaInternalFrameDockIconUI are used
>>>> to maintain the cache of image for the dock(the icon which is used
>>>> when the internal frame is minimized). The logic is next:
>>>>    * Before the frame will be minimized it draws to the special
>>>> ImageIcon which will be used as an icon for the dock.
>>>>    * After the frame is minimized and dock is showing the saved image
>>>> will be used(and placed to the cache)
>>>>    * If the frame will be resized/show the cache will be reset.
>>>>    * When in the next time the same frame will be minimized the cached
>>>> image will be used.
>>>>
>>>> The bug is in the last step. When the frame will be minimized in the
>>>> second time, it can have another content. But minimized icon will show
>>>> the miniature from the previous minimization. Note this is the only
>>>> step where the cache is used.
>>>>
>>>> Solution:
>>>> As a solution all cache related stuff were dropped. The new test was
>>>> added.
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144166
>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/8144166/webrev.01
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Mar 22 15:41:05 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Tue, 22 Mar 2016 08:41:05 -0700
Subject: <Swing Dev> [9] Review Request for 8078514: Nightly:
 api/javax_swing/DefaultRowSorter/index_ModelStructChanged failure
In-Reply-To: <5667D282.3020900@oracle.com>
References: <55560786.9010306@oracle.com> <555B1885.2020605@oracle.com>
	<555DECDB.6020301@oracle.com> <55644D39.2080208@oracle.com>
	<56376A78.3090900@oracle.com> <566735DC.8050706@oracle.com>
	<5667D282.3020900@oracle.com>
Message-ID: <56F16791.4040204@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 12/8/2015 11:04 PM, Semyon Sadetsky wrote:
>
>
> On 12/8/2015 10:56 PM, Sergey Bylokhov wrote:
>> On 02/11/15 16:51, Semyon Sadetsky wrote:
>>> On 5/26/2015 1:38 PM, Alexander Scherbatiy wrote:
>>>> On 5/21/2015 5:34 PM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> I have decided to remake the fix.
>>>>> The reason for that is sun.swing.FilePane class. One of its inner
>>>>> classes extends DefaultRowSorter and relays on lazy initialization of
>>>>> the DefaultRowSorter in unsorted state. After removing the lazy init
>>>>> the FilePane crashes with AOB exception.
>>>>
>>>>    It looks like FilePane tries to call some operations like
>>>> DefaultRowSorter.convertRowIndexToView(int) on non updated
>>>> DefaultRowSorter.
>>>>    Is it possible to fix it in FilePane?
>>> I fixed the FilePane. Please review the updated webrev:
>>> http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.02/
>>
>> Can you please clarify the change from v01->v02 related to 
>> modelRowCount. One fix version uses Math.max, latest version skip it. 
>> but getViewRowCount() still use Math.max.
> There are DefaultRowSorter usage in the FilePane that relays on the 
> current logic, but the current logic doesn't work for JTable sorting. 
> (Remind you that the initial problem was 6894632).
> The first solution worked in both cases, but it had caused Alexanders 
> doubts in offline discussion.
> The second version fixes the FilePane and doesn't use the ambiguous 
> Math.max.
> For me both are working solutions.
>>
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>> This can be fixed, but I think it will be too big change for the
>>>>> issue and users can be already using the DefaultRowSorter in the
>>>>> similar way.
>>>>> Here is the new approach:
>>>>> http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.01/
>>>>> It looks a little bit risky ,but all related tests have been passed.
>>>>>
>>>>> --Semyon
>>>>>
>>>>> On 5/19/2015 2:03 PM, Alexander Scherbatiy wrote:
>>>>>> On 5/15/2015 5:49 PM, Semyon Sadetsky wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review fix for JDK9:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8078514
>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.00/
>>>>>>
>>>>>>   DefaultRowSorter
>>>>>> 221             allChanged();
>>>>>> 222             modelRowCount = getModelWrapper().getRowCount();
>>>>>>
>>>>>> - This can be moved to a private method that will be used both in
>>>>>> the public modelStructureChanged() and setModelWrapper() methods.
>>>>>>
>>>>>> 532     public void sort()
>>>>>> - Could the rawFilter be null in case viewToModel != null an
>>>>>> !isUnsorted() ?
>>>>>> - isUnsorted() method is called twice. Is it possible to store its
>>>>>> value to a variable and use it?
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>>
>>>>>>> The 6894632 fix violated a contract between the table and its row
>>>>>>> sorter: the sorter should receive TableChanged events even if table
>>>>>>> is not sorted actually.
>>>>>>> Another way to fix 6894632 is to initialize sorter internal
>>>>>>> structures instantly. The last is applied in the fix.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>



From Sergey.Bylokhov at oracle.com  Tue Mar 22 16:28:03 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 22 Mar 2016 19:28:03 +0300
Subject: <Swing Dev> [9] Review request for JDK-8150225
 api/javax_swing/text/AbstractWriter/index_indent failed
In-Reply-To: <53d0d59a-1266-4b0b-b2e8-d74ca78b8144@default>
References: <d57da090-134d-4840-87d5-fbfc73027061@default>
	<56DFF9BF.6080205@oracle.com>
	<195b6aa5-1959-467e-826b-ce98377e392a@default>
	<53d0d59a-1266-4b0b-b2e8-d74ca78b8144@default>
Message-ID: <56F17293.5000002@oracle.com>

Looks fine to me. But I am not an expert here. And I wonder why the <p> 
tag is so specific, can we get the similar issue if some other tags will 
be used instead?

On 22.03.16 11:35, Rajeev Chamyal wrote:
> Hello All,
>
> Gentle reminder.
> Please review the fix.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225
> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Rajeev Chamyal
> Sent: 09 March 2016 15:58
> To: Sergey Bylokhov; Alexander Scherbatiy; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed
>
> Hello Sergey,
>
> I have run JCK tests for HTMLWriter and AbstractWriter with this fix and all passed.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 09 March 2016 15:54
> To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed
>
> Hi, Rajeev.
> Please confirm that there are no new issues in the jck after this fix.
>
> On 09.03.16 12:18, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225
>>
>> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/
>> <http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/>
>>
>> Issue : JCK conformance test failed due to fix for bug JDK-7104635
>>
>> Fix: Reverted the fix for JDK-7104635 and added a new method in
>> HTMLWriter.java to check if P tag is within Pre tag.
>>
>> Decrement indentation is skipped if P tag is with a Pre tag.
>>
>> Regards,
>>
>> Rajeev Chamyal
>>
>
>
> --
> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Mar 22 17:09:31 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 22 Mar 2016 20:09:31 +0300
Subject: <Swing Dev> Review Request of 8151282: [TEST_BUG]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with
 GTK LnF
In-Reply-To: <9704F43B-38E3-4E53-9801-039731984330@oracle.com>
References: <6F445466-A228-49AD-AB49-AA53EE1584A0@oracle.com>
	<56E17C34.5030303@oracle.com>
	<8AE0341F-6D3A-4586-B7CC-38318B986450@oracle.com>
	<2DD39FDD-D8C9-47B6-BAAB-D1AEA0A22DF6@oracle.com>
	<56EC68F6.5000106@oracle.com>
	<F78727F3-6931-4A40-A949-45EC3C716614@oracle.com>
	<56F0072E.9070800@oracle.com>
	<9704F43B-38E3-4E53-9801-039731984330@oracle.com>
Message-ID: <56F17C4B.8050506@oracle.com>

Looks fine.

On 22.03.16 10:38, Avik Niyogi wrote:
> Hi All,
> Please find webrev with new code fix:
> http://cr.openjdk.java.net/~aniyogi/8151282/webrev.02/
>
> With Regards,
> Avik Niyogi
>
>> On 21-Mar-2016, at 8:07 pm, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Avik.
>> How this test can fail? I do not see any raised exceptions.
>>
>> On 21.03.16 9:46, Avik Niyogi wrote:
>>> Hi Sergey,
>>> Please review the following code change.
>>> With Regards,
>>> Avik Niyogi
>>>> On 19-Mar-2016, at 2:15 am, Alexander Scherbatiy
>>>> <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>
>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>
>>>> The fix looks good to me.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>> On 14/03/16 16:25, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> Please review code changes made as per inputs provided.
>>>>>
>>>>> http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.01/>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>> On 14-Mar-2016, at 10:53 am, Avik Niyogi
>>>>>> <<mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com
>>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>
>>>>>> Hi Sergey,
>>>>>> Seems like it is a delay issue. Will submit test case with a
>>>>>> waitForIdle() fix.
>>>>>>
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov
>>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>>> <mailto:Sergey.Bylokhov at oracle.com><mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi, Avik.
>>>>>>> A few questions.
>>>>>>> - Why webrev contains the new file?
>>>>>>> - You marked the test as a mac specific but it is iterates over a
>>>>>>> bunch of l&fs. It seems it should not be OS specific, but should
>>>>>>> check some specific l&fs (which support such icons): Metal, Nimbus,
>>>>>>> Aqua, Windows(???). So gtk/motif should be skipped.
>>>>>>>
>>>>>>> On 08.03.16 8:10, Avik Niyogi wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>
>>>>>>>> *Bug:*
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151282
>>>>>>>>
>>>>>>>> *Webrev:*
>>>>>>>>
>>>>>>>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
>>>>>>>> _
>>>>>>>> _
>>>>>>>> *Issue:*
>>>>>>>> The test case failed for GTK LAF.
>>>>>>>>
>>>>>>>> *Cause:*
>>>>>>>> The test case was meant to be Mac specific and was missing a jtreg
>>>>>>>> parameter
>>>>>>>>
>>>>>>>> *Fix:*
>>>>>>>> Minor change to test case with @requires tag added to set the fix.
>>>>>>>>
>>>>>>>> With Regards,
>>>>>>>> Avik Niyogi
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards, Sergey.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From artem.ananiev at oracle.com  Wed Mar 23 06:28:02 2016
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 23 Mar 2016 09:28:02 +0300
Subject: <Swing Dev> CFV: New Swing Group Member: Semyon Sadetsky
In-Reply-To: <56EF8E29.4070605@oracle.com>
References: <56EF8E29.4070605@oracle.com>
Message-ID: <56F23772.50002@oracle.com>


Vote: yes

Artem

On 3/21/16 9:01 AM, Alexander Scherbatiy wrote:
>
> I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to
> Membership in the Swing Group.
>
> Semyon is active member of Swing group and contributed a lot of fixes
> which include Swing TimerQueue race condition improvement, UndoManager
> deadlock resolving, proposing and implementation a public API for
> internal Swing functionality which is part of Swing modularization
> support for JDK 9, and others (see Semyon?s list OpenJDK changesets [1])
>
> Semyon proposed a big change for the Swing part of the JEP 283 ?Enable
> GTK 3 on Linux? [2] implementation [3].
>
> Semyon not only provides fixes for Swing issues but also regularly
> reviews fixes suggested by other members.
>
> Votes are due by Apr 5, 2016.
>
> Only current Members of the Swing  Group [4] are eligible
> to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [5].
>
> Thanks,
> Alexandr.
>
> [1]
> http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ssadetsky%22%29
>
> [2] http://openjdk.java.net/jeps/283
> [3] http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005440.html
> [4] http://openjdk.java.net/census#swing
> [5] http://openjdk.java.net/groups/#member-vote


From rajeev.chamyal at oracle.com  Wed Mar 23 09:14:38 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 23 Mar 2016 02:14:38 -0700 (PDT)
Subject: <Swing Dev> [9] Review request for JDK-8150225
 api/javax_swing/text/AbstractWriter/index_indent failed
In-Reply-To: <56F17293.5000002@oracle.com>
References: <d57da090-134d-4840-87d5-fbfc73027061@default>
	<56DFF9BF.6080205@oracle.com>
	<195b6aa5-1959-467e-826b-ce98377e392a@default>
	<53d0d59a-1266-4b0b-b2e8-d74ca78b8144@default>
	<56F17293.5000002@oracle.com>
Message-ID: <18c2bb97-0ec6-48ec-8b39-209a19b67482@default>

Hello Sergey,

I had found below link about pre tag which states A P tag is strictly not permitted inside PRE, but if a browser encounters one, it should treat it as two newlines.
http://www.htmlhelp.com/reference/wilbur/block/pre.html 

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov 
Sent: 22 March 2016 21:58
To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed

Looks fine to me. But I am not an expert here. And I wonder why the <p> tag is so specific, can we get the similar issue if some other tags will be used instead?

On 22.03.16 11:35, Rajeev Chamyal wrote:
> Hello All,
>
> Gentle reminder.
> Please review the fix.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225
> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Rajeev Chamyal
> Sent: 09 March 2016 15:58
> To: Sergey Bylokhov; Alexander Scherbatiy; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 
> api/javax_swing/text/AbstractWriter/index_indent failed
>
> Hello Sergey,
>
> I have run JCK tests for HTMLWriter and AbstractWriter with this fix and all passed.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 09 March 2016 15:54
> To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 
> api/javax_swing/text/AbstractWriter/index_indent failed
>
> Hi, Rajeev.
> Please confirm that there are no new issues in the jck after this fix.
>
> On 09.03.16 12:18, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225
>>
>> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/
>> <http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/>
>>
>> Issue : JCK conformance test failed due to fix for bug JDK-7104635
>>
>> Fix: Reverted the fix for JDK-7104635 and added a new method in 
>> HTMLWriter.java to check if P tag is within Pre tag.
>>
>> Decrement indentation is skipped if P tag is with a Pre tag.
>>
>> Regards,
>>
>> Rajeev Chamyal
>>
>
>
> --
> Best regards, Sergey.
>


--
Best regards, Sergey.


From avik.niyogi at oracle.com  Wed Mar 23 09:55:29 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 23 Mar 2016 15:25:29 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <56EC6376.5020106@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
Message-ID: <0278A740-4E11-4303-8FEF-EA4B8343EBC7@oracle.com>

Hi Alexander,
With inputs (code) provided, it is not possible to accommodate the right methods for tabPlacement parameter.
Also, since AquaTabbedPane is copied from BasicUI.java, this implementation if moved to TabbedPaneLayout, does not accommodate Awua related changes and hence, the redundant code is in effect.
Also, regarding the query about the below:
> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs navigation.
> May be the fix should update the AquaTruncatingTabbedPaneLayout only?

The defect due to the bug is injected only if Scrolling is in effect. The non-scrolling values populated for tabbedPaneLayout tried to add another row and hence would result in defects.
This was due to the fact that TabbedPaneScrollLayout was not even getting set even when the user was trying to set it.
Ideally, it would have been easier to call the super class to manage just the layout part but as per inputs received, it will not be accepted even though it have no splash impact and would not lead to regressions. 
Due to those reasons, this is the solution seeming fit for this.
I have tried the way suggested in your input code, but it broke the UI and different elements not required to be visible were being rendered because it is copying those elements from BasicUI.
If a better solution is available without breaking some code apart from fix provided, please let me know. Thank you in advance.

With Regards,
Avik Niyogi

> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> 
> I would think about something like:
> -------------
>     public class TabbedPaneLayout implements LayoutManager {
> 
>         protected int basePreferredTabAreaWidth(final int tabPlacement, final int height) {
>             // TabbedPaneLayout preferredTabAreaWidth implementation
>         }
> 
>         protected int truncatingPreferredTabAreaWidth(final int tabPlacement, final int height) {
>             if (tabPlacement == SwingConstants.LEFT || tabPlacement == SwingConstants.RIGHT) {
>                 return basePreferredTabAreaWidth(tabPlacement, height);
>             }
> 
>             return basePreferredTabAreaWidth(tabPlacement, height);
>         }
> 
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return basePreferredTabAreaWidth(tabPlacement, height);
>         }
> 
>     }
> 
>     class TabbedPaneScrollLayout extends TabbedPaneLayout {
>         @Override
>         protected int basePreferredTabAreaWidth(int tabPlacement, int height) {
>             // TabbedPaneScrollLayout preferredTabAreaWidth implementation
>         }
>     }
> 
>     protected class AquaTruncatingTabbedPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
> 
>         @Override
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>         }
>     }
> 
>     protected class AquaTruncatingTabbedScrollPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
> 
>         @Override
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>         }
>     }
> -------------
> 
> I just have one more question. The TabbedPaneScrollLayout is only created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
> 
> Are there any real cases when the TabbedPaneScrollLayout is created?
> 
> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not look similar to Aqua L&F:
>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png <http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png>
> 
> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs navigation.
> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
> 
> Thanks,
> Alexandr.
> 
> On 18/03/16 14:21, Avik Niyogi wrote:
>> Hi Alexander,
>> Thank you for the inputs. I agree with you and did feel the need for removing duplicate code as well. But as per an earlier review input, changes to the super call lay outing is not accepted. This was the only other feasible solution. Created redundant code in this process, but would be maintaining with requirements with code impact to superclasses.
>> Please provide any insight to a probable compensate to mitigate this dichotomy of code expectation. Thank you in advance.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>> 
>>> 
>>> It is not usually a good idea to have a duplicated code which should be updated every time in several places.
>>> 
>>> Is it possible to move the  methods used both in AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with different names and then reused?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 17/03/16 17:17, Avik Niyogi wrote:
>>>> Hi Alexander,
>>>> The issue only applies for ScrollingTabbedPane and hence this fix.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy < <mailto:alexandr.scherbatiy at oracle.com>alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>> 
>>>>> 
>>>>> Does the same issue affects the AquaTabbedPaneContrastUI?
>>>>> 
>>>>> Thanks,
>>>>> Alexandr.
>>>>> 
>>>>> On 14/03/16 09:04, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> A gentle reminder, please review code changes.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Please review code changes done as with inputs provided.
>>>>>>>  <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/>
>>>>>>> 
>>>>>>> Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
>>>>>>> In the new fix as provided, references to base class layout manager is removed in current solution.
>>>>>>> 
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>> 
>>>>>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> Hello Avik
>>>>>>>> 
>>>>>>>> Let me make it clear I don't approve the proposed fix
>>>>>>>> and ask you to do additional evaluation.
>>>>>>>> 
>>>>>>>> Every LookAndFeel is different and it doesn't make much sense
>>>>>>>> to compare Metal LaF with AquaLaf.
>>>>>>>> 
>>>>>>>> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
>>>>>>>> 
>>>>>>>> The bug you are fixing has the following subject 
>>>>>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>>>>>> 
>>>>>>>> Could you please fix exactly the problem with the minimal heights,
>>>>>>>> without changing the UI delegate class.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> alexp
>>>>>>>> 
>>>>>>>>> Gentle reminder. Please review this fix.
>>>>>>>>> 
>>>>>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>>>>>>>  and not TabbedPaneLayout() as which is the default.
>>>>>>>>>> 
>>>>>>>>>> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
>>>>>>>>>> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>>>>>>>>>> 
>>>>>>>>>> Fixing the minimum size in AquaTabbedPaneUI will fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>>>>>>>>> 
>>>>>>>>>> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
>>>>>>>>>> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>>>>>>>>>> 
>>>>>>>>>> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>>>>>>>>>> 
>>>>>>>>>> With Regards,
>>>>>>>>>> Avik Niyogi
>>>>>>>>>> 
>>>>>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hello Avik
>>>>>>>>>>> 
>>>>>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
>>>>>>>>>>> I don't think setting the layout manager from the base class is the right solution here.
>>>>>>>>>>> 
>>>>>>>>>>> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
>>>>>>>>>>> 
>>>>>>>>>>> Thanks
>>>>>>>>>>> alexp
>>>>>>>>>>> 
>>>>>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>> 
>>>>>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>>>>> 
>>>>>>>>>>>> Bug:
>>>>>>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8137169>https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>>>>>>>>>>> 
>>>>>>>>>>>> Webrev:
>>>>>>>>>>>> 
>>>>>>>>>>>>  <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>
>>>>>>>>>>>> 
>>>>>>>>>>>> Issue:
>>>>>>>>>>>> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cause:
>>>>>>>>>>>> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>>>>>> 
>>>>>>>>>>>> Fix:
>>>>>>>>>>>> Major linking calls to super class fix done within createLayoutManager().
>>>>>>>>>>>> 
>>>>>>>>>>>> With Regards,
>>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160323/d32c108c/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed Mar 23 10:01:38 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 23 Mar 2016 14:01:38 +0400
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
 minimal heigh of JTabbedPane with more tabs
In-Reply-To: <A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
	<A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
Message-ID: <56F26982.9070608@oracle.com>

On 21/03/16 09:19, Avik Niyogi wrote:
> Hi Alexander,
> I agree with what you said regarding the look and feel looking 
> different. But this bug arrises due to setting of 
> TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua 
> look and feel should not the setting of this parameter instead throw a 
> helpful error saying this parameter is not accepted
   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) 
javadoc:
   "Some look and feels might only support a subset of the possible 
layout policies, in which case the value of this property may be ignored."

   Aqua L&F ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and 
always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.

   Thanks,
   Alexandr.

> instead of absorbing this parameter and letting it render itself into 
> a dummy node which does not proceed further with this parameter? Maybe 
> we need to discuss what the expected behaviour may be. Also, thank you 
> for the inputs regarding how to proceed with removing duplicate code.
>
> With Regards,
> Avik Niyogi
>> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com 
>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>
>>
>> I would think about something like:
>> -------------
>>     public class TabbedPaneLayout implements LayoutManager {
>>
>>         protected int basePreferredTabAreaWidth(final int 
>> tabPlacement, final int height) {
>>             // TabbedPaneLayout preferredTabAreaWidth implementation
>>         }
>>
>>         protected int truncatingPreferredTabAreaWidth(final int 
>> tabPlacement, final int height) {
>>             if (tabPlacement == SwingConstants.LEFT || tabPlacement 
>> == SwingConstants.RIGHT) {
>>                 return basePreferredTabAreaWidth(tabPlacement, height);
>>             }
>>
>>             return basePreferredTabAreaWidth(tabPlacement, height);
>>         }
>>
>>         protected int preferredTabAreaWidth(final int tabPlacement, 
>> final int height) {
>>             return basePreferredTabAreaWidth(tabPlacement, height);
>>         }
>>
>>     }
>>
>>     class TabbedPaneScrollLayout extends TabbedPaneLayout {
>>         @Override
>>         protected int basePreferredTabAreaWidth(int tabPlacement, int 
>> height) {
>>             // TabbedPaneScrollLayout preferredTabAreaWidth 
>> implementation
>>         }
>>     }
>>
>>     protected class AquaTruncatingTabbedPaneLayout extends 
>> AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
>>
>>         @Override
>>         protected int preferredTabAreaWidth(final int tabPlacement, 
>> final int height) {
>>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>         }
>>     }
>>
>>     protected class AquaTruncatingTabbedScrollPaneLayout extends 
>> AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
>>
>>         @Override
>>         protected int preferredTabAreaWidth(final int tabPlacement, 
>> final int height) {
>>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>         }
>>     }
>> -------------
>>
>> I just have one more question. The TabbedPaneScrollLayout is only 
>> created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use 
>> AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return 
>> TabbedPaneScrollLayout.
>>
>> Are there any real cases when the TabbedPaneScrollLayout is created?
>>
>> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the 
>> AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not 
>> look similar to Aqua L&F:
>> http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png
>>
>> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden 
>> tabs navigation.
>> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
>>
>> Thanks,
>> Alexandr.
>>
>> On 18/03/16 14:21, Avik Niyogi wrote:
>>> Hi Alexander,
>>> Thank you for the inputs. I agree with you and did feel the need for 
>>> removing duplicate code as well. But as per an earlier review input, 
>>> changes to the super call lay outing is not accepted. This was the 
>>> only other feasible solution. Created redundant code in this 
>>> process, but would be maintaining with requirements with code impact 
>>> to superclasses.
>>> Please provide any insight to a probable compensate to mitigate this 
>>> dichotomy of code expectation. Thank you in advance.
>>>
>>> With Regards,
>>> Avik Niyogi
>>>> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy 
>>>> <alexandr.scherbatiy at oracle.com 
>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>
>>>>
>>>> It is not usually a good idea to have a duplicated code which 
>>>> should be updated every time in several places.
>>>>
>>>> Is it possible to move the  methods used both in 
>>>> AquaTruncatingTabbedPaneLayout and 
>>>> AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with 
>>>> different names and then reused?
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>> On 17/03/16 17:17, Avik Niyogi wrote:
>>>>> Hi Alexander,
>>>>> The issue only applies for ScrollingTabbedPane and hence this fix.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>
>>>>>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy 
>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>
>>>>>>
>>>>>> Does the same issue affects the AquaTabbedPaneContrastUI?
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>> On 14/03/16 09:04, Avik Niyogi wrote:
>>>>>>> Hi All,
>>>>>>> A gentle reminder, please review code changes.
>>>>>>>
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi 
>>>>>>>> <avik.niyogi at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review code changes done as with inputs provided.
>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/
>>>>>>>>
>>>>>>>> Also, albeit the title of issue mentioned is as above, the 
>>>>>>>> injection of issue occurs because 
>>>>>>>> *pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT);* is 
>>>>>>>> not honoured.
>>>>>>>> In the new fix as provided, references to base class layout 
>>>>>>>> manager is removed in current solution.
>>>>>>>>
>>>>>>>> With Regards,
>>>>>>>> Avik Niyogi
>>>>>>>>
>>>>>>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin 
>>>>>>>>> <alexander.potochkin at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Hello Avik
>>>>>>>>>
>>>>>>>>> Let me make it clear I don't approve the proposed fix
>>>>>>>>> and ask you to do additional evaluation.
>>>>>>>>>
>>>>>>>>> Every LookAndFeel is different and it doesn't make much sense
>>>>>>>>> to compare Metal LaF with AquaLaf.
>>>>>>>>>
>>>>>>>>> The AquaLaf mimics the native MacOS controls and therefore 
>>>>>>>>> look quite different from any other Lafs.
>>>>>>>>>
>>>>>>>>> The bug you are fixing has the following subject
>>>>>>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>>>>>>>
>>>>>>>>> Could you please fix exactly the problem with the minimal heights,
>>>>>>>>> without changing the UI delegate class.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> alexp
>>>>>>>>>
>>>>>>>>>> Gentle reminder. Please review this fix.
>>>>>>>>>>
>>>>>>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi 
>>>>>>>>>>> <avik.niyogi at oracle.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The issue is with setting of TabbedPane*Scroll*Layout() for 
>>>>>>>>>>> the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in 
>>>>>>>>>>> the test code
>>>>>>>>>>>  and *not* TabbedPaneLayout() as which is the default.
>>>>>>>>>>>
>>>>>>>>>>> The minimum size fixes itself because the *ScrollLayout* 
>>>>>>>>>>> check fails in *setTabLayoutPolicy*() for the pane. So the 
>>>>>>>>>>> issue is with the call to set layout manager.
>>>>>>>>>>> There are only two configurations that the *JTabbedPane* can 
>>>>>>>>>>> exist in of which *SCROLL_TAB_LAYOUT* is one of them.
>>>>>>>>>>>
>>>>>>>>>>> Fixing the minimum size in *AquaTabbedPaneUI* will fix it 
>>>>>>>>>>> for *TabbedPaneLayout*() only which is the *WRAP_TAB_LAYOUT*.
>>>>>>>>>>>
>>>>>>>>>>> Also, I have checked other implementations such as for 
>>>>>>>>>>> *Metal* and *Motif* and *they have similar code for doing 
>>>>>>>>>>> this process*.
>>>>>>>>>>> Hence, with in-depth analysis, this fix has no other impact 
>>>>>>>>>>> apart from this fix.
>>>>>>>>>>>
>>>>>>>>>>> In case the impact caused by this change has caused some 
>>>>>>>>>>> definitive regressions, please mention them so they can be 
>>>>>>>>>>> addressed. Thank you.
>>>>>>>>>>>
>>>>>>>>>>> With Regards,
>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>>
>>>>>>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin 
>>>>>>>>>>>> <alexander.potochkin at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello Avik
>>>>>>>>>>>>
>>>>>>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is 
>>>>>>>>>>>> specific for the AquaTabbedPaneUI.
>>>>>>>>>>>> I don't think setting the layout manager from the base 
>>>>>>>>>>>> class is the right solution here.
>>>>>>>>>>>>
>>>>>>>>>>>> If there is a problem with minimum size it should be fixed 
>>>>>>>>>>>> inside the AquaTabbedPaneUI
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> alexp
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Bug:*
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8137169
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Webrev:*
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Issue:*
>>>>>>>>>>>>> For Aqua Look&Feel, multiple calls 
>>>>>>>>>>>>> to pane.getMinimumSize().height causes incremental return 
>>>>>>>>>>>>> of values.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Cause:*
>>>>>>>>>>>>> The impact was caused by a major broken code within 
>>>>>>>>>>>>> AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Fix:*
>>>>>>>>>>>>> Major linking calls to super class fix done within 
>>>>>>>>>>>>> createLayoutManager().
>>>>>>>>>>>>>
>>>>>>>>>>>>> With Regards,
>>>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160323/062fb238/attachment.html>

From avik.niyogi at oracle.com  Wed Mar 23 10:07:37 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 23 Mar 2016 15:37:37 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <56F26982.9070608@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
	<A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
	<56F26982.9070608@oracle.com>
Message-ID: <29DECA40-D3D8-4673-92F6-6E0B594F318A@oracle.com>


> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> On 21/03/16 09:19, Avik Niyogi wrote:
>> Hi Alexander,
>> I agree with what you said regarding the look and feel looking different. But this bug arrises due to setting of TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua look and feel should not the setting of this parameter instead throw a helpful error saying this parameter is not accepted
>   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) javadoc:  
>   "Some look and feels might only support a subset of the possible layout policies, in which case the value of this property may be ignored."
>   
>   Aqua L&F ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.

Actually, it is doing the other way around for Aqua L&F. It is defaulting WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of TabbedPaneLayout and not TabbedPaneScrollLayout.

>   Thanks,
>   Alexandr.
> 
>> instead of absorbing this parameter and letting it render itself into a dummy node which does not proceed further with this parameter? Maybe we need to discuss what the expected behaviour may be. Also, thank you for the inputs regarding how to proceed with removing duplicate code.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>> 
>>> 
>>> I would think about something like:
>>> -------------
>>>     public class TabbedPaneLayout implements LayoutManager {
>>> 
>>>         protected int basePreferredTabAreaWidth(final int tabPlacement, final int height) {
>>>             // TabbedPaneLayout preferredTabAreaWidth implementation
>>>         }
>>> 
>>>         protected int truncatingPreferredTabAreaWidth(final int tabPlacement, final int height) {
>>>             if (tabPlacement == SwingConstants.LEFT || tabPlacement == SwingConstants.RIGHT) {
>>>                 return basePreferredTabAreaWidth(tabPlacement, height);
>>>             }
>>> 
>>>             return basePreferredTabAreaWidth(tabPlacement, height);
>>>         }
>>> 
>>>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>>>             return basePreferredTabAreaWidth(tabPlacement, height);
>>>         }
>>> 
>>>     }
>>> 
>>>     class TabbedPaneScrollLayout extends TabbedPaneLayout {
>>>         @Override
>>>         protected int basePreferredTabAreaWidth(int tabPlacement, int height) {
>>>             // TabbedPaneScrollLayout preferredTabAreaWidth implementation
>>>         }
>>>     }
>>> 
>>>     protected class AquaTruncatingTabbedPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
>>> 
>>>         @Override
>>>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>>>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>>         }
>>>     }
>>> 
>>>     protected class AquaTruncatingTabbedScrollPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
>>> 
>>>         @Override
>>>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>>>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>>         }
>>>     }
>>> -------------
>>> 
>>> I just have one more question. The TabbedPaneScrollLayout is only created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
>>> 
>>> Are there any real cases when the TabbedPaneScrollLayout is created?
>>> 
>>> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not look similar to Aqua L&F:
>>>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png <http://cr.openjdk.java.net/%7Ealexsch/8137169/aqua-scrolled-tabbed-pane.png>
>>> 
>>> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs navigation.
>>> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 18/03/16 14:21, Avik Niyogi wrote:
>>>> Hi Alexander,
>>>> Thank you for the inputs. I agree with you and did feel the need for removing duplicate code as well. But as per an earlier review input, changes to the super call lay outing is not accepted. This was the only other feasible solution. Created redundant code in this process, but would be maintaining with requirements with code impact to superclasses.
>>>> Please provide any insight to a probable compensate to mitigate this dichotomy of code expectation. Thank you in advance.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy < <mailto:alexandr.scherbatiy at oracle.com>alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>> 
>>>>> 
>>>>> It is not usually a good idea to have a duplicated code which should be updated every time in several places.
>>>>> 
>>>>> Is it possible to move the  methods used both in AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with different names and then reused?
>>>>> 
>>>>> Thanks,
>>>>> Alexandr.
>>>>> 
>>>>> On 17/03/16 17:17, Avik Niyogi wrote:
>>>>>> Hi Alexander,
>>>>>> The issue only applies for ScrollingTabbedPane and hence this fix.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>> 
>>>>>>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Does the same issue affects the AquaTabbedPaneContrastUI?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>> 
>>>>>>> On 14/03/16 09:04, Avik Niyogi wrote:
>>>>>>>> Hi All,
>>>>>>>> A gentle reminder, please review code changes.
>>>>>>>> 
>>>>>>>> With Regards,
>>>>>>>> Avik Niyogi
>>>>>>>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> Please review code changes done as with inputs provided.
>>>>>>>>>  <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/>
>>>>>>>>> 
>>>>>>>>> Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
>>>>>>>>> In the new fix as provided, references to base class layout manager is removed in current solution.
>>>>>>>>> 
>>>>>>>>> With Regards,
>>>>>>>>> Avik Niyogi
>>>>>>>>> 
>>>>>>>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hello Avik
>>>>>>>>>> 
>>>>>>>>>> Let me make it clear I don't approve the proposed fix
>>>>>>>>>> and ask you to do additional evaluation.
>>>>>>>>>> 
>>>>>>>>>> Every LookAndFeel is different and it doesn't make much sense
>>>>>>>>>> to compare Metal LaF with AquaLaf.
>>>>>>>>>> 
>>>>>>>>>> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
>>>>>>>>>> 
>>>>>>>>>> The bug you are fixing has the following subject 
>>>>>>>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>>>>>>>> 
>>>>>>>>>> Could you please fix exactly the problem with the minimal heights,
>>>>>>>>>> without changing the UI delegate class.
>>>>>>>>>> 
>>>>>>>>>> Thanks
>>>>>>>>>> alexp
>>>>>>>>>> 
>>>>>>>>>>> Gentle reminder. Please review this fix.
>>>>>>>>>>> 
>>>>>>>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>>>>>>>>>  and not TabbedPaneLayout() as which is the default.
>>>>>>>>>>>> 
>>>>>>>>>>>> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
>>>>>>>>>>>> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>>>>>>>>>>>> 
>>>>>>>>>>>> Fixing the minimum size in AquaTabbedPaneUI will fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>>>>>>>>>>> 
>>>>>>>>>>>> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
>>>>>>>>>>>> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>>>>>>>>>>>> 
>>>>>>>>>>>> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>>>>>>>>>>>> 
>>>>>>>>>>>> With Regards,
>>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hello Avik
>>>>>>>>>>>>> 
>>>>>>>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
>>>>>>>>>>>>> I don't think setting the layout manager from the base class is the right solution here.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> alexp
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Bug:
>>>>>>>>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8137169>https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>  <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Issue:
>>>>>>>>>>>>>> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Cause:
>>>>>>>>>>>>>> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Fix:
>>>>>>>>>>>>>> Major linking calls to super class fix done within createLayoutManager().
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> With Regards,
>>>>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160323/e2719415/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed Mar 23 10:44:11 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 23 Mar 2016 14:44:11 +0400
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
 minimal heigh of JTabbedPane with more tabs
In-Reply-To: <29DECA40-D3D8-4673-92F6-6E0B594F318A@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
	<A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
	<56F26982.9070608@oracle.com>
	<29DECA40-D3D8-4673-92F6-6E0B594F318A@oracle.com>
Message-ID: <56F2737B.6050108@oracle.com>

On 23/03/16 14:07, Avik Niyogi wrote:
>
>> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com 
>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>
>> On 21/03/16 09:19, Avik Niyogi wrote:
>>> Hi Alexander,
>>> I agree with what you said regarding the look and feel looking 
>>> different. But this bug arrises due to setting of 
>>> TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua 
>>> look and feel should not the setting of this parameter instead throw 
>>> a helpful error saying this parameter is not accepted
>>   According to the JTabbedPane.setTabLayoutPolicy(int 
>> tabLayoutPolicy) javadoc:
>>   "Some look and feels might only support a subset of the possible 
>> layout policies, in which case the value of this property may be 
>> ignored."
>>
>>   Aqua L&F ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and 
>> always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.
>
> Actually, it is doing the other way around for Aqua L&F. It is 
> defaulting WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still 
> setting a subclass of TabbedPaneLayout and not TabbedPaneScrollLayout.
    According to the JTabbedPane javadoc:
   SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset of 
available tabs when all the tabs will not fit within a single run.
   WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in multiple 
runs when all tabs will not fit within a single run.

    The Aqua L&F uses only AquaTabbedPaneUI and AquaTabbedPaneContrastUI 
for tabbed pane UI and they both returns AquaTruncatingTabbedPaneLayout 
which has been designed for to place tabs according to the 
SCROLL_TAB_LAYOUT.

   Thanks,
   Alexandr.
>
>>   Thanks,
>>   Alexandr.
>>
>>> instead of absorbing this parameter and letting it render itself 
>>> into a dummy node which does not proceed further with this 
>>> parameter? Maybe we need to discuss what the expected behaviour may 
>>> be. Also, thank you for the inputs regarding how to proceed with 
>>> removing duplicate code.
>>>
>>> With Regards,
>>> Avik Niyogi
>>>> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy 
>>>> <alexandr.scherbatiy at oracle.com 
>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>
>>>>
>>>> I would think about something like:
>>>> -------------
>>>>     public class TabbedPaneLayout implements LayoutManager {
>>>>
>>>>         protected int basePreferredTabAreaWidth(final int 
>>>> tabPlacement, final int height) {
>>>>             // TabbedPaneLayout preferredTabAreaWidth implementation
>>>>         }
>>>>
>>>>         protected int truncatingPreferredTabAreaWidth(final int 
>>>> tabPlacement, final int height) {
>>>>             if (tabPlacement == SwingConstants.LEFT || tabPlacement 
>>>> == SwingConstants.RIGHT) {
>>>>                 return basePreferredTabAreaWidth(tabPlacement, height);
>>>>             }
>>>>
>>>>             return basePreferredTabAreaWidth(tabPlacement, height);
>>>>         }
>>>>
>>>>         protected int preferredTabAreaWidth(final int tabPlacement, 
>>>> final int height) {
>>>>             return basePreferredTabAreaWidth(tabPlacement, height);
>>>>         }
>>>>
>>>>     }
>>>>
>>>>     class TabbedPaneScrollLayout extends TabbedPaneLayout {
>>>>         @Override
>>>>         protected int basePreferredTabAreaWidth(int tabPlacement, 
>>>> int height) {
>>>>             // TabbedPaneScrollLayout preferredTabAreaWidth 
>>>> implementation
>>>>         }
>>>>     }
>>>>
>>>>     protected class AquaTruncatingTabbedPaneLayout extends 
>>>> AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
>>>>
>>>>         @Override
>>>>         protected int preferredTabAreaWidth(final int tabPlacement, 
>>>> final int height) {
>>>>             return truncatingPreferredTabAreaWidth(tabPlacement, 
>>>> height);
>>>>         }
>>>>     }
>>>>
>>>>     protected class AquaTruncatingTabbedScrollPaneLayout extends 
>>>> AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
>>>>
>>>>         @Override
>>>>         protected int preferredTabAreaWidth(final int tabPlacement, 
>>>> final int height) {
>>>>             return truncatingPreferredTabAreaWidth(tabPlacement, 
>>>> height);
>>>>         }
>>>>     }
>>>> -------------
>>>>
>>>> I just have one more question. The TabbedPaneScrollLayout is only 
>>>> created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use 
>>>> AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return 
>>>> TabbedPaneScrollLayout.
>>>>
>>>> Are there any real cases when the TabbedPaneScrollLayout is created?
>>>>
>>>> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the 
>>>> AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does 
>>>> not look similar to Aqua L&F:
>>>> http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png
>>>>
>>>> The AquaTruncatingTabbedPaneLayout already contains arrows for 
>>>> hidden tabs navigation.
>>>> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>> On 18/03/16 14:21, Avik Niyogi wrote:
>>>>> Hi Alexander,
>>>>> Thank you for the inputs. I agree with you and did feel the need 
>>>>> for removing duplicate code as well. But as per an earlier review 
>>>>> input, changes to the super call lay outing is not accepted. This 
>>>>> was the only other feasible solution. Created redundant code in 
>>>>> this process, but would be maintaining with requirements with code 
>>>>> impact to superclasses.
>>>>> Please provide any insight to a probable compensate to mitigate 
>>>>> this dichotomy of code expectation. Thank you in advance.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy 
>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>
>>>>>>
>>>>>> It is not usually a good idea to have a duplicated code which 
>>>>>> should be updated every time in several places.
>>>>>>
>>>>>> Is it possible to move the methods used both in 
>>>>>> AquaTruncatingTabbedPaneLayout and 
>>>>>> AquaTruncatingTabbedScrollPaneLayout to TabbedPaneLayout with 
>>>>>> different names and then reused?
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>> On 17/03/16 17:17, Avik Niyogi wrote:
>>>>>>> Hi Alexander,
>>>>>>> The issue only applies for ScrollingTabbedPane and hence this fix.
>>>>>>>
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>>
>>>>>>>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy 
>>>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Does the same issue affects the AquaTabbedPaneContrastUI?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>> On 14/03/16 09:04, Avik Niyogi wrote:
>>>>>>>>> Hi All,
>>>>>>>>> A gentle reminder, please review code changes.
>>>>>>>>>
>>>>>>>>> With Regards,
>>>>>>>>> Avik Niyogi
>>>>>>>>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi 
>>>>>>>>>> <avik.niyogi at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review code changes done as with inputs provided.
>>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Also, albeit the title of issue mentioned is as above, the 
>>>>>>>>>> injection of issue occurs because 
>>>>>>>>>> *pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT);* is 
>>>>>>>>>> not honoured.
>>>>>>>>>> In the new fix as provided, references to base class layout 
>>>>>>>>>> manager is removed in current solution.
>>>>>>>>>>
>>>>>>>>>> With Regards,
>>>>>>>>>> Avik Niyogi
>>>>>>>>>>
>>>>>>>>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin 
>>>>>>>>>>> <alexander.potochkin at oracle.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello Avik
>>>>>>>>>>>
>>>>>>>>>>> Let me make it clear I don't approve the proposed fix
>>>>>>>>>>> and ask you to do additional evaluation.
>>>>>>>>>>>
>>>>>>>>>>> Every LookAndFeel is different and it doesn't make much sense
>>>>>>>>>>> to compare Metal LaF with AquaLaf.
>>>>>>>>>>>
>>>>>>>>>>> The AquaLaf mimics the native MacOS controls and therefore 
>>>>>>>>>>> look quite different from any other Lafs.
>>>>>>>>>>>
>>>>>>>>>>> The bug you are fixing has the following subject
>>>>>>>>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>>>>>>>>>
>>>>>>>>>>> Could you please fix exactly the problem with the minimal 
>>>>>>>>>>> heights,
>>>>>>>>>>> without changing the UI delegate class.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> alexp
>>>>>>>>>>>
>>>>>>>>>>>> Gentle reminder. Please review this fix.
>>>>>>>>>>>>
>>>>>>>>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi 
>>>>>>>>>>>>> <avik.niyogi at oracle.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> The issue is with setting of TabbedPane*Scroll*Layout() 
>>>>>>>>>>>>> for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled 
>>>>>>>>>>>>> in the test code
>>>>>>>>>>>>>  and *not* TabbedPaneLayout() as which is the default.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The minimum size fixes itself because the *ScrollLayout* 
>>>>>>>>>>>>> check fails in *setTabLayoutPolicy*() for the pane. So the 
>>>>>>>>>>>>> issue is with the call to set layout manager.
>>>>>>>>>>>>> There are only two configurations that the *JTabbedPane* 
>>>>>>>>>>>>> can exist in of which *SCROLL_TAB_LAYOUT* is one of them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Fixing the minimum size in *AquaTabbedPaneUI* will fix it 
>>>>>>>>>>>>> for *TabbedPaneLayout*() only which is the *WRAP_TAB_LAYOUT*.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, I have checked other implementations such as for 
>>>>>>>>>>>>> *Metal* and *Motif* and *they have similar code for doing 
>>>>>>>>>>>>> this process*.
>>>>>>>>>>>>> Hence, with in-depth analysis, this fix has no other 
>>>>>>>>>>>>> impact apart from this fix.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In case the impact caused by this change has caused some 
>>>>>>>>>>>>> definitive regressions, please mention them so they can be 
>>>>>>>>>>>>> addressed. Thank you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> With Regards,
>>>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin 
>>>>>>>>>>>>>> <alexander.potochkin at oracle.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello Avik
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is 
>>>>>>>>>>>>>> specific for the AquaTabbedPaneUI.
>>>>>>>>>>>>>> I don't think setting the layout manager from the base 
>>>>>>>>>>>>>> class is the right solution here.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If there is a problem with minimum size it should be 
>>>>>>>>>>>>>> fixed inside the AquaTabbedPaneUI
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> alexp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Bug:*
>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8137169
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Webrev:*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Issue:*
>>>>>>>>>>>>>>> For Aqua Look&Feel, multiple calls 
>>>>>>>>>>>>>>> to pane.getMinimumSize().height causes incremental 
>>>>>>>>>>>>>>> return of values.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Cause:*
>>>>>>>>>>>>>>> The impact was caused by a major broken code within 
>>>>>>>>>>>>>>> AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Fix:*
>>>>>>>>>>>>>>> Major linking calls to super class fix done within 
>>>>>>>>>>>>>>> createLayoutManager().
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With Regards,
>>>>>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160323/56b0680e/attachment.html>

From semyon.sadetsky at oracle.com  Thu Mar 24 06:14:37 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 24 Mar 2016 09:14:37 +0300
Subject: <Swing Dev> Review Request for 6439354 : Win L&F: TitledBorder
 colors are not from desktop
In-Reply-To: <34d597fe-a34e-4693-b2cb-3e4dbe0b746a@default>
References: <9dfecb85-567d-410c-b60a-9b8976521e55@default>
	<56EFFEA6.7040408@oracle.com>
	<34d597fe-a34e-4693-b2cb-3e4dbe0b746a@default>
Message-ID: <56F385CD.1040400@oracle.com>

Looks good.

--Semyon

On 3/22/2016 11:56 AM, Prem Balakrishnan wrote:
> Hi Sergey,
>
> Updated test as per the review comments.
>
> Webrev: http://cr.openjdk.java.net/~arapte/prem/6439354/webrev.01/
>
> Regards,
> Prem
>
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Monday, March 21, 2016 7:31 PM
> To: Prem Balakrishnan; Semyon Sadetsky; Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net
> Subject: Re: Review Request for 6439354 : Win L&F: TitledBorder colors are not from desktop
>
> Hi, Prem.
> In the test the Swing components accessed on non-EDT thread. Probably the test can be simplified further?
>
> On 21.03.16 11:20, Prem Balakrishnan wrote:
>> Hi*,*
>>
>> Please review fix for JDK 9,
>>
>> *Bug: *https://bugs.openjdk.java.net/browse/JDK-6439354 **
>>
>> *Webrev: *http://cr.openjdk.java.net/~arapte/prem/6439354/webrev.00/
>>
>> *Issue:*
>>
>> Win L&F: TitledBorder colors are not from desktop
>>
>> *Cause:*
>>
>> "TitledBorder.border" is set to EtchedBorder with default
>> highlight/shadow colors.
>>
>> *Fix:*
>>
>> "TitledBorder.border" is set to  EtchedBorder with Desktop
>>    highlight/shadow colors.
>>
>> **
>>
>> *Test: *Manual Test (since windows theme to be set)**
>>
>> **
>>
>> Regards,
>> Prem
>>
>
> --
> Best regards, Sergey.



From semyon.sadetsky at oracle.com  Thu Mar 24 06:36:59 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 24 Mar 2016 09:36:59 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56EC2389.3020507@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
Message-ID: <56F38B0B.3060700@oracle.com>

Hi Alexander,

Could you answer one question:
Why did you choose default interface methods to implement TextUIDrawing 
and not implement them in DefaultTextUIDrawing having declarations only 
in the interface?
AFAIK the common point of view is default methods should be used rarely 
because they may lead to unreadable code.

--Semyon

On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>
>   - Public TextUIDrawing interface is added to the javax.swing.plaf 
> package
>   - TextUIDrawing methods description does not mention component 
> properties to be more general
>   - TextUIDrawing methods are made default
>   - L&F sets an instance of the TextUIDrawing to look and feel 
> defaults using "uiDrawing.text" property
>   - ComponentUI class is not changed
>   - Each ComponentUI reads TextUIDrawing from UI defaults
>   - There is an interesting issue described in
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>     which is related to the fact that MetalLabelUI returns a static 
> field from createUI() method.
>     TitleBorder creates a JLabel but does not put it to any component 
> hierarchy. In this case SwingUtilities.updateComponentTreeUI() method 
> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI 
> field and sets a new LabelUI for ordinary labels. The TitleBorder 
> label UI is not changed in this case and it still uses the 
> metalLabelUI field which is not initialized.
>     It seems that other applications can also use components just for 
> drawing and have the same issue.
>     For this case the textUIDrawing field is not cleared in the 
> uninstallDefaults but just set to a static default value which should 
> not lead to memory leaks.
>
>   Thanks,
>   Alexandr.
>
> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>> Hi Alexandr,
>>>
>>>> Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>> ....
>>>> - public TextUIDrawing interface is added to the javax.swing.plaf 
>>>> package
>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>> ComponentUI class
>>>> - L&F sets an instance of the TextUIDrawing to look and feel 
>>>> defaults using
>>>> "uiDrawing.text" property
>>>> - Look and Feel delegates use the instance of the TextUIDrawing for 
>>>> text
>>>> drawing and measuring
>>> Some thoughts on the current design/implementation:
>>>
>>> By adding a field to the ComponentUI class the current 
>>> implementation increases
>>> memory consumption for all Swing applications. And you get the 
>>> feeling that
>>> there are different implementations of TextUIDrawing per ComponentUI 
>>> instances.
>>> Personally I can't imagine to have different implementations of
>>> TextUIDrawing for
>>> a given LookAndFeel. If I would design/implement it, then I would
>>> implement it as
>>> a property of the LookAndFeel class (similar to LayoutStyle) and not
>>> the ComponentUI.
>>> Developers can use then the following code to obtain the instance of
>>> TextUIDrawing:
>>>
>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>> short cut for the line above.
>>   LayoutStyle keeps its instance per App context. The same is for the 
>> LookAndFeel
>>   when it is got through UIManager.getLookAndFeel() call.
>>   It means that accessing an instance of a TextUIDrawing will leads 
>> to a time consumption.
>>
>>   There are 3 main ways of the SwingUtilities2.drawString(...) usage:
>>   1. ComponentUI classes
>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>   3. Public utilities methods (like WindowsGraphicsUtils.paintText())
>>
>>   For the cases 1 and 2 it is possible to load and store the 
>> UIDrawing instance during installUI()/updateUI() calls to decrease a 
>> time access to it.
>>
>>   For the case 3 it is necessary to get LookAndFeel instance each 
>> time (which is taken from an App context)
>>   or use the passed JComponent object. It requires to have a public 
>> method and the associated variable for each instance of 
>> JComponent/ComponentUI/... class.
>>> You can use this methods then in JDK too.
>>>
>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>> more useful methods,
>>> e.g. a method to create a composite font, a method to convert DLUs 
>>> to pixels.
>>   UIDrawing name may look like it should be used for any UI drawing, 
>> not only for text ones. I am afraid that it can be misleading.
>>
>>   Thanks,
>>   Alexandr.
>>
>>>
>>> Best regards,
>>> Andrej Golovnin
>>
>



From avik.niyogi at oracle.com  Thu Mar 24 06:48:50 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 24 Mar 2016 12:18:50 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <56F2737B.6050108@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
	<A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
	<56F26982.9070608@oracle.com>
	<29DECA40-D3D8-4673-92F6-6E0B594F318A@oracle.com>
	<56F2737B.6050108@oracle.com>
Message-ID: <604613F1-6641-40C3-A1A3-47C937133845@oracle.com>

Hi All,

Please review my code changes below as per the inputs received.

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/>

As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation within the derived AquaTruncatedTabbedPaneLayout, extending of TabbedPaneScrollLayout is not needed and management of row and column height is done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight need not manage the number of columns and rows respectively and will remain 1 as tabs can be brought forth to the UI by the arrow buttons AQUA provides instead of placing them in another row or column. This is also the expected behaviour for AquaLAF as per javadoc.

With Regards,
Avik Niyogi


> On 23-Mar-2016, at 4:14 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> On 23/03/16 14:07, Avik Niyogi wrote:
>> 
>>> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>> 
>>> On 21/03/16 09:19, Avik Niyogi wrote:
>>>> Hi Alexander,
>>>> I agree with what you said regarding the look and feel looking different. But this bug arrises due to setting of TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua look and feel should not the setting of this parameter instead throw a helpful error saying this parameter is not accepted
>>>   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) javadoc:  
>>>   "Some look and feels might only support a subset of the possible layout policies, in which case the value of this property may be ignored."
>>>   
>>>   Aqua L&F ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.
>> 
>> Actually, it is doing the other way around for Aqua L&F. It is defaulting WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of TabbedPaneLayout and not TabbedPaneScrollLayout.
>    According to the JTabbedPane javadoc:
>   SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset of available tabs when all the tabs will not fit within a single run.
>   WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in multiple runs when all tabs will not fit within a single run.
>  
>    The Aqua L&F uses only AquaTabbedPaneUI and AquaTabbedPaneContrastUI for tabbed pane UI and they both returns AquaTruncatingTabbedPaneLayout which has been designed for to place tabs according to the SCROLL_TAB_LAYOUT.
> 
>   Thanks,
>   Alexandr.
>> 
>>>   Thanks,
>>>   Alexandr.
>>> 
>>>> instead of absorbing this parameter and letting it render itself into a dummy node which does not proceed further with this parameter? Maybe we need to discuss what the expected behaviour may be. Also, thank you for the inputs regarding how to proceed with removing duplicate code.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy < <mailto:alexandr.scherbatiy at oracle.com>alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>> 
>>>>> 
>>>>> I would think about something like:
>>>>> -------------
>>>>>     public class TabbedPaneLayout implements LayoutManager {
>>>>> 
>>>>>         protected int basePreferredTabAreaWidth(final int tabPlacement, final int height) {
>>>>>             // TabbedPaneLayout preferredTabAreaWidth implementation
>>>>>         }
>>>>> 
>>>>>         protected int truncatingPreferredTabAreaWidth(final int tabPlacement, final int height) {
>>>>>             if (tabPlacement == SwingConstants.LEFT || tabPlacement == SwingConstants.RIGHT) {
>>>>>                 return basePreferredTabAreaWidth(tabPlacement, height);
>>>>>             }
>>>>> 
>>>>>             return basePreferredTabAreaWidth(tabPlacement, height);
>>>>>         }
>>>>> 
>>>>>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>>>>>             return basePreferredTabAreaWidth(tabPlacement, height);
>>>>>         }
>>>>> 
>>>>>     }
>>>>> 
>>>>>     class TabbedPaneScrollLayout extends TabbedPaneLayout {
>>>>>         @Override
>>>>>         protected int basePreferredTabAreaWidth(int tabPlacement, int height) {
>>>>>             // TabbedPaneScrollLayout preferredTabAreaWidth implementation
>>>>>         }
>>>>>     }
>>>>> 
>>>>>     protected class AquaTruncatingTabbedPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
>>>>> 
>>>>>         @Override
>>>>>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>>>>>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>>>>         }
>>>>>     }
>>>>> 
>>>>>     protected class AquaTruncatingTabbedScrollPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
>>>>> 
>>>>>         @Override
>>>>>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>>>>>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>>>>         }
>>>>>     }
>>>>> -------------
>>>>> 
>>>>> I just have one more question. The TabbedPaneScrollLayout is only created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
>>>>> 
>>>>> Are there any real cases when the TabbedPaneScrollLayout is created?
>>>>> 
>>>>> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not look similar to Aqua L&F:
>>>>>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png <http://cr.openjdk.java.net/%7Ealexsch/8137169/aqua-scrolled-tabbed-pane.png>
>>>>> 
>>>>> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs navigation.
>>>>> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
>>>>> 
>>>>> Thanks,
>>>>> Alexandr.
>>>>> 
>>>>> On 18/03/16 14:21, Avik Niyogi wrote:
>>>>>> Hi Alexander,
>>>>>> Thank you for the inputs. I agree with you and did feel the need for removing duplicate code as well. But as per an earlier review input, changes to the super call lay outing is not accepted. This was the only other feasible solution. Created redundant code in this process, but would be maintaining with requirements with code impact to superclasses.
>>>>>> Please provide any insight to a probable compensate to mitigate this dichotomy of code expectation. Thank you in advance.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy < <mailto:alexandr.scherbatiy at oracle.com>alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> It is not usually a good idea to have a duplicated code which should be updated every time in several places.
>>>>>>> 
>>>>>>> Is it possible to move the  methods used both in AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with different names and then reused?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>> 
>>>>>>> On 17/03/16 17:17, Avik Niyogi wrote:
>>>>>>>> Hi Alexander,
>>>>>>>> The issue only applies for ScrollingTabbedPane and hence this fix.
>>>>>>>> 
>>>>>>>> With Regards,
>>>>>>>> Avik Niyogi
>>>>>>>> 
>>>>>>>>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy < <mailto:alexandr.scherbatiy at oracle.com>alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Does the same issue affects the AquaTabbedPaneContrastUI?
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>> 
>>>>>>>>> On 14/03/16 09:04, Avik Niyogi wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>> A gentle reminder, please review code changes.
>>>>>>>>>> 
>>>>>>>>>> With Regards,
>>>>>>>>>> Avik Niyogi
>>>>>>>>>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi All,
>>>>>>>>>>> 
>>>>>>>>>>> Please review code changes done as with inputs provided.
>>>>>>>>>>>  <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/>
>>>>>>>>>>> 
>>>>>>>>>>> Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
>>>>>>>>>>> In the new fix as provided, references to base class layout manager is removed in current solution.
>>>>>>>>>>> 
>>>>>>>>>>> With Regards,
>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>> 
>>>>>>>>>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hello Avik
>>>>>>>>>>>> 
>>>>>>>>>>>> Let me make it clear I don't approve the proposed fix
>>>>>>>>>>>> and ask you to do additional evaluation.
>>>>>>>>>>>> 
>>>>>>>>>>>> Every LookAndFeel is different and it doesn't make much sense
>>>>>>>>>>>> to compare Metal LaF with AquaLaf.
>>>>>>>>>>>> 
>>>>>>>>>>>> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
>>>>>>>>>>>> 
>>>>>>>>>>>> The bug you are fixing has the following subject 
>>>>>>>>>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>>>>>>>>>> 
>>>>>>>>>>>> Could you please fix exactly the problem with the minimal heights,
>>>>>>>>>>>> without changing the UI delegate class.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> alexp
>>>>>>>>>>>> 
>>>>>>>>>>>>> Gentle reminder. Please review this fix.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < <mailto:avik.niyogi at oracle.com>avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>>>>>>>>>>>  and not TabbedPaneLayout() as which is the default.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
>>>>>>>>>>>>>> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Fixing the minimum size in AquaTabbedPaneUI will fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
>>>>>>>>>>>>>> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> With Regards,
>>>>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin < <mailto:alexander.potochkin at oracle.com>alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hello Avik
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
>>>>>>>>>>>>>>> I don't think setting the layout manager from the base class is the right solution here.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> alexp
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Bug:
>>>>>>>>>>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8137169>https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Issue:
>>>>>>>>>>>>>>>> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Cause:
>>>>>>>>>>>>>>>> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Fix:
>>>>>>>>>>>>>>>> Major linking calls to super class fix done within createLayoutManager().
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> With Regards,
>>>>>>>>>>>>>>>> Avik Niyogi
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160324/14d05c23/attachment.html>

From rajeev.chamyal at oracle.com  Thu Mar 24 07:04:47 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Thu, 24 Mar 2016 00:04:47 -0700 (PDT)
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
 minimal heigh of JTabbedPane with more tabs
In-Reply-To: <604613F1-6641-40C3-A1A3-47C937133845@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
	<A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
	<56F26982.9070608@oracle.com>
	<29DECA40-D3D8-4673-92F6-6E0B594F318A@oracle.com>
	<56F2737B.6050108@oracle.com>
	<604613F1-6641-40C3-A1A3-47C937133845@oracle.com>
Message-ID: <9366cb90-bf09-4ad2-a885-490eb3bfcb72@default>

Hello Avik,

 

x variable on line 2195 is not used anywhere. Do we need for loop also?

 

Regards,

Rajeev Chamyal

 

From: Avik Niyogi 
Sent: 24 March 2016 12:19
To: Alexander Scherbatiy
Cc: Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

 

Hi All,

 

Please review my code changes below as per the inputs received.

 

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/

 

As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation within the derived AquaTruncatedTabbedPaneLayout, extending of TabbedPaneScrollLayout is not needed and management of row and column height is done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight need not manage the number of columns and rows respectively and will remain 1 as tabs can be brought forth to the UI by the arrow buttons AQUA provides instead of placing them in another row or column. This is also the expected behaviour for AquaLAF as per javadoc.

 

With Regards,

Avik Niyogi

 

 

On 23-Mar-2016, at 4:14 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

 

On 23/03/16 14:07, Avik Niyogi wrote:



 

On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

 

On 21/03/16 09:19, Avik Niyogi wrote:



Hi Alexander, 

I agree with what you said regarding the look and feel looking different. But this bug arrises due to setting of TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua look and feel should not the setting of this parameter instead throw a helpful error saying this parameter is not accepted

  According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) javadoc:  
  "Some look and feels might only support a subset of the possible layout policies, in which case the value of this property may be ignored."
  
  Aqua L&F ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.

 

Actually, it is doing the other way around for Aqua L&F. It is defaulting WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of TabbedPaneLayout and not TabbedPaneScrollLayout.

   According to the JTabbedPane javadoc:
  SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset of available tabs when all the tabs will not fit within a single run.
  WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in multiple runs when all tabs will not fit within a single run.
 
   The Aqua L&F uses only AquaTabbedPaneUI and AquaTabbedPaneContrastUI for tabbed pane UI and they both returns AquaTruncatingTabbedPaneLayout which has been designed for to place tabs according to the SCROLL_TAB_LAYOUT.

  Thanks,
  Alexandr.







  Thanks,
  Alexandr.




instead of absorbing this parameter and letting it render itself into a dummy node which does not proceed further with this parameter? Maybe we need to discuss what the expected behaviour may be. Also, thank you for the inputs regarding how to proceed with removing duplicate code.

 

With Regards,

Avik Niyogi

On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

 


I would think about something like:
-------------
    public class TabbedPaneLayout implements LayoutManager {

        protected int basePreferredTabAreaWidth(final int tabPlacement, final int height) {
            // TabbedPaneLayout preferredTabAreaWidth implementation
        }

        protected int truncatingPreferredTabAreaWidth(final int tabPlacement, final int height) {
            if (tabPlacement == SwingConstants.LEFT || tabPlacement == SwingConstants.RIGHT) {
                return basePreferredTabAreaWidth(tabPlacement, height);
            }

            return basePreferredTabAreaWidth(tabPlacement, height);
        }

        protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
            return basePreferredTabAreaWidth(tabPlacement, height);
        }

    }

    class TabbedPaneScrollLayout extends TabbedPaneLayout {
        @Override
        protected int basePreferredTabAreaWidth(int tabPlacement, int height) {
            // TabbedPaneScrollLayout preferredTabAreaWidth implementation
        }
    }

    protected class AquaTruncatingTabbedPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {

        @Override
        protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
            return truncatingPreferredTabAreaWidth(tabPlacement, height);
        }
    }

    protected class AquaTruncatingTabbedScrollPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {

        @Override
        protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
            return truncatingPreferredTabAreaWidth(tabPlacement, height);
        }
    }
-------------

I just have one more question. The TabbedPaneScrollLayout is only created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 

Are there any real cases when the TabbedPaneScrollLayout is created?

When you enabled the AquaTruncatingTabbedScrollPaneLayout in the AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not look similar to Aqua L&F:
  HYPERLINK "http://cr.openjdk.java.net/%7Ealexsch/8137169/aqua-scrolled-tabbed-pane.png"http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png

The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs navigation.
May be the fix should update the AquaTruncatingTabbedPaneLayout only?

Thanks,
Alexandr.

On 18/03/16 14:21, Avik Niyogi wrote:

Hi Alexander, 

Thank you for the inputs. I agree with you and did feel the need for removing duplicate code as well. But as per an earlier review input, changes to the super call lay outing is not accepted. This was the only other feasible solution. Created redundant code in this process, but would be maintaining with requirements with code impact to superclasses.

Please provide any insight to a probable compensate to mitigate this dichotomy of code expectation. Thank you in advance.

 

With Regards,

Avik Niyogi

On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

 


It is not usually a good idea to have a duplicated code which should be updated every time in several places.

Is it possible to move the  methods used both in AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with different names and then reused?

Thanks,
Alexandr.

On 17/03/16 17:17, Avik Niyogi wrote:

Hi Alexander, 

The issue only applies for ScrollingTabbedPane and hence this fix.

 

With Regards,

Avik Niyogi

 

On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

 


Does the same issue affects the AquaTabbedPaneContrastUI?

Thanks,
Alexandr.

On 14/03/16 09:04, Avik Niyogi wrote:

Hi All, 

A gentle reminder, please review code changes.

 

With Regards,

Avik Niyogi

On 08-Mar-2016, at 9:51 pm, Avik Niyogi <HYPERLINK "mailto:avik.niyogi at oracle.com"avik.niyogi at oracle.com> wrote:

 

Hi All, 

 

Please review code changes done as with inputs provided.

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/

 

Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.

In the new fix as provided, references to base class layout manager is removed in current solution.

 

With Regards,

Avik Niyogi

 

On 02-Mar-2016, at 7:50 pm, Alexander Potochkin <HYPERLINK "mailto:alexander.potochkin at oracle.com"alexander.potochkin at oracle.com> wrote:

 

Hello Avik

Let me make it clear I don't approve the proposed fix
and ask you to do additional evaluation.

Every LookAndFeel is different and it doesn't make much sense
to compare Metal LaF with AquaLaf.

The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.

The bug you are fixing has the following subject 
"Incorrect minimal heigh of JTabbedPane with more tabs"

Could you please fix exactly the problem with the minimal heights,
without changing the UI delegate class.

Thanks
alexp

 

Gentle reminder. Please review this fix. 

 

On 26-Feb-2016, at 10:39 am, Avik Niyogi <HYPERLINK "mailto:avik.niyogi at oracle.com"avik.niyogi at oracle.com> wrote:

 

The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code 

 and not TabbedPaneLayout() as which is the default.

 

The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.

There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.

 

Fixing the minimum size in AquaTabbedPaneUI will fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.

 

Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.

Hence, with in-depth analysis, this fix has no other impact apart from this fix.

 

In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.

 

With Regards,

Avik Niyogi

 

On 25-Feb-2016, at 6:45 pm, Alexander Potochkin <HYPERLINK "mailto:alexander.potochkin at oracle.com"alexander.potochkin at oracle.com> wrote:

 

Hello Avik

AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
I don't think setting the layout manager from the base class is the right solution here.

If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI

Thanks
alexp

On 2/24/2016 12:07, Avik Niyogi wrote:

Hi All, 

 

Kindly review the bug fix for JDK 9.

 

Bug:

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

 

Webrev:

 

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/

 

Issue:

For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.

 

Cause:

The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()

 

Fix:

Major linking calls to super class fix done within createLayoutManager().

 

With Regards,

Avik Niyogi

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160324/880f4c83/attachment.html>

From avik.niyogi at oracle.com  Thu Mar 24 07:23:58 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 24 Mar 2016 12:53:58 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <9366cb90-bf09-4ad2-a885-490eb3bfcb72@default>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
	<A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
	<56F26982.9070608@oracle.com>
	<29DECA40-D3D8-4673-92F6-6E0B594F318A@oracle.com>
	<56F2737B.6050108@oracle.com>
	<604613F1-6641-40C3-A1A3-47C937133845@oracle.com>
	<9366cb90-bf09-4ad2-a885-490eb3bfcb72@default>
Message-ID: <467204A6-7721-4CBE-978C-B79D3C442699@oracle.com>

Hi All,
Please review code changes as per inputs received. 

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03 <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03>

As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation within the derived AquaTruncatedTabbedPaneLayout, extending of TabbedPaneScrollLayout is not needed and management of row and column height is done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight need not manage the number of columns and rows respectively and will remain 1 as tabs can be brought forth to the UI by the arrow buttons AQUA provides instead of placing them in another row or column. This is also the expected behaviour for AquaLAF as per javadoc.

With Regards,
Avik Niyogi

> On 24-Mar-2016, at 12:34 pm, Rajeev Chamyal <rajeev.chamyal at oracle.com> wrote:
> 
> Hello Avik,
>  
> x variable on line 2195 is not used anywhere. Do we need for loop also?
>  
> Regards,
> Rajeev Chamyal
>  
> From: Avik Niyogi 
> Sent: 24 March 2016 12:19
> To: Alexander Scherbatiy
> Cc: Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs
>  
> Hi All,
>  
> Please review my code changes below as per the inputs received.
>  
> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/>
>  
> As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation within the derived AquaTruncatedTabbedPaneLayout, extending of TabbedPaneScrollLayout is not needed and management of row and column height is done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight need not manage the number of columns and rows respectively and will remain 1 as tabs can be brought forth to the UI by the arrow buttons AQUA provides instead of placing them in another row or column. This is also the expected behaviour for AquaLAF as per javadoc.
>  
> With Regards,
> Avik Niyogi
>  
>  
> On 23-Mar-2016, at 4:14 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> On 23/03/16 14:07, Avik Niyogi wrote:
> 
>  
> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> On 21/03/16 09:19, Avik Niyogi wrote:
> 
> Hi Alexander, 
> I agree with what you said regarding the look and feel looking different. But this bug arrises due to setting of TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua look and feel should not the setting of this parameter instead throw a helpful error saying this parameter is not accepted
>   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) javadoc:  
>   "Some look and feels might only support a subset of the possible layout policies, in which case the value of this property may be ignored."
>   
>   Aqua L&F ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.
>  
> Actually, it is doing the other way around for Aqua L&F. It is defaulting WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of TabbedPaneLayout and not TabbedPaneScrollLayout.
>    According to the JTabbedPane javadoc:
>   SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset of available tabs when all the tabs will not fit within a single run.
>   WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in multiple runs when all tabs will not fit within a single run.
>  
>    The Aqua L&F uses only AquaTabbedPaneUI and AquaTabbedPaneContrastUI for tabbed pane UI and they both returns AquaTruncatingTabbedPaneLayout which has been designed for to place tabs according to the SCROLL_TAB_LAYOUT.
> 
>   Thanks,
>   Alexandr.
> 
> 
> 
>   Thanks,
>   Alexandr.
> 
> 
> instead of absorbing this parameter and letting it render itself into a dummy node which does not proceed further with this parameter? Maybe we need to discuss what the expected behaviour may be. Also, thank you for the inputs regarding how to proceed with removing duplicate code.
>  
> With Regards,
> Avik Niyogi
> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> 
> I would think about something like:
> -------------
>     public class TabbedPaneLayout implements LayoutManager {
> 
>         protected int basePreferredTabAreaWidth(final int tabPlacement, final int height) {
>             // TabbedPaneLayout preferredTabAreaWidth implementation
>         }
> 
>         protected int truncatingPreferredTabAreaWidth(final int tabPlacement, final int height) {
>             if (tabPlacement == SwingConstants.LEFT || tabPlacement == SwingConstants.RIGHT) {
>                 return basePreferredTabAreaWidth(tabPlacement, height);
>             }
> 
>             return basePreferredTabAreaWidth(tabPlacement, height);
>         }
> 
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return basePreferredTabAreaWidth(tabPlacement, height);
>         }
> 
>     }
> 
>     class TabbedPaneScrollLayout extends TabbedPaneLayout {
>         @Override
>         protected int basePreferredTabAreaWidth(int tabPlacement, int height) {
>             // TabbedPaneScrollLayout preferredTabAreaWidth implementation
>         }
>     }
> 
>     protected class AquaTruncatingTabbedPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
> 
>         @Override
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>         }
>     }
> 
>     protected class AquaTruncatingTabbedScrollPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
> 
>         @Override
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>         }
>     }
> -------------
> 
> I just have one more question. The TabbedPaneScrollLayout is only created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
> 
> Are there any real cases when the TabbedPaneScrollLayout is created?
> 
> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not look similar to Aqua L&F:
>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png <http://cr.openjdk.java.net/%7Ealexsch/8137169/aqua-scrolled-tabbed-pane.png>
> 
> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs navigation.
> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
> 
> Thanks,
> Alexandr.
> 
> On 18/03/16 14:21, Avik Niyogi wrote:
> Hi Alexander, 
> Thank you for the inputs. I agree with you and did feel the need for removing duplicate code as well. But as per an earlier review input, changes to the super call lay outing is not accepted. This was the only other feasible solution. Created redundant code in this process, but would be maintaining with requirements with code impact to superclasses.
> Please provide any insight to a probable compensate to mitigate this dichotomy of code expectation. Thank you in advance.
>  
> With Regards,
> Avik Niyogi
> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> 
> It is not usually a good idea to have a duplicated code which should be updated every time in several places.
> 
> Is it possible to move the  methods used both in AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with different names and then reused?
> 
> Thanks,
> Alexandr.
> 
> On 17/03/16 17:17, Avik Niyogi wrote:
> Hi Alexander, 
> The issue only applies for ScrollingTabbedPane and hence this fix.
>  
> With Regards,
> Avik Niyogi
>  
> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> 
> Does the same issue affects the AquaTabbedPaneContrastUI?
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 09:04, Avik Niyogi wrote:
> Hi All, 
> A gentle reminder, please review code changes.
>  
> With Regards,
> Avik Niyogi
> On 08-Mar-2016, at 9:51 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>  
> Hi All, 
>  
> Please review code changes done as with inputs provided.
> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/>
>  
> Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
> In the new fix as provided, references to base class layout manager is removed in current solution.
>  
> With Regards,
> Avik Niyogi
>  
> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin <alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>  
> Hello Avik
> 
> Let me make it clear I don't approve the proposed fix
> and ask you to do additional evaluation.
> 
> Every LookAndFeel is different and it doesn't make much sense
> to compare Metal LaF with AquaLaf.
> 
> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
> 
> The bug you are fixing has the following subject 
> "Incorrect minimal heigh of JTabbedPane with more tabs"
> 
> Could you please fix exactly the problem with the minimal heights,
> without changing the UI delegate class.
> 
> Thanks
> alexp
>  
> Gentle reminder. Please review this fix. 
>  
> On 26-Feb-2016, at 10:39 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>  
> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code 
>  and notTabbedPaneLayout() as which is the default.
>  
> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>  
> Fixing the minimum size in AquaTabbedPaneUIwill fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>  
> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>  
> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>  
> With Regards,
> Avik Niyogi
>  
> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin <alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>  
> Hello Avik
> 
> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
> I don't think setting the layout manager from the base class is the right solution here.
> 
> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
> 
> Thanks
> alexp
> 
> On 2/24/2016 12:07, Avik Niyogi wrote:
> Hi All,
>  
> Kindly review the bug fix for JDK 9.
>  
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>  
> Webrev:
>  
> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>
>  
> Issue:
> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>  
> Cause:
> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>  
> Fix:
> Major linking calls to super class fix done within createLayoutManager().
>  
> With Regards,
> Avik Niyogi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160324/84a4c8ed/attachment.html>

From rajeev.chamyal at oracle.com  Thu Mar 24 08:33:04 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Thu, 24 Mar 2016 01:33:04 -0700 (PDT)
Subject: <Swing Dev> Review Request for 6439354 : Win L&F: TitledBorder
 colors are not from desktop
In-Reply-To: <56F385CD.1040400@oracle.com>
References: <9dfecb85-567d-410c-b60a-9b8976521e55@default>
	<56EFFEA6.7040408@oracle.com>
	<34d597fe-a34e-4693-b2cb-3e4dbe0b746a@default>
	<56F385CD.1040400@oracle.com>
Message-ID: <e654c461-d1bb-412c-92b7-e0534ac73da5@default>

Looks good to me.

Regards,
Rajeev Chamyal

-----Original Message-----
From: Semyon Sadetsky 
Sent: 24 March 2016 11:45
To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net
Subject: Re: Review Request for 6439354 : Win L&F: TitledBorder colors are not from desktop

Looks good.

--Semyon

On 3/22/2016 11:56 AM, Prem Balakrishnan wrote:
> Hi Sergey,
>
> Updated test as per the review comments.
>
> Webrev: http://cr.openjdk.java.net/~arapte/prem/6439354/webrev.01/
>
> Regards,
> Prem
>
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Monday, March 21, 2016 7:31 PM
> To: Prem Balakrishnan; Semyon Sadetsky; Rajeev Chamyal; Alexander 
> Scherbatiy; swing-dev at openjdk.java.net
> Subject: Re: Review Request for 6439354 : Win L&F: TitledBorder colors 
> are not from desktop
>
> Hi, Prem.
> In the test the Swing components accessed on non-EDT thread. Probably the test can be simplified further?
>
> On 21.03.16 11:20, Prem Balakrishnan wrote:
>> Hi*,*
>>
>> Please review fix for JDK 9,
>>
>> *Bug: *https://bugs.openjdk.java.net/browse/JDK-6439354 **
>>
>> *Webrev: *http://cr.openjdk.java.net/~arapte/prem/6439354/webrev.00/
>>
>> *Issue:*
>>
>> Win L&F: TitledBorder colors are not from desktop
>>
>> *Cause:*
>>
>> "TitledBorder.border" is set to EtchedBorder with default 
>> highlight/shadow colors.
>>
>> *Fix:*
>>
>> "TitledBorder.border" is set to  EtchedBorder with Desktop
>>    highlight/shadow colors.
>>
>> **
>>
>> *Test: *Manual Test (since windows theme to be set)**
>>
>> **
>>
>> Regards,
>> Prem
>>
>
> --
> Best regards, Sergey.



From rajeev.chamyal at oracle.com  Thu Mar 24 09:31:36 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Thu, 24 Mar 2016 02:31:36 -0700 (PDT)
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
 minimal heigh of JTabbedPane with more tabs
In-Reply-To: <467204A6-7721-4CBE-978C-B79D3C442699@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
	<A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
	<56F26982.9070608@oracle.com>
	<29DECA40-D3D8-4673-92F6-6E0B594F318A@oracle.com>
	<56F2737B.6050108@oracle.com>
	<604613F1-6641-40C3-A1A3-47C937133845@oracle.com>
	<9366cb90-bf09-4ad2-a885-490eb3bfcb72@default>
	<467204A6-7721-4CBE-978C-B79D3C442699@oracle.com>
Message-ID: <b4d57a58-6840-408d-8b88-1664df190602@default>

Looks good to me.

 

Regards,

Rajeev Chamyal

 

From: Avik Niyogi 
Sent: 24 March 2016 12:54
To: Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

 

Hi All,

Please review code changes as per inputs received. 

 

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03

 

As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation within the derived AquaTruncatedTabbedPaneLayout, extending of TabbedPaneScrollLayout is not needed and management of row and column height is done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight need not manage the number of columns and rows respectively and will remain 1 as tabs can be brought forth to the UI by the arrow buttons AQUA provides instead of placing them in another row or column. This is also the expected behaviour for AquaLAF as per javadoc.

 

With Regards,

Avik Niyogi

 

On 24-Mar-2016, at 12:34 pm, Rajeev Chamyal <HYPERLINK "mailto:rajeev.chamyal at oracle.com"rajeev.chamyal at oracle.com> wrote:

 

Hello Avik,

 

x variable on line 2195 is not used anywhere. Do we need for loop also?

 

Regards,

Rajeev Chamyal

 

From: Avik Niyogi 
Sent: 24 March 2016 12:19
To: Alexander Scherbatiy
Cc: Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

 

Hi All,

 

Please review my code changes below as per the inputs received.

 

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/

 

As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation within the derived AquaTruncatedTabbedPaneLayout, extending of TabbedPaneScrollLayout is not needed and management of row and column height is done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight need not manage the number of columns and rows respectively and will remain 1 as tabs can be brought forth to the UI by the arrow buttons AQUA provides instead of placing them in another row or column. This is also the expected behaviour for AquaLAF as per javadoc.

 

With Regards,

Avik Niyogi

 

 

On 23-Mar-2016, at 4:14 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

 

On 23/03/16 14:07, Avik Niyogi wrote:




 

On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

 

On 21/03/16 09:19, Avik Niyogi wrote:




Hi Alexander, 

I agree with what you said regarding the look and feel looking different. But this bug arrises due to setting of TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua look and feel should not the setting of this parameter instead throw a helpful error saying this parameter is not accepted

  According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) javadoc:  
  "Some look and feels might only support a subset of the possible layout policies, in which case the value of this property may be ignored."
  
  Aqua L&F ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.

 

Actually, it is doing the other way around for Aqua L&F. It is defaulting WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of TabbedPaneLayout and not TabbedPaneScrollLayout.

   According to the JTabbedPane javadoc:
  SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset of available tabs when all the tabs will not fit within a single run.
  WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in multiple runs when all tabs will not fit within a single run.
 
   The Aqua L&F uses only AquaTabbedPaneUI and AquaTabbedPaneContrastUI for tabbed pane UI and they both returns AquaTruncatingTabbedPaneLayout which has been designed for to place tabs according to the SCROLL_TAB_LAYOUT.

  Thanks,
  Alexandr.









  Thanks,
  Alexandr.





instead of absorbing this parameter and letting it render itself into a dummy node which does not proceed further with this parameter? Maybe we need to discuss what the expected behaviour may be. Also, thank you for the inputs regarding how to proceed with removing duplicate code.

 

With Regards,

Avik Niyogi

On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

 


I would think about something like:
-------------
    public class TabbedPaneLayout implements LayoutManager {

        protected int basePreferredTabAreaWidth(final int tabPlacement, final int height) {
            // TabbedPaneLayout preferredTabAreaWidth implementation
        }

        protected int truncatingPreferredTabAreaWidth(final int tabPlacement, final int height) {
            if (tabPlacement == SwingConstants.LEFT || tabPlacement == SwingConstants.RIGHT) {
                return basePreferredTabAreaWidth(tabPlacement, height);
            }

            return basePreferredTabAreaWidth(tabPlacement, height);
        }

        protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
            return basePreferredTabAreaWidth(tabPlacement, height);
        }

    }

    class TabbedPaneScrollLayout extends TabbedPaneLayout {
        @Override
        protected int basePreferredTabAreaWidth(int tabPlacement, int height) {
            // TabbedPaneScrollLayout preferredTabAreaWidth implementation
        }
    }

    protected class AquaTruncatingTabbedPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {

        @Override
        protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
            return truncatingPreferredTabAreaWidth(tabPlacement, height);
        }
    }

    protected class AquaTruncatingTabbedScrollPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {

        @Override
        protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
            return truncatingPreferredTabAreaWidth(tabPlacement, height);
        }
    }
-------------

I just have one more question. The TabbedPaneScrollLayout is only created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 

Are there any real cases when the TabbedPaneScrollLayout is created?

When you enabled the AquaTruncatingTabbedScrollPaneLayout in the AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not look similar to Aqua L&F:
  HYPERLINK "http://cr.openjdk.java.net/%7Ealexsch/8137169/aqua-scrolled-tabbed-pane.png"http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png

The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs navigation.
May be the fix should update the AquaTruncatingTabbedPaneLayout only?

Thanks,
Alexandr.

On 18/03/16 14:21, Avik Niyogi wrote:

Hi Alexander, 

Thank you for the inputs. I agree with you and did feel the need for removing duplicate code as well. But as per an earlier review input, changes to the super call lay outing is not accepted. This was the only other feasible solution. Created redundant code in this process, but would be maintaining with requirements with code impact to superclasses.

Please provide any insight to a probable compensate to mitigate this dichotomy of code expectation. Thank you in advance.

 

With Regards,

Avik Niyogi

On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

 


It is not usually a good idea to have a duplicated code which should be updated every time in several places.

Is it possible to move the  methods used both in AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with different names and then reused?

Thanks,
Alexandr.

On 17/03/16 17:17, Avik Niyogi wrote:

Hi Alexander, 

The issue only applies for ScrollingTabbedPane and hence this fix.

 

With Regards,

Avik Niyogi

 

On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"alexandr.scherbatiy at oracle.com> wrote:

 


Does the same issue affects the AquaTabbedPaneContrastUI?

Thanks,
Alexandr.

On 14/03/16 09:04, Avik Niyogi wrote:

Hi All, 

A gentle reminder, please review code changes.

 

With Regards,

Avik Niyogi

On 08-Mar-2016, at 9:51 pm, Avik Niyogi <HYPERLINK "mailto:avik.niyogi at oracle.com"avik.niyogi at oracle.com> wrote:

 

Hi All, 

 

Please review code changes done as with inputs provided.

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/

 

Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.

In the new fix as provided, references to base class layout manager is removed in current solution.

 

With Regards,

Avik Niyogi

 

On 02-Mar-2016, at 7:50 pm, Alexander Potochkin <HYPERLINK "mailto:alexander.potochkin at oracle.com"alexander.potochkin at oracle.com> wrote:

 

Hello Avik

Let me make it clear I don't approve the proposed fix
and ask you to do additional evaluation.

Every LookAndFeel is different and it doesn't make much sense
to compare Metal LaF with AquaLaf.

The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.

The bug you are fixing has the following subject 
"Incorrect minimal heigh of JTabbedPane with more tabs"

Could you please fix exactly the problem with the minimal heights,
without changing the UI delegate class.

Thanks
alexp

 

Gentle reminder. Please review this fix. 

 

On 26-Feb-2016, at 10:39 am, Avik Niyogi <HYPERLINK "mailto:avik.niyogi at oracle.com"avik.niyogi at oracle.com> wrote:

 

The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code 

 and notTabbedPaneLayout() as which is the default.

 

The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.

There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.

 

Fixing the minimum size in AquaTabbedPaneUIwill fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.

 

Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.

Hence, with in-depth analysis, this fix has no other impact apart from this fix.

 

In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.

 

With Regards,

Avik Niyogi

 

On 25-Feb-2016, at 6:45 pm, Alexander Potochkin <HYPERLINK "mailto:alexander.potochkin at oracle.com"alexander.potochkin at oracle.com> wrote:

 

Hello Avik

AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
I don't think setting the layout manager from the base class is the right solution here.

If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI

Thanks
alexp

On 2/24/2016 12:07, Avik Niyogi wrote:

Hi All, 

 

Kindly review the bug fix for JDK 9.

 

Bug:

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

 

Webrev:

 

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/

 

Issue:

For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.

 

Cause:

The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()

 

Fix:

Major linking calls to super class fix done within createLayoutManager().

 

With Regards,

Avik Niyogi

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160324/bf375161/attachment.html>

From avik.niyogi at oracle.com  Thu Mar 24 09:45:43 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 24 Mar 2016 15:15:43 +0530
Subject: <Swing Dev> [9] Review request for JDK-8150225
	api/javax_swing/text/AbstractWriter/index_indent failed
Message-ID: <6F65F7A2-3C7D-4627-A812-836724814504@oracle.com>

Hi Rajeev,

The fix looks fine to me.

With Regards,
Avik Niyogi

-----Original Message-----
From: Rajeev Chamyal 
Sent: 23 March 2016 14:45
To: Sergey Bylokhov; Alexander Scherbatiy; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
Subject: RE: <Swing Dev> [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed

Hello Sergey,

I had found below link about pre tag which states A P tag is strictly not permitted inside PRE, but if a browser encounters one, it should treat it as two newlines.
http://www.htmlhelp.com/reference/wilbur/block/pre.html <http://www.htmlhelp.com/reference/wilbur/block/pre.html> 

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov
Sent: 22 March 2016 21:58
To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed

Looks fine to me. But I am not an expert here. And I wonder why the <p> tag is so specific, can we get the similar issue if some other tags will be used instead?

On 22.03.16 11:35, Rajeev Chamyal wrote:
> Hello All,
> 
> Gentle reminder.
> Please review the fix.
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225 <https://bugs.openjdk.java.net/browse/JDK-8150225>
> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/ <http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/>
> 
> Regards,
> Rajeev Chamyal
> 
> -----Original Message-----
> From: Rajeev Chamyal
> Sent: 09 March 2016 15:58
> To: Sergey Bylokhov; Alexander Scherbatiy; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 
> api/javax_swing/text/AbstractWriter/index_indent failed
> 
> Hello Sergey,
> 
> I have run JCK tests for HTMLWriter and AbstractWriter with this fix and all passed.
> 
> Regards,
> Rajeev Chamyal
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 09 March 2016 15:54
> To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> [9] Review request for JDK-8150225 
> api/javax_swing/text/AbstractWriter/index_indent failed
> 
> Hi, Rajeev.
> Please confirm that there are no new issues in the jck after this fix.
> 
> On 09.03.16 12:18, Rajeev Chamyal wrote:
>> Hello All,
>> 
>> Please review the following fix for Jdk9:
>> 
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225 <https://bugs.openjdk.java.net/browse/JDK-8150225>
>> 
>> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/ <http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/>
>> <http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/ <http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/>>
>> 
>> Issue : JCK conformance test failed due to fix for bug JDK-7104635
>> 
>> Fix: Reverted the fix for JDK-7104635 and added a new method in 
>> HTMLWriter.java to check if P tag is within Pre tag.
>> 
>> Decrement indentation is skipped if P tag is with a Pre tag.
>> 
>> Regards,
>> 
>> Rajeev Chamyal
>> 
> 
> 
> --
> Best regards, Sergey.
> 


--
Best regards, Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160324/a02f327a/attachment.html>

From ajit.ghaisas at oracle.com  Thu Mar 24 09:55:03 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Thu, 24 Mar 2016 02:55:03 -0700 (PDT)
Subject: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on button
	release
Message-ID: <b8077c49-2413-40ed-b765-43847cc52eb6@default>

Hi,

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

Issue :  A JButton which is pressed using left mouse button gets released if right mouse button is pressed and released.

Root cause :
---------------
In file BasicButtonListener.java, mousePressed() and mouseReleased() methods check whether the event is from left mouse button.
This check is done using ----  if (SwingUtilities.isLeftMouseButton(e) ) 
This method returns true if left mouse button is down OR event is from left mouse button.
SwingUtilities.isLeftMouseButton() returns true if it is called for right mouse event while holding left button down. This causes mouseReleased() method to release pressed JButton.


Alternatives considered :
-----------------------------
1. Modifying SwingUtilities.isLeftMouseButton() method to only test for whether the event is from left mouse button only
2. Modifying mousePressed() and mouseReleased() methods to check for whether the event is from left mouse button using argument passed to them.

Option 1 will break the code wherever SwingUtilities.isLeftMouseButton() is used to test for left mouse button down.
File history revealed that the mouse button down condition is added to fix another bug.

Hence, option 2 is chosen as it is safe and intuitive.
I have also added a test. It passes on Windows, Linux and Mac.
Test mentioned in comment on the bug also passed.

Please review the webrev :

http://cr.openjdk.java.net/~aghaisas/8049069/webrev.00/

Regards,
Ajit


From alexandr.scherbatiy at oracle.com  Thu Mar 24 10:45:26 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 24 Mar 2016 14:45:26 +0400
Subject: <Swing Dev> CFV: New Swing Group Member: Semyon Sadetsky
In-Reply-To: <56EF8E29.4070605@oracle.com>
References: <56EF8E29.4070605@oracle.com>
Message-ID: <56F3C546.8070402@oracle.com>


Vote: yes.

Thanks,
Alexandr.

On 21/03/16 10:01, Alexander Scherbatiy wrote:
>
> I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to 
> Membership in the Swing Group.
>
> Semyon is active member of Swing group and contributed a lot of fixes 
> which include Swing TimerQueue race condition improvement, UndoManager 
> deadlock resolving, proposing and implementation a public API for 
> internal Swing functionality which is part of Swing modularization 
> support for JDK 9, and others (see Semyon?s list OpenJDK changesets [1])
>
> Semyon proposed a big change for the Swing part of the JEP 283 ?Enable 
> GTK 3 on Linux? [2] implementation [3].
>
> Semyon not only provides fixes for Swing issues but also regularly 
> reviews fixes suggested by other members.
>
> Votes are due by Apr 5, 2016.
>
> Only current Members of the Swing  Group [4] are eligible
> to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [5].
>
> Thanks,
> Alexandr.
>
> [1] 
> http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ssadetsky%22%29
> [2] http://openjdk.java.net/jeps/283
> [3] 
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005440.html
> [4] http://openjdk.java.net/census#swing
> [5] http://openjdk.java.net/groups/#member-vote



From Sergey.Bylokhov at oracle.com  Thu Mar 24 11:16:33 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 24 Mar 2016 14:16:33 +0300
Subject: <Swing Dev> Review Request for 6439354 : Win L&F: TitledBorder
 colors are not from desktop
In-Reply-To: <34d597fe-a34e-4693-b2cb-3e4dbe0b746a@default>
References: <9dfecb85-567d-410c-b60a-9b8976521e55@default>
	<56EFFEA6.7040408@oracle.com>
	<34d597fe-a34e-4693-b2cb-3e4dbe0b746a@default>
Message-ID: <56F3CC91.3060008@oracle.com>

+1 thanks.

On 22.03.16 11:56, Prem Balakrishnan wrote:
> Hi Sergey,
>
> Updated test as per the review comments.
>
> Webrev: http://cr.openjdk.java.net/~arapte/prem/6439354/webrev.01/
>
> Regards,
> Prem
>
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Monday, March 21, 2016 7:31 PM
> To: Prem Balakrishnan; Semyon Sadetsky; Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net
> Subject: Re: Review Request for 6439354 : Win L&F: TitledBorder colors are not from desktop
>
> Hi, Prem.
> In the test the Swing components accessed on non-EDT thread. Probably the test can be simplified further?
>
> On 21.03.16 11:20, Prem Balakrishnan wrote:
>> Hi*,*
>>
>> Please review fix for JDK 9,
>>
>> *Bug: *https://bugs.openjdk.java.net/browse/JDK-6439354 **
>>
>> *Webrev: *http://cr.openjdk.java.net/~arapte/prem/6439354/webrev.00/
>>
>> *Issue:*
>>
>> Win L&F: TitledBorder colors are not from desktop
>>
>> *Cause:*
>>
>> "TitledBorder.border" is set to EtchedBorder with default
>> highlight/shadow colors.
>>
>> *Fix:*
>>
>> "TitledBorder.border" is set to  EtchedBorder with Desktop
>>    highlight/shadow colors.
>>
>> **
>>
>> *Test: *Manual Test (since windows theme to be set)**
>>
>> **
>>
>> Regards,
>> Prem
>>
>
>
> --
> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Thu Mar 24 13:52:58 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 24 Mar 2016 17:52:58 +0400
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56F38B0B.3060700@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com>
Message-ID: <56F3F13A.9000808@oracle.com>

On 24/03/16 10:36, Semyon Sadetsky wrote:
> Hi Alexander,
>
> Could you answer one question:
> Why did you choose default interface methods to implement 
> TextUIDrawing and not implement them in DefaultTextUIDrawing having 
> declarations only in the interface?
> AFAIK the common point of view is default methods should be used 
> rarely because they may lead to unreadable code.
>
   The only problem which I know about default methods is multiple 
inheritance which has its own solution.

   Could you give links to discussion or provide use cases where default 
methods leads to the unreadable code and show how does it relate to the 
TextUIDrawing  implementation?

   Thanks,
   Alexandr.
> --Semyon
>
> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>
>> Could you review the updated fix:
>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>
>>   - Public TextUIDrawing interface is added to the javax.swing.plaf 
>> package
>>   - TextUIDrawing methods description does not mention component 
>> properties to be more general
>>   - TextUIDrawing methods are made default
>>   - L&F sets an instance of the TextUIDrawing to look and feel 
>> defaults using "uiDrawing.text" property
>>   - ComponentUI class is not changed
>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>   - There is an interesting issue described in
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>>     which is related to the fact that MetalLabelUI returns a static 
>> field from createUI() method.
>>     TitleBorder creates a JLabel but does not put it to any component 
>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() method 
>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI 
>> field and sets a new LabelUI for ordinary labels. The TitleBorder 
>> label UI is not changed in this case and it still uses the 
>> metalLabelUI field which is not initialized.
>>     It seems that other applications can also use components just for 
>> drawing and have the same issue.
>>     For this case the textUIDrawing field is not cleared in the 
>> uninstallDefaults but just set to a static default value which should 
>> not lead to memory leaks.
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>> Hi Alexandr,
>>>>
>>>>> Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>> ....
>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf 
>>>>> package
>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>>> ComponentUI class
>>>>> - L&F sets an instance of the TextUIDrawing to look and feel 
>>>>> defaults using
>>>>> "uiDrawing.text" property
>>>>> - Look and Feel delegates use the instance of the TextUIDrawing 
>>>>> for text
>>>>> drawing and measuring
>>>> Some thoughts on the current design/implementation:
>>>>
>>>> By adding a field to the ComponentUI class the current 
>>>> implementation increases
>>>> memory consumption for all Swing applications. And you get the 
>>>> feeling that
>>>> there are different implementations of TextUIDrawing per 
>>>> ComponentUI instances.
>>>> Personally I can't imagine to have different implementations of
>>>> TextUIDrawing for
>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>> implement it as
>>>> a property of the LookAndFeel class (similar to LayoutStyle) and not
>>>> the ComponentUI.
>>>> Developers can use then the following code to obtain the instance of
>>>> TextUIDrawing:
>>>>
>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>> short cut for the line above.
>>>   LayoutStyle keeps its instance per App context. The same is for 
>>> the LookAndFeel
>>>   when it is got through UIManager.getLookAndFeel() call.
>>>   It means that accessing an instance of a TextUIDrawing will leads 
>>> to a time consumption.
>>>
>>>   There are 3 main ways of the SwingUtilities2.drawString(...) usage:
>>>   1. ComponentUI classes
>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>   3. Public utilities methods (like WindowsGraphicsUtils.paintText())
>>>
>>>   For the cases 1 and 2 it is possible to load and store the 
>>> UIDrawing instance during installUI()/updateUI() calls to decrease a 
>>> time access to it.
>>>
>>>   For the case 3 it is necessary to get LookAndFeel instance each 
>>> time (which is taken from an App context)
>>>   or use the passed JComponent object. It requires to have a public 
>>> method and the associated variable for each instance of 
>>> JComponent/ComponentUI/... class.
>>>> You can use this methods then in JDK too.
>>>>
>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>> more useful methods,
>>>> e.g. a method to create a composite font, a method to convert DLUs 
>>>> to pixels.
>>>   UIDrawing name may look like it should be used for any UI drawing, 
>>> not only for text ones. I am afraid that it can be misleading.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>>
>>>> Best regards,
>>>> Andrej Golovnin
>>>
>>
>



From semyon.sadetsky at oracle.com  Thu Mar 24 14:13:37 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 24 Mar 2016 17:13:37 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56F3F13A.9000808@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
Message-ID: <56F3F611.2000600@oracle.com>



On 3/24/2016 4:52 PM, Alexander Scherbatiy wrote:
> On 24/03/16 10:36, Semyon Sadetsky wrote:
>> Hi Alexander,
>>
>> Could you answer one question:
>> Why did you choose default interface methods to implement 
>> TextUIDrawing and not implement them in DefaultTextUIDrawing having 
>> declarations only in the interface?
>> AFAIK the common point of view is default methods should be used 
>> rarely because they may lead to unreadable code.
>>
>   The only problem which I know about default methods is multiple 
> inheritance which has its own solution.
>
>   Could you give links to discussion or provide use cases where 
> default methods leads to the unreadable code and show how does it 
> relate to the TextUIDrawing  implementation?
Yes, multiple inheritance is the problem.
>
>   Thanks,
>   Alexandr.
>> --Semyon
>>
>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>
>>> Could you review the updated fix:
>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>
>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf 
>>> package
>>>   - TextUIDrawing methods description does not mention component 
>>> properties to be more general
>>>   - TextUIDrawing methods are made default
>>>   - L&F sets an instance of the TextUIDrawing to look and feel 
>>> defaults using "uiDrawing.text" property
>>>   - ComponentUI class is not changed
>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>   - There is an interesting issue described in
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>>>     which is related to the fact that MetalLabelUI returns a static 
>>> field from createUI() method.
>>>     TitleBorder creates a JLabel but does not put it to any 
>>> component hierarchy. In this case 
>>> SwingUtilities.updateComponentTreeUI() method calls 
>>> MetalLabelUI.uninstallDefaults() on the static metalLabelUI field 
>>> and sets a new LabelUI for ordinary labels. The TitleBorder label UI 
>>> is not changed in this case and it still uses the metalLabelUI field 
>>> which is not initialized.
>>>     It seems that other applications can also use components just 
>>> for drawing and have the same issue.
>>>     For this case the textUIDrawing field is not cleared in the 
>>> uninstallDefaults but just set to a static default value which 
>>> should not lead to memory leaks.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>> Hi Alexandr,
>>>>>
>>>>>> Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>> ....
>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf 
>>>>>> package
>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>>>> ComponentUI class
>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel 
>>>>>> defaults using
>>>>>> "uiDrawing.text" property
>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing 
>>>>>> for text
>>>>>> drawing and measuring
>>>>> Some thoughts on the current design/implementation:
>>>>>
>>>>> By adding a field to the ComponentUI class the current 
>>>>> implementation increases
>>>>> memory consumption for all Swing applications. And you get the 
>>>>> feeling that
>>>>> there are different implementations of TextUIDrawing per 
>>>>> ComponentUI instances.
>>>>> Personally I can't imagine to have different implementations of
>>>>> TextUIDrawing for
>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>> implement it as
>>>>> a property of the LookAndFeel class (similar to LayoutStyle) and not
>>>>> the ComponentUI.
>>>>> Developers can use then the following code to obtain the instance of
>>>>> TextUIDrawing:
>>>>>
>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>> short cut for the line above.
>>>>   LayoutStyle keeps its instance per App context. The same is for 
>>>> the LookAndFeel
>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>   It means that accessing an instance of a TextUIDrawing will leads 
>>>> to a time consumption.
>>>>
>>>>   There are 3 main ways of the SwingUtilities2.drawString(...) usage:
>>>>   1. ComponentUI classes
>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>   3. Public utilities methods (like WindowsGraphicsUtils.paintText())
>>>>
>>>>   For the cases 1 and 2 it is possible to load and store the 
>>>> UIDrawing instance during installUI()/updateUI() calls to decrease 
>>>> a time access to it.
>>>>
>>>>   For the case 3 it is necessary to get LookAndFeel instance each 
>>>> time (which is taken from an App context)
>>>>   or use the passed JComponent object. It requires to have a public 
>>>> method and the associated variable for each instance of 
>>>> JComponent/ComponentUI/... class.
>>>>> You can use this methods then in JDK too.
>>>>>
>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>> more useful methods,
>>>>> e.g. a method to create a composite font, a method to convert DLUs 
>>>>> to pixels.
>>>>   UIDrawing name may look like it should be used for any UI 
>>>> drawing, not only for text ones. I am afraid that it can be 
>>>> misleading.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>>
>>>>> Best regards,
>>>>> Andrej Golovnin
>>>>
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Thu Mar 24 14:22:52 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 24 Mar 2016 17:22:52 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56F3F13A.9000808@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
Message-ID: <56F3F83C.3010706@oracle.com>

On 24.03.16 16:52, Alexander Scherbatiy wrote:
> On 24/03/16 10:36, Semyon Sadetsky wrote:
>> Hi Alexander,
>>
>> Could you answer one question:
>> Why did you choose default interface methods to implement
>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>> declarations only in the interface?
>> AFAIK the common point of view is default methods should be used
>> rarely because they may lead to unreadable code.
>>
>    The only problem which I know about default methods is multiple
> inheritance which has its own solution.

What kind of problems? The benefit is obvious: it will not be necessary 
to implement all methods if only one of them should be tweaked.

>
>    Could you give links to discussion or provide use cases where default
> methods leads to the unreadable code and show how does it relate to the
> TextUIDrawing  implementation?
>
>    Thanks,
>    Alexandr.
>> --Semyon
>>
>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>
>>> Could you review the updated fix:
>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>
>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>> package
>>>   - TextUIDrawing methods description does not mention component
>>> properties to be more general
>>>   - TextUIDrawing methods are made default
>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>> defaults using "uiDrawing.text" property
>>>   - ComponentUI class is not changed
>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>   - There is an interesting issue described in
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>>>     which is related to the fact that MetalLabelUI returns a static
>>> field from createUI() method.
>>>     TitleBorder creates a JLabel but does not put it to any component
>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() method
>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>> label UI is not changed in this case and it still uses the
>>> metalLabelUI field which is not initialized.
>>>     It seems that other applications can also use components just for
>>> drawing and have the same issue.
>>>     For this case the textUIDrawing field is not cleared in the
>>> uninstallDefaults but just set to a static default value which should
>>> not lead to memory leaks.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>> Hi Alexandr,
>>>>>
>>>>>> Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>> ....
>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>> package
>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>>>> ComponentUI class
>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>> defaults using
>>>>>> "uiDrawing.text" property
>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>> for text
>>>>>> drawing and measuring
>>>>> Some thoughts on the current design/implementation:
>>>>>
>>>>> By adding a field to the ComponentUI class the current
>>>>> implementation increases
>>>>> memory consumption for all Swing applications. And you get the
>>>>> feeling that
>>>>> there are different implementations of TextUIDrawing per
>>>>> ComponentUI instances.
>>>>> Personally I can't imagine to have different implementations of
>>>>> TextUIDrawing for
>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>> implement it as
>>>>> a property of the LookAndFeel class (similar to LayoutStyle) and not
>>>>> the ComponentUI.
>>>>> Developers can use then the following code to obtain the instance of
>>>>> TextUIDrawing:
>>>>>
>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>> short cut for the line above.
>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>> the LookAndFeel
>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>   It means that accessing an instance of a TextUIDrawing will leads
>>>> to a time consumption.
>>>>
>>>>   There are 3 main ways of the SwingUtilities2.drawString(...) usage:
>>>>   1. ComponentUI classes
>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>   3. Public utilities methods (like WindowsGraphicsUtils.paintText())
>>>>
>>>>   For the cases 1 and 2 it is possible to load and store the
>>>> UIDrawing instance during installUI()/updateUI() calls to decrease a
>>>> time access to it.
>>>>
>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>> time (which is taken from an App context)
>>>>   or use the passed JComponent object. It requires to have a public
>>>> method and the associated variable for each instance of
>>>> JComponent/ComponentUI/... class.
>>>>> You can use this methods then in JDK too.
>>>>>
>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>> more useful methods,
>>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>>> to pixels.
>>>>   UIDrawing name may look like it should be used for any UI drawing,
>>>> not only for text ones. I am afraid that it can be misleading.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>>
>>>>> Best regards,
>>>>> Andrej Golovnin
>>>>
>>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Mar 24 14:34:26 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 24 Mar 2016 17:34:26 +0300
Subject: <Swing Dev> <AWT Dev> [9] Review Request for several test bugs:
 8150535, 8151033, 8151037 etc.
In-Reply-To: <56F3F70D.3070809@oracle.com>
References: <56F3F70D.3070809@oracle.com>
Message-ID: <56F3FAF2.6060009@oracle.com>

cc swing-dev

On 24.03.16 17:17, Yuri Nesterenko wrote:
> Hi,
>
> please review this test-only fix, a leftover from Jigsaw M3 integration.
> Some 7 tests fixed but note that not all of them always pass even fixed.
> Webrev:
> http://cr.openjdk.java.net/~yan/8150535/webrev.01
>
> I need to file a bug about the fixed here manual test
> java/awt/xembed/server/TestXEmbedServerJava
>
> Thank you!
>
> -yan


-- 
Best regards, Sergey.


From yuri.nesterenko at oracle.com  Thu Mar 24 15:12:08 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 24 Mar 2016 18:12:08 +0300
Subject: <Swing Dev> <AWT Dev> [9] Review Request for several test bugs:
 8150535, 8151033, 8151037 etc.
In-Reply-To: <56F3FAF2.6060009@oracle.com>
References: <56F3F70D.3070809@oracle.com> <56F3FAF2.6060009@oracle.com>
Message-ID: <56F403C8.7050609@oracle.com>

Sergey, I'm sorry,
filing JDK-8152693, I found an error in that version.

A new one is
http://cr.openjdk.java.net/~yan/8150535/webrev.02
The spawned processes were provided with addExports.

Shame on me!
-yan


On 03/24/2016 05:34 PM, Sergey Bylokhov wrote:
> cc swing-dev
>
> On 24.03.16 17:17, Yuri Nesterenko wrote:
>> Hi,
>>
>> please review this test-only fix, a leftover from Jigsaw M3 integration.
>> Some 7 tests fixed but note that not all of them always pass even fixed.
>> Webrev:
>> http://cr.openjdk.java.net/~yan/8150535/webrev.01
>>
>> I need to file a bug about the fixed here manual test
>> java/awt/xembed/server/TestXEmbedServerJava
>>
>> Thank you!
>>
>> -yan
>
>



From Sergey.Bylokhov at oracle.com  Thu Mar 24 22:02:48 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 25 Mar 2016 01:02:48 +0300
Subject: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on
 button release
In-Reply-To: <b8077c49-2413-40ed-b765-43847cc52eb6@default>
References: <b8077c49-2413-40ed-b765-43847cc52eb6@default>
Message-ID: <56F46408.7060403@oracle.com>

Hi, Ajit.
Is this bug a regression of JDK-7088744 or JDK-8049069, or it works this 
way in jdk6 as well?
I guess the code in jdk6 was something like this:
     public static boolean isLeftMouseButton(MouseEvent anEvent) {
          return ((anEvent.getModifiers() & InputEvent.BUTTON1_MASK) != 0);
     }

On 24.03.16 12:55, Ajit Ghaisas wrote:
> Hi,
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8049069
>
> Issue :  A JButton which is pressed using left mouse button gets released if right mouse button is pressed and released.
>
> Root cause :
> ---------------
> In file BasicButtonListener.java, mousePressed() and mouseReleased() methods check whether the event is from left mouse button.
> This check is done using ----  if (SwingUtilities.isLeftMouseButton(e) )
> This method returns true if left mouse button is down OR event is from left mouse button.
> SwingUtilities.isLeftMouseButton() returns true if it is called for right mouse event while holding left button down. This causes mouseReleased() method to release pressed JButton.
>
>
> Alternatives considered :
> -----------------------------
> 1. Modifying SwingUtilities.isLeftMouseButton() method to only test for whether the event is from left mouse button only
> 2. Modifying mousePressed() and mouseReleased() methods to check for whether the event is from left mouse button using argument passed to them.
>
> Option 1 will break the code wherever SwingUtilities.isLeftMouseButton() is used to test for left mouse button down.
> File history revealed that the mouse button down condition is added to fix another bug.
>
> Hence, option 2 is chosen as it is safe and intuitive.
> I have also added a test. It passes on Windows, Linux and Mac.
> Test mentioned in comment on the bug also passed.
>
> Please review the webrev :
>
> http://cr.openjdk.java.net/~aghaisas/8049069/webrev.00/
>
> Regards,
> Ajit
>


-- 
Best regards, Sergey.


From avik.niyogi at oracle.com  Mon Mar 28 08:15:55 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 28 Mar 2016 13:45:55 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <b4d57a58-6840-408d-8b88-1664df190602@default>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
	<A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
	<56F26982.9070608@oracle.com>
	<29DECA40-D3D8-4673-92F6-6E0B594F318A@oracle.com>
	<56F2737B.6050108@oracle.com>
	<604613F1-6641-40C3-A1A3-47C937133845@oracle.com>
	<9366cb90-bf09-4ad2-a885-490eb3bfcb72@default>
	<467204A6-7721-4CBE-978C-B79D3C442699@oracle.com>
	<b4d57a58-6840-408d-8b88-1664df190602@default>
Message-ID: <22BB01C7-7CC1-4DFD-8B0D-20CB92D24C52@oracle.com>

A gentle reminder, Please review the code changes as presented below.

With Regards,
Avik Niyogi
> On 24-Mar-2016, at 3:01 pm, Rajeev Chamyal <rajeev.chamyal at oracle.com> wrote:
> 
> Looks good to me.
>  
> Regards,
> Rajeev Chamyal
>  
> From: Avik Niyogi 
> Sent: 24 March 2016 12:54
> To: Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs
>  
> Hi All,
> Please review code changes as per inputs received. 
>  
> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03 <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03>
>  
> As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation within the derived AquaTruncatedTabbedPaneLayout, extending of TabbedPaneScrollLayout is not needed and management of row and column height is done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight need not manage the number of columns and rows respectively and will remain 1 as tabs can be brought forth to the UI by the arrow buttons AQUA provides instead of placing them in another row or column. This is also the expected behaviour for AquaLAF as per javadoc.
>  
> With Regards,
> Avik Niyogi
>  
> On 24-Mar-2016, at 12:34 pm, Rajeev Chamyal <rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com>> wrote:
>  
> Hello Avik,
>  
> x variable on line 2195 is not used anywhere. Do we need for loop also?
>  
> Regards,
> Rajeev Chamyal
>  
> From: Avik Niyogi 
> Sent: 24 March 2016 12:19
> To: Alexander Scherbatiy
> Cc: Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs
>  
> Hi All,
>  
> Please review my code changes below as per the inputs received.
>  
> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/>
>  
> As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation within the derived AquaTruncatedTabbedPaneLayout, extending of TabbedPaneScrollLayout is not needed and management of row and column height is done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight need not manage the number of columns and rows respectively and will remain 1 as tabs can be brought forth to the UI by the arrow buttons AQUA provides instead of placing them in another row or column. This is also the expected behaviour for AquaLAF as per javadoc.
>  
> With Regards,
> Avik Niyogi
>  
>  
> On 23-Mar-2016, at 4:14 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> On 23/03/16 14:07, Avik Niyogi wrote:
> 
> 
>  
> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> On 21/03/16 09:19, Avik Niyogi wrote:
> 
> 
> Hi Alexander, 
> I agree with what you said regarding the look and feel looking different. But this bug arrises due to setting of TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua look and feel should not the setting of this parameter instead throw a helpful error saying this parameter is not accepted
>   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) javadoc:  
>   "Some look and feels might only support a subset of the possible layout policies, in which case the value of this property may be ignored."
>   
>   Aqua L&F ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.
>  
> Actually, it is doing the other way around for Aqua L&F. It is defaulting WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of TabbedPaneLayout and not TabbedPaneScrollLayout.
>    According to the JTabbedPane javadoc:
>   SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset of available tabs when all the tabs will not fit within a single run.
>   WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in multiple runs when all tabs will not fit within a single run.
>  
>    The Aqua L&F uses only AquaTabbedPaneUI and AquaTabbedPaneContrastUI for tabbed pane UI and they both returns AquaTruncatingTabbedPaneLayout which has been designed for to place tabs according to the SCROLL_TAB_LAYOUT.
> 
>   Thanks,
>   Alexandr.
> 
> 
> 
> 
> 
>   Thanks,
>   Alexandr.
> 
> 
> 
> instead of absorbing this parameter and letting it render itself into a dummy node which does not proceed further with this parameter? Maybe we need to discuss what the expected behaviour may be. Also, thank you for the inputs regarding how to proceed with removing duplicate code.
>  
> With Regards,
> Avik Niyogi
> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> 
> I would think about something like:
> -------------
>     public class TabbedPaneLayout implements LayoutManager {
> 
>         protected int basePreferredTabAreaWidth(final int tabPlacement, final int height) {
>             // TabbedPaneLayout preferredTabAreaWidth implementation
>         }
> 
>         protected int truncatingPreferredTabAreaWidth(final int tabPlacement, final int height) {
>             if (tabPlacement == SwingConstants.LEFT || tabPlacement == SwingConstants.RIGHT) {
>                 return basePreferredTabAreaWidth(tabPlacement, height);
>             }
> 
>             return basePreferredTabAreaWidth(tabPlacement, height);
>         }
> 
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return basePreferredTabAreaWidth(tabPlacement, height);
>         }
> 
>     }
> 
>     class TabbedPaneScrollLayout extends TabbedPaneLayout {
>         @Override
>         protected int basePreferredTabAreaWidth(int tabPlacement, int height) {
>             // TabbedPaneScrollLayout preferredTabAreaWidth implementation
>         }
>     }
> 
>     protected class AquaTruncatingTabbedPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
> 
>         @Override
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>         }
>     }
> 
>     protected class AquaTruncatingTabbedScrollPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
> 
>         @Override
>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>         }
>     }
> -------------
> 
> I just have one more question. The TabbedPaneScrollLayout is only created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
> 
> Are there any real cases when the TabbedPaneScrollLayout is created?
> 
> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not look similar to Aqua L&F:
>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png <http://cr.openjdk.java.net/%7Ealexsch/8137169/aqua-scrolled-tabbed-pane.png>
> 
> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs navigation.
> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
> 
> Thanks,
> Alexandr.
> 
> On 18/03/16 14:21, Avik Niyogi wrote:
> Hi Alexander, 
> Thank you for the inputs. I agree with you and did feel the need for removing duplicate code as well. But as per an earlier review input, changes to the super call lay outing is not accepted. This was the only other feasible solution. Created redundant code in this process, but would be maintaining with requirements with code impact to superclasses.
> Please provide any insight to a probable compensate to mitigate this dichotomy of code expectation. Thank you in advance.
>  
> With Regards,
> Avik Niyogi
> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> 
> It is not usually a good idea to have a duplicated code which should be updated every time in several places.
> 
> Is it possible to move the  methods used both in AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with different names and then reused?
> 
> Thanks,
> Alexandr.
> 
> On 17/03/16 17:17, Avik Niyogi wrote:
> Hi Alexander, 
> The issue only applies for ScrollingTabbedPane and hence this fix.
>  
> With Regards,
> Avik Niyogi
>  
> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>  
> 
> Does the same issue affects the AquaTabbedPaneContrastUI?
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 09:04, Avik Niyogi wrote:
> Hi All, 
> A gentle reminder, please review code changes.
>  
> With Regards,
> Avik Niyogi
> On 08-Mar-2016, at 9:51 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>  
> Hi All, 
>  
> Please review code changes done as with inputs provided.
> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/>
>  
> Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
> In the new fix as provided, references to base class layout manager is removed in current solution.
>  
> With Regards,
> Avik Niyogi
>  
> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin <alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>  
> Hello Avik
> 
> Let me make it clear I don't approve the proposed fix
> and ask you to do additional evaluation.
> 
> Every LookAndFeel is different and it doesn't make much sense
> to compare Metal LaF with AquaLaf.
> 
> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
> 
> The bug you are fixing has the following subject 
> "Incorrect minimal heigh of JTabbedPane with more tabs"
> 
> Could you please fix exactly the problem with the minimal heights,
> without changing the UI delegate class.
> 
> Thanks
> alexp
>  
> Gentle reminder. Please review this fix. 
>  
> On 26-Feb-2016, at 10:39 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>  
> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code 
>  and notTabbedPaneLayout() as which is the default.
>  
> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>  
> Fixing the minimum size in AquaTabbedPaneUIwill fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>  
> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>  
> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>  
> With Regards,
> Avik Niyogi
>  
> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin <alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>  
> Hello Avik
> 
> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
> I don't think setting the layout manager from the base class is the right solution here.
> 
> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
> 
> Thanks
> alexp
> 
> On 2/24/2016 12:07, Avik Niyogi wrote:
> Hi All,
>  
> Kindly review the bug fix for JDK 9.
>  
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>  
> Webrev:
>  
> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>
>  
> Issue:
> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>  
> Cause:
> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>  
> Fix:
> Major linking calls to super class fix done within createLayoutManager().
>  
> With Regards,
> Avik Niyogi
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160328/55ceda00/attachment.html>

From ajit.ghaisas at oracle.com  Mon Mar 28 11:43:16 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Mon, 28 Mar 2016 04:43:16 -0700 (PDT)
Subject: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on
 button release
In-Reply-To: <56F46408.7060403@oracle.com>
References: <b8077c49-2413-40ed-b765-43847cc52eb6@default>
	<56F46408.7060403@oracle.com>
Message-ID: <529629fc-b68d-4a5b-8882-1bb2b7bc409e@default>

Hi,
       
    In JDK-6u115, this bug is not reproducible.
    Fix for JDK-7088744 did  not break the JButton behavior.
    This bug is regression due to changes done to SwingUtilities as a fix of JDK-7146377.  

    After reading comments on JBS for JDK-7146377, I realized that the modification was done to support left mouse drag.
    Ideally, it should have been done using a new public method such as isLeftMouseButtonDown() and using it in test/client code. 
    In this case, we will need to add isMiddleMouseButtonDown() and isRightMouseButtonDown() methods as well. 
    Modifying existing APIs as well as introducing new public APIs raises a risk of forced test/client code modifications. (This is the reason why I have chosen option 2 as mentioned below)

    I have fixed the JDK-8049069 in BasicButtonListener.java as there is no need to use swingUtilities methods in mousePressed() and mouseReleased() methods.

Regards,
Ajit

-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, March 25, 2016 3:33 AM
To: Ajit Ghaisas; swing-dev at openjdk.java.net; Alexander Scherbatiy; Rajeev Chamyal
Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on button release

Hi, Ajit.
Is this bug a regression of JDK-7088744 or JDK-8049069, or it works this way in jdk6 as well?
I guess the code in jdk6 was something like this:
     public static boolean isLeftMouseButton(MouseEvent anEvent) {
          return ((anEvent.getModifiers() & InputEvent.BUTTON1_MASK) != 0);
     }

On 24.03.16 12:55, Ajit Ghaisas wrote:
> Hi,
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8049069
>
> Issue :  A JButton which is pressed using left mouse button gets released if right mouse button is pressed and released.
>
> Root cause :
> ---------------
> In file BasicButtonListener.java, mousePressed() and mouseReleased() methods check whether the event is from left mouse button.
> This check is done using ----  if (SwingUtilities.isLeftMouseButton(e) 
> ) This method returns true if left mouse button is down OR event is from left mouse button.
> SwingUtilities.isLeftMouseButton() returns true if it is called for right mouse event while holding left button down. This causes mouseReleased() method to release pressed JButton.
>
>
> Alternatives considered :
> -----------------------------
> 1. Modifying SwingUtilities.isLeftMouseButton() method to only test 
> for whether the event is from left mouse button only 2. Modifying mousePressed() and mouseReleased() methods to check for whether the event is from left mouse button using argument passed to them.
>
> Option 1 will break the code wherever SwingUtilities.isLeftMouseButton() is used to test for left mouse button down.
> File history revealed that the mouse button down condition is added to fix another bug.
>
> Hence, option 2 is chosen as it is safe and intuitive.
> I have also added a test. It passes on Windows, Linux and Mac.
> Test mentioned in comment on the bug also passed.
>
> Please review the webrev :
>
> http://cr.openjdk.java.net/~aghaisas/8049069/webrev.00/
>
> Regards,
> Ajit
>


--
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Mar 29 06:52:59 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 29 Mar 2016 10:52:59 +0400
Subject: <Swing Dev> RFR JDK-8143021: [TEST_BUG] Test
 javax/swing/JColorChooser/Test6541987.java fails for Ubuntu 15.10
In-Reply-To: <b5953f3f-8443-402a-8cd2-8d9c16b12aa1@default>
References: <b5953f3f-8443-402a-8cd2-8d9c16b12aa1@default>
Message-ID: <56FA264B.8010200@oracle.com>

On 22/03/16 10:13, Ahmad Ahmad wrote:
>
> Hello,
>
> Please review fix for JDK9 test bug.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143021
>
> Webrev: http://cr.openjdk.java.net/~srastogi/shaik/webrev.01/ 
> <http://cr.openjdk.java.net/%7Esrastogi/shaik/webrev.01/>
>
  115         if (c instanceof JTabbedPane) {
  116             JTabbedPane dummy = (JTabbedPane) c;
  117             dummy.removeTabAt(0);
  118         }

It is better to find the HSV tab and set it selected rather to remove 
the first tab in this case.
The spinner search is also better to do on EDT.
>
> Issue:
>
> java.lang.Error: found visible window: frame0
>
> at Test6541987.main(Test6541987.java:64)
>
> Cause:
>
> Test is failing in Ubuntu OS as intermittently due to frame is visible 
> but ideally all windows should be closed, introduced delay to solve 
> the issue.
>
> Fix:
>
> Beside reported issue in the bug, When I tested on Mac OS, Test never 
> passed due to ALT + H + 4 TABs still keep the focus in the slider and 
> not on spinner
>
     Alt+H should select HSV tab but there is the known issue that 
mnemonics do not work for tabs in JTabbedPane on Mac OS X:
   8064922 [macosx] Test javax/swing/JTabbedPane/4624207/bug4624207.java 
fails
     https://bugs.openjdk.java.net/browse/JDK-8064922

Thanks,
Alexandr.

> but the actual test is all about ensuring JColorChooser disappears 
> when pressing esc, keeping the focus on the spinner.
>
> Test verified in Mac OS, Windows, OEL and Ubuntu.
>
> Thanks & Regards
>
> Shaik Ahmad
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160329/7cece02a/attachment.html>

From avik.niyogi at oracle.com  Tue Mar 29 07:05:31 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 29 Mar 2016 12:35:31 +0530
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
	minimal heigh of JTabbedPane with more tabs
In-Reply-To: <22BB01C7-7CC1-4DFD-8B0D-20CB92D24C52@oracle.com>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
	<A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
	<56F26982.9070608@oracle.com>
	<29DECA40-D3D8-4673-92F6-6E0B594F318A@oracle.com>
	<56F2737B.6050108@oracle.com>
	<604613F1-6641-40C3-A1A3-47C937133845@oracle.com>
	<9366cb90-bf09-4ad2-a885-490eb3bfcb72@default>
	<467204A6-7721-4CBE-978C-B79D3C442699@oracle.com>
	<b4d57a58-6840-408d-8b88-1664df190602@default>
	<22BB01C7-7CC1-4DFD-8B0D-20CB92D24C52@oracle.com>
Message-ID: <5D48D7D1-8B50-4821-9339-30688440C545@oracle.com>

Hi Sergey and Alexander,

Please review the code changes done.

With Regards,
Avik Niyogi
> On 28-Mar-2016, at 1:45 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> A gentle reminder, Please review the code changes as presented below.
> 
> With Regards,
> Avik Niyogi
>> On 24-Mar-2016, at 3:01 pm, Rajeev Chamyal <rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com>> wrote:
>> 
>> Looks good to me.
>>  
>> Regards,
>> Rajeev Chamyal
>>  
>> From: Avik Niyogi 
>> Sent: 24 March 2016 12:54
>> To: Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>> Subject: Re: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs
>>  
>> Hi All,
>> Please review code changes as per inputs received. 
>>  
>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03 <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03>
>>  
>> As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation within the derived AquaTruncatedTabbedPaneLayout, extending of TabbedPaneScrollLayout is not needed and management of row and column height is done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight need not manage the number of columns and rows respectively and will remain 1 as tabs can be brought forth to the UI by the arrow buttons AQUA provides instead of placing them in another row or column. This is also the expected behaviour for AquaLAF as per javadoc.
>>  
>> With Regards,
>> Avik Niyogi
>>  
>> On 24-Mar-2016, at 12:34 pm, Rajeev Chamyal <rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com>> wrote:
>>  
>> Hello Avik,
>>  
>> x variable on line 2195 is not used anywhere. Do we need for loop also?
>>  
>> Regards,
>> Rajeev Chamyal
>>  
>> From: Avik Niyogi 
>> Sent: 24 March 2016 12:19
>> To: Alexander Scherbatiy
>> Cc: Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>> Subject: Re: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs
>>  
>> Hi All,
>>  
>> Please review my code changes below as per the inputs received.
>>  
>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/>
>>  
>> As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation within the derived AquaTruncatedTabbedPaneLayout, extending of TabbedPaneScrollLayout is not needed and management of row and column height is done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight need not manage the number of columns and rows respectively and will remain 1 as tabs can be brought forth to the UI by the arrow buttons AQUA provides instead of placing them in another row or column. This is also the expected behaviour for AquaLAF as per javadoc.
>>  
>> With Regards,
>> Avik Niyogi
>>  
>>  
>> On 23-Mar-2016, at 4:14 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>  
>> On 23/03/16 14:07, Avik Niyogi wrote:
>> 
>> 
>>  
>> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>  
>> On 21/03/16 09:19, Avik Niyogi wrote:
>> 
>> 
>> Hi Alexander, 
>> I agree with what you said regarding the look and feel looking different. But this bug arrises due to setting of TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua look and feel should not the setting of this parameter instead throw a helpful error saying this parameter is not accepted
>>   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) javadoc:  
>>   "Some look and feels might only support a subset of the possible layout policies, in which case the value of this property may be ignored."
>>   
>>   Aqua L&F ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.
>>  
>> Actually, it is doing the other way around for Aqua L&F. It is defaulting WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of TabbedPaneLayout and not TabbedPaneScrollLayout.
>>    According to the JTabbedPane javadoc:
>>   SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset of available tabs when all the tabs will not fit within a single run.
>>   WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in multiple runs when all tabs will not fit within a single run.
>>  
>>    The Aqua L&F uses only AquaTabbedPaneUI and AquaTabbedPaneContrastUI for tabbed pane UI and they both returns AquaTruncatingTabbedPaneLayout which has been designed for to place tabs according to the SCROLL_TAB_LAYOUT.
>> 
>>   Thanks,
>>   Alexandr.
>> 
>> 
>> 
>> 
>> 
>>   Thanks,
>>   Alexandr.
>> 
>> 
>> 
>> instead of absorbing this parameter and letting it render itself into a dummy node which does not proceed further with this parameter? Maybe we need to discuss what the expected behaviour may be. Also, thank you for the inputs regarding how to proceed with removing duplicate code.
>>  
>> With Regards,
>> Avik Niyogi
>> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>  
>> 
>> I would think about something like:
>> -------------
>>     public class TabbedPaneLayout implements LayoutManager {
>> 
>>         protected int basePreferredTabAreaWidth(final int tabPlacement, final int height) {
>>             // TabbedPaneLayout preferredTabAreaWidth implementation
>>         }
>> 
>>         protected int truncatingPreferredTabAreaWidth(final int tabPlacement, final int height) {
>>             if (tabPlacement == SwingConstants.LEFT || tabPlacement == SwingConstants.RIGHT) {
>>                 return basePreferredTabAreaWidth(tabPlacement, height);
>>             }
>> 
>>             return basePreferredTabAreaWidth(tabPlacement, height);
>>         }
>> 
>>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>>             return basePreferredTabAreaWidth(tabPlacement, height);
>>         }
>> 
>>     }
>> 
>>     class TabbedPaneScrollLayout extends TabbedPaneLayout {
>>         @Override
>>         protected int basePreferredTabAreaWidth(int tabPlacement, int height) {
>>             // TabbedPaneScrollLayout preferredTabAreaWidth implementation
>>         }
>>     }
>> 
>>     protected class AquaTruncatingTabbedPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
>> 
>>         @Override
>>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>         }
>>     }
>> 
>>     protected class AquaTruncatingTabbedScrollPaneLayout extends AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
>> 
>>         @Override
>>         protected int preferredTabAreaWidth(final int tabPlacement, final int height) {
>>             return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>         }
>>     }
>> -------------
>> 
>> I just have one more question. The TabbedPaneScrollLayout is only created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
>> 
>> Are there any real cases when the TabbedPaneScrollLayout is created?
>> 
>> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the AquaTabbedPaneUI the JTabbedPane L&F with SCROLL_TAB_LAYOUT does not look similar to Aqua L&F:
>>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png <http://cr.openjdk.java.net/%7Ealexsch/8137169/aqua-scrolled-tabbed-pane.png>
>> 
>> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs navigation.
>> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
>> 
>> Thanks,
>> Alexandr.
>> 
>> On 18/03/16 14:21, Avik Niyogi wrote:
>> Hi Alexander, 
>> Thank you for the inputs. I agree with you and did feel the need for removing duplicate code as well. But as per an earlier review input, changes to the super call lay outing is not accepted. This was the only other feasible solution. Created redundant code in this process, but would be maintaining with requirements with code impact to superclasses.
>> Please provide any insight to a probable compensate to mitigate this dichotomy of code expectation. Thank you in advance.
>>  
>> With Regards,
>> Avik Niyogi
>> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>  
>> 
>> It is not usually a good idea to have a duplicated code which should be updated every time in several places.
>> 
>> Is it possible to move the  methods used both in AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with different names and then reused?
>> 
>> Thanks,
>> Alexandr.
>> 
>> On 17/03/16 17:17, Avik Niyogi wrote:
>> Hi Alexander, 
>> The issue only applies for ScrollingTabbedPane and hence this fix.
>>  
>> With Regards,
>> Avik Niyogi
>>  
>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>  
>> 
>> Does the same issue affects the AquaTabbedPaneContrastUI?
>> 
>> Thanks,
>> Alexandr.
>> 
>> On 14/03/16 09:04, Avik Niyogi wrote:
>> Hi All, 
>> A gentle reminder, please review code changes.
>>  
>> With Regards,
>> Avik Niyogi
>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>  
>> Hi All, 
>>  
>> Please review code changes done as with inputs provided.
>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/>
>>  
>> Also, albeit the title of issue mentioned is as above, the injection of issue occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
>> In the new fix as provided, references to base class layout manager is removed in current solution.
>>  
>> With Regards,
>> Avik Niyogi
>>  
>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin <alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>  
>> Hello Avik
>> 
>> Let me make it clear I don't approve the proposed fix
>> and ask you to do additional evaluation.
>> 
>> Every LookAndFeel is different and it doesn't make much sense
>> to compare Metal LaF with AquaLaf.
>> 
>> The AquaLaf mimics the native MacOS controls and therefore look quite different from any other Lafs.
>> 
>> The bug you are fixing has the following subject 
>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>> 
>> Could you please fix exactly the problem with the minimal heights,
>> without changing the UI delegate class.
>> 
>> Thanks
>> alexp
>>  
>> Gentle reminder. Please review this fix. 
>>  
>> On 26-Feb-2016, at 10:39 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>  
>> The issue is with setting of TabbedPaneScrollLayout() for the option JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code 
>>  and notTabbedPaneLayout() as which is the default.
>>  
>> The minimum size fixes itself because the ScrollLayout check fails in setTabLayoutPolicy() for the pane. So the issue is with the call to set layout manager.
>> There are only two configurations that the JTabbedPane can exist in of which SCROLL_TAB_LAYOUT is one of them.
>>  
>> Fixing the minimum size in AquaTabbedPaneUIwill fix it for TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>  
>> Also, I have checked other implementations such as for Metal and Motif and they have similar code for doing this process.
>> Hence, with in-depth analysis, this fix has no other impact apart from this fix.
>>  
>> In case the impact caused by this change has caused some definitive regressions, please mention them so they can be addressed. Thank you.
>>  
>> With Regards,
>> Avik Niyogi
>>  
>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin <alexander.potochkin at oracle.com <mailto:alexander.potochkin at oracle.com>> wrote:
>>  
>> Hello Avik
>> 
>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the AquaTabbedPaneUI.
>> I don't think setting the layout manager from the base class is the right solution here.
>> 
>> If there is a problem with minimum size it should be fixed inside the AquaTabbedPaneUI
>> 
>> Thanks
>> alexp
>> 
>> On 2/24/2016 12:07, Avik Niyogi wrote:
>> Hi All,
>>  
>> Kindly review the bug fix for JDK 9.
>>  
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8137169 <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>  
>> Webrev:
>>  
>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>
>>  
>> Issue:
>> For Aqua Look&Feel, multiple calls to pane.getMinimumSize().height causes incremental return of values.
>>  
>> Cause:
>> The impact was caused by a major broken code within AquaTabbedPaneUI.java for createLayoutManager()
>>  
>> Fix:
>> Major linking calls to super class fix done within createLayoutManager().
>>  
>> With Regards,
>> Avik Niyogi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160329/17f5672e/attachment.html>

From alexandr.scherbatiy at oracle.com  Tue Mar 29 07:42:34 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 29 Mar 2016 11:42:34 +0400
Subject: <Swing Dev> Review request for JDK-8075084
 JOptionPane.showMessageDialog causes JScrollBar to move
In-Reply-To: <fe80f065-ae27-49c5-815f-34708b85e91b@default>
References: <556d6cec-a723-42a4-a96a-dc22b7d2f112@default>
	<565EAB0D.4070406@oracle.com>
	<745c79a4-6692-4b5c-9c81-ae10332c248d@default>
	<566961E8.1020806@oracle.com>
	<0101fe6a-0bfe-44e5-9bd4-4c470160024a@default>
	<56788E7A.4020601@oracle.com>
	<d1a90ca8-a85e-4ab5-9cd1-bc99ded86f81@default>
	<567D6D12.70806@oracle.com>
	<6a9ba228-fbfb-41d8-bb59-01f98f449a0a@default>
	<3396fa45-2f9d-4c1b-8d4c-dc30e1ce751e@default>
	<569678A3.6090500@oracle.com>
	<fe80f065-ae27-49c5-815f-34708b85e91b@default>
Message-ID: <56FA31EA.9070402@oracle.com>

On 22/03/16 15:25, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the re-worked fix.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8075084
> Webrev : http://cr.openjdk.java.net/~rchamyal/8075084/webrev.03/
>
> In the updated fix a global awt event listener has been added to BasicScrollBarUI to take actions on mouse events.
> The awt event listener determines the state of arrow buttons and source of mouse events and based on these it stops the timer.
   - when an AWTListener is added there also should be the code to 
remove it when GC destroys the BasicScrollBarUI object to avoid possible 
memory leaks
   - this change should be checked with the security manager installed 
because adding the awt listener requires special AWT permissions.

   Could you also check a way when a counter for mouse release events is 
added to the Toolkit?
   This counter can be accessed by AWTAccessor.ToolkitAccessor and be 
used just to check that the mouse button was released on a modal dialog.


  Thanks,
  Alexandr.

> Regards,
> Rajeev Chamyal
>
>
>   -----Original Message-----
> From: Alexander Scherbatiy
> Sent: 13 January 2016 21:48
> To: Rajeev Chamyal
> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> Review request for JDK-8075084 JOptionPane.showMessageDialog causes JScrollBar to move
>
> On 1/12/2016 5:28 PM, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Gentle reminder to review the fix.
>> http://cr.openjdk.java.net/~rchamyal/8075084/webrev.02/
>      My impression was that the scroll timer is started before an adjustment listener is executed. In this case the timer can track the open modal dialog and be stopped.
>      It looks like the real situation is opposite and the scroll timer should track the closed modal dialog which is not reliable because it is possible to press and hold  a scroll thumb on another scrollbar and it will detect the closed modal dialog too.
>
>      If I am correct for the first version of the fix the mouse release and exit events can be still missed if a modal dialog is shown outside the scroll bar.
>
>      I do not have a good idea how the mouse exit event can be caught in this case when a modal dialog is shown.
>      May be it possible to add a counter of mouse release events to the toolkit (or read it by AWTEventListener).
>      If number of mouse release events are different before the scroll bar  adjustment listener is executed and after that it means that mouse was released on a modal dialog or missed by some other reason.
>
>     Thanks,
>     Alexandr.
>
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Rajeev Chamyal
>> Sent: 27 December 2015 20:32
>> To: Sergey Bylokhov
>> Cc: swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> Review request for JDK-8075084
>> JOptionPane.showMessageDialog causes JScrollBar to move
>>
>> Hello Sergey,
>>
>> The first webrev version is implemented on similar lines as you suggested but it had issues as pointed my Alexandr in his review below.
>> If the mouse pointer after clicking on modal dialog close lies outside the parent window then parent window is not getting any mouse events and BasicScrollBarUI::scrollByUnit method is again getting called recursively, Because of which the scroll bar pointer keeps on moving till the end of scrollbar.
>> With this new implementation these issue are not seen.
>>
>> Regards,
>> Rajeev Chamyal
>>
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: 25 December 2015 21:52
>> To: Rajeev Chamyal; Alexander Scherbatiy
>> Cc: Prasanta Sadhukhan; swing-dev at openjdk.java.net
>> Subject: Re: Review request for JDK-8075084
>> JOptionPane.showMessageDialog causes JScrollBar to move
>>
>> Probably this bug can be fixed in a different way. Is it possible to check the state of the scroll bar in the timer? And if in some iteration the button became unpressed then stops itself(timer).
>>
>> On 23/12/15 12:29, Rajeev Chamyal wrote:
>>> Hello Alexandr,
>>>
>>> The modal dialog can be application modal, document modal and toolkit modal.
>>>         1) Application-modal dialog box blocks all windows from the same application, except windows from its child hierarchy
>>>         2) Document-modal dialog box blocks all windows from the same document, except windows from its child hierarchy.
>>>         3) Toolkit-modal dialog box blocks all windows that run in the
>>> same toolkit, except windows from its child hierarchy
>>>
>>> The current issue is reproducible with all modal dialog types. I have updated the condition in code to check for modal dialogs.
>>>
>>> http://cr.openjdk.java.net/~rchamyal/8075084/webrev.02/
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Alexander Scherbatiy
>>> Sent: 22 December 2015 05:13
>>> To: Rajeev Chamyal
>>> Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>>> Subject: Re: Review request for JDK-8075084
>>> JOptionPane.showMessageDialog causes JScrollBar to move
>>>
>>> On 21/12/15 12:21, Rajeev Chamyal wrote:
>>>> Hello Alexandr,
>>>>
>>>> I have updated the fix. Please review it.
>>>> http://cr.openjdk.java.net/~rchamyal/8075084/webrev.01/
>>>        When a modal dialog is shown does it block all windows or is it possible that a modal dialog blocks some windows and does not block others?
>>>
>>>      Thanks,
>>>      Alexandr.
>>>
>>>> Regards,
>>>> Rajeev Chamyal
>>>>
>>>> -----Original Message-----
>>>> From: Alexander Scherbatiy
>>>> Sent: 10 December 2015 16:59
>>>> To: Rajeev Chamyal
>>>> Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>>>> Subject: Re: Review request for JDK-8075084
>>>> JOptionPane.showMessageDialog causes JScrollBar to move
>>>>
>>>> On 12/3/2015 11:08 AM, Rajeev Chamyal wrote:
>>>>> Hello Alexandr,
>>>>>
>>>>> Thanks for the review.
>>>>>
>>>>> When we open a JOption dialog from AdjustmentListener the scroll
>>>>> bar arrow button is not receiving the mouse release event.
>>>>>
>>>>> As a result the JScrollBar: scrollTimer is not getting stopped and
>>>>> its becoming a recursive call.
>>>>>
>>>>         I tried to run the BuggyDialog sample form the issue description with the suggested fix.
>>>>         I noticed a strange behavior when I press scroll down and click not on the JOptionPane OK button but on the close button.
>>>>         The scroll bar continues scrolling in this case.
>>>>
>>>>         When a modal dialog is open it blocks others windows. Is it possible to check this event and stop the scroll timer in this case?
>>>>
>>>>        Thanks,
>>>>        Alexandr.
>>>>
>>>>> Regards,
>>>>>
>>>>> Rajeev Chamyal
>>>>>
>>>>> *From:*Alexandr Scherbatiy
>>>>> *Sent:* 02 December 2015 13:56
>>>>> *To:* Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan;
>>>>> swing-dev at openjdk.java.net
>>>>> *Subject:* Re: Review request for JDK-8075084
>>>>> JOptionPane.showMessageDialog causes JScrollBar to move
>>>>>
>>>>> On 11/11/2015 7:47 AM, Rajeev Chamyal wrote:
>>>>>
>>>>>         Hello All,
>>>>>
>>>>>         Please review the following fix for Jdk9:
>>>>>
>>>>>
>>>>>
>>>>>         Bug:https://bugs.openjdk.java.net/browse/JDK-8075084
>>>>>
>>>>>         Webrev:http://cr.openjdk.java.net/~rchamyal/8075084/webrev.00/
>>>>>         <http://cr.openjdk.java.net/%7Erchamyal/8075084/webrev.00/>
>>>>>
>>>>>         Issue: On running the sample program attached in bug JDK-8075084
>>>>>         user is expected to see a scrollbar and on clicking the scrollbar
>>>>>         tracker or scrollbar up/down arrow buttons a JOption dialog should
>>>>>         come once. The program works fine if scrollbar tracker is clicked
>>>>>         i.e. JOption dialog comes only once. But on clicking up/down arrow
>>>>>         buttons of scrollbar the JOption dialog keeps on coming repeatedly.
>>>>>
>>>>>         Cause: The mouse pressed event of scrollbar arrow buttons calls BasicScrollBarUI::scrollByUnit method which creates a property change event and calls scroll bar action listener which again calls BasicScrollBarUI::scrollByUnit. This is becoming a recursive call and causing the scrollbar slider to move repeatedly till it reaches the other end of scrollbar.
>>>>>
>>>>>        If I change the AdjustmentListener to not show the
>>>>> JOptionPane it is called only one time.
>>>>>        What is the reason that showing JOptionPane causes that the
>>>>> AdjustmentListener is called one more time?
>>>>>
>>>>>        Thanks,
>>>>>        Alexandr.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>         Fix: Added checks in the BasicScrollBarUI action listener to stop the recursion.
>>>>>
>>>>>
>>>>>
>>>>>         Regards,
>>>>>
>>>>>         Rajeev Chamyal
>>>>>
>> --
>> Best regards, Sergey.



From semyon.sadetsky at oracle.com  Tue Mar 29 07:49:00 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 29 Mar 2016 10:49:00 +0300
Subject: <Swing Dev> <AWT Dev> [9] Review Request for several test bugs:
 8150535, 8151033, 8151037 etc.
In-Reply-To: <56F403C8.7050609@oracle.com>
References: <56F3F70D.3070809@oracle.com> <56F3FAF2.6060009@oracle.com>
	<56F403C8.7050609@oracle.com>
Message-ID: <56FA336C.1000804@oracle.com>

Hi Yuri,

Is it possible to make those tests to run on both Jigsaw and non-Jigsaw 
JDKs?

Some tests may be unstable on Ubuntu because of 
https://bugs.openjdk.java.net/browse/JDK-8036915.

To make stability better I propose to replace all top windows 
getLocation() by getLocationOnScreen() and for rectangles got by 
getBounds() to call setLocation(window.getLocationOnScreen()).

getLocationOnScreen() queries the position from WM directly and is more 
reliable.

--Semyon


On 3/24/2016 6:12 PM, Yuri Nesterenko wrote:
> Sergey, I'm sorry,
> filing JDK-8152693, I found an error in that version.
>
> A new one is
> http://cr.openjdk.java.net/~yan/8150535/webrev.02
> The spawned processes were provided with addExports.
>
> Shame on me!
> -yan
>
>
> On 03/24/2016 05:34 PM, Sergey Bylokhov wrote:
>> cc swing-dev
>>
>> On 24.03.16 17:17, Yuri Nesterenko wrote:
>>> Hi,
>>>
>>> please review this test-only fix, a leftover from Jigsaw M3 
>>> integration.
>>> Some 7 tests fixed but note that not all of them always pass even 
>>> fixed.
>>> Webrev:
>>> http://cr.openjdk.java.net/~yan/8150535/webrev.01
>>>
>>> I need to file a bug about the fixed here manual test
>>> java/awt/xembed/server/TestXEmbedServerJava
>>>
>>> Thank you!
>>>
>>> -yan
>>
>>
>



From yuri.nesterenko at oracle.com  Tue Mar 29 09:47:31 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Tue, 29 Mar 2016 12:47:31 +0300
Subject: <Swing Dev> <AWT Dev> [9] Review Request for several test bugs:
 8150535, 8151033, 8151037 etc.
In-Reply-To: <56FA336C.1000804@oracle.com>
References: <56F3F70D.3070809@oracle.com> <56F3FAF2.6060009@oracle.com>
	<56F403C8.7050609@oracle.com> <56FA336C.1000804@oracle.com>
Message-ID: <56FA4F33.1050405@oracle.com>

Hi Semyon,

(see also my answer in
https://bugs.openjdk.java.net/browse/JDK-8152693 )
Unfortunately, this changeset is already pushed.

Generally, some of the tests is not hard to adapt for non-modules
execution mode, and let's try that sometimes, however
(1) some of them already run well with jdk8 (bug8133039.java, 
PointerInfoCrashTest.java);
(2) there's no way back from Jigsaw; with time, that conditional
execution would introduce unnecessary complexity
(WrappedToolkitTest.sh would be two times bigger, why not use
jdk8 version?).
(3) Some of the tests is not easy to make two-way even now:
for instance, every test requiring Xpatch.

Thank you! In future I will have in mind that getLocation()
issue.

-yan

On 03/29/2016 10:49 AM, Semyon Sadetsky wrote:
> Hi Yuri,
>
> Is it possible to make those tests to run on both Jigsaw and non-Jigsaw
> JDKs?
>
> Some tests may be unstable on Ubuntu because of
> https://bugs.openjdk.java.net/browse/JDK-8036915.
>
> To make stability better I propose to replace all top windows
> getLocation() by getLocationOnScreen() and for rectangles got by
> getBounds() to call setLocation(window.getLocationOnScreen()).
>
> getLocationOnScreen() queries the position from WM directly and is more
> reliable.
>
> --Semyon
>
>
> On 3/24/2016 6:12 PM, Yuri Nesterenko wrote:
>> Sergey, I'm sorry,
>> filing JDK-8152693, I found an error in that version.
>>
>> A new one is
>> http://cr.openjdk.java.net/~yan/8150535/webrev.02
>> The spawned processes were provided with addExports.
>>
>> Shame on me!
>> -yan
>>
>>
>> On 03/24/2016 05:34 PM, Sergey Bylokhov wrote:
>>> cc swing-dev
>>>
>>> On 24.03.16 17:17, Yuri Nesterenko wrote:
>>>> Hi,
>>>>
>>>> please review this test-only fix, a leftover from Jigsaw M3
>>>> integration.
>>>> Some 7 tests fixed but note that not all of them always pass even
>>>> fixed.
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~yan/8150535/webrev.01
>>>>
>>>> I need to file a bug about the fixed here manual test
>>>> java/awt/xembed/server/TestXEmbedServerJava
>>>>
>>>> Thank you!
>>>>
>>>> -yan
>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Tue Mar 29 13:25:50 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 29 Mar 2016 17:25:50 +0400
Subject: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on
 button release
In-Reply-To: <529629fc-b68d-4a5b-8882-1bb2b7bc409e@default>
References: <b8077c49-2413-40ed-b765-43847cc52eb6@default>
	<56F46408.7060403@oracle.com>
	<529629fc-b68d-4a5b-8882-1bb2b7bc409e@default>
Message-ID: <56FA825E.8030608@oracle.com>

On 28/03/16 15:43, Ajit Ghaisas wrote:
> Hi,
>         
>      In JDK-6u115, this bug is not reproducible.
>      Fix for JDK-7088744 did  not break the JButton behavior.
>      This bug is regression due to changes done to SwingUtilities as a fix of JDK-7146377.
>
>      After reading comments on JBS for JDK-7146377, I realized that the modification was done to support left mouse drag.
>      Ideally, it should have been done using a new public method such as isLeftMouseButtonDown() and using it in test/client code.
>      In this case, we will need to add isMiddleMouseButtonDown() and isRightMouseButtonDown() methods as well.
>      Modifying existing APIs as well as introducing new public APIs raises a risk of forced test/client code modifications. (This is the reason why I have chosen option 2 as mentioned below)

   The SwingUtilities.isLeftMouseButton() method used not only in 
JButton listener but in other places too.
   Could you check some component like JSpinner with proper L&F that it 
does not have the same issue described in 8049069.

   It is possible just to add one internal method 
isLeftMouseButtonDown() to the sun.swing.SwingUtilities2 class first.
   Will it be enough to  fix these two issues 8049069 and 7146377?

   Thanks,
   Alexandr.
>
>      I have fixed the JDK-8049069 in BasicButtonListener.java as there is no need to use swingUtilities methods in mousePressed() and mouseReleased() methods.
>
> Regards,
> Ajit
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Friday, March 25, 2016 3:33 AM
> To: Ajit Ghaisas; swing-dev at openjdk.java.net; Alexander Scherbatiy; Rajeev Chamyal
> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on button release
>
> Hi, Ajit.
> Is this bug a regression of JDK-7088744 or JDK-8049069, or it works this way in jdk6 as well?
> I guess the code in jdk6 was something like this:
>       public static boolean isLeftMouseButton(MouseEvent anEvent) {
>            return ((anEvent.getModifiers() & InputEvent.BUTTON1_MASK) != 0);
>       }
>
> On 24.03.16 12:55, Ajit Ghaisas wrote:
>> Hi,
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8049069
>>
>> Issue :  A JButton which is pressed using left mouse button gets released if right mouse button is pressed and released.
>>
>> Root cause :
>> ---------------
>> In file BasicButtonListener.java, mousePressed() and mouseReleased() methods check whether the event is from left mouse button.
>> This check is done using ----  if (SwingUtilities.isLeftMouseButton(e)
>> ) This method returns true if left mouse button is down OR event is from left mouse button.
>> SwingUtilities.isLeftMouseButton() returns true if it is called for right mouse event while holding left button down. This causes mouseReleased() method to release pressed JButton.
>>
>>
>> Alternatives considered :
>> -----------------------------
>> 1. Modifying SwingUtilities.isLeftMouseButton() method to only test
>> for whether the event is from left mouse button only 2. Modifying mousePressed() and mouseReleased() methods to check for whether the event is from left mouse button using argument passed to them.
>>
>> Option 1 will break the code wherever SwingUtilities.isLeftMouseButton() is used to test for left mouse button down.
>> File history revealed that the mouse button down condition is added to fix another bug.
>>
>> Hence, option 2 is chosen as it is safe and intuitive.
>> I have also added a test. It passes on Windows, Linux and Mac.
>> Test mentioned in comment on the bug also passed.
>>
>> Please review the webrev :
>>
>> http://cr.openjdk.java.net/~aghaisas/8049069/webrev.00/
>>
>> Regards,
>> Ajit
>>
>
> --
> Best regards, Sergey.



From alexandr.scherbatiy at oracle.com  Tue Mar 29 13:53:52 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 29 Mar 2016 17:53:52 +0400
Subject: <Swing Dev> Review Request of 8137169 : [macosx] Incorrect
 minimal heigh of JTabbedPane with more tabs
In-Reply-To: <b4d57a58-6840-408d-8b88-1664df190602@default>
References: <7CBB4FD2-C4A5-4B84-829B-FA681330C016@oracle.com>
	<56CEFE6B.5000401@oracle.com>
	<E3CC41CA-F7FC-430F-A64B-A1A2FFA85165@oracle.com>
	<4ED353CF-E409-4348-9313-AC74CC653D6A@oracle.com>
	<56D6F6B4.808@oracle.com>
	<01520179-6464-44E8-AC4A-95A53F044063@oracle.com>
	<26FBE1E8-5917-43DB-BD8E-9FC6181698B7@oracle.com>
	<56E941A1.1090402@oracle.com>
	<44EA4FCD-0A5B-4718-8C82-2DFE8AD6AB22@oracle.com>
	<56EBC66C.2060605@oracle.com>
	<824DE39E-9174-4461-9B16-E4027DE92B8A@oracle.com>
	<56EC6376.5020106@oracle.com>
	<A1DDAF33-ECE2-4388-B903-A25E0CBAD5AC@oracle.com>
	<56F26982.9070608@oracle.com>
	<29DECA40-D3D8-4673-92F6-6E0B594F318A@oracle.com>
	<56F2737B.6050108@oracle.com>
	<604613F1-6641-40C3-A1A3-47C937133845@oracle.com>
	<9366cb90-bf09-4ad2-a885-490eb3bfcb72@default>
	<467204A6-7721-4CBE-978C-B79D3C442699@oracle.com>
	<b4d57a58-6840-408d-8b88-1664df190602@default>
Message-ID: <56FA88F0.2090300@oracle.com>


The fix looks good to me.

  Thanks,
  Alexandr.

On 24/03/16 13:31, Rajeev Chamyal wrote:
>
> Looks good to me.
>
> Regards,
>
> Rajeev Chamyal
>
> *From:*Avik Niyogi
> *Sent:* 24 March 2016 12:54
> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> Review Request of 8137169 : [macosx] 
> Incorrect minimal heigh of JTabbedPane with more tabs
>
> Hi All,
>
> Please review code changes as per inputs received.
>
> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03 
> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.03>
>
> As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with 
> implementation within the derived AquaTruncatedTabbedPaneLayout, 
> extending of TabbedPaneScrollLayout is not needed and management of 
> row and column height is done within it itself. Hence 
> preferredTabAreaWidth and preferredTabAreaHeight need not manage the 
> number of columns and rows respectively and will remain 1 as tabs can 
> be brought forth to the UI by the arrow buttons AQUA provides instead 
> of placing them in another row or column. This is also the expected 
> behaviour for AquaLAF as per javadoc.
>
> With Regards,
>
> Avik Niyogi
>
>     On 24-Mar-2016, at 12:34 pm, Rajeev Chamyal
>     <rajeev.chamyal at oracle.com <mailto:rajeev.chamyal at oracle.com>> wrote:
>
>     Hello Avik,
>
>     x variable on line 2195 is not used anywhere. Do we need for loop
>     also?
>
>     Regards,
>
>     Rajeev Chamyal
>
>     *From:*Avik Niyogi
>     *Sent:*24 March 2016 12:19
>     *To:*Alexander Scherbatiy
>     *Cc:*Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:*Re: <Swing Dev> Review Request of 8137169 : [macosx]
>     Incorrect minimal heigh of JTabbedPane with more tabs
>
>     Hi All,
>
>     Please review my code changes below as per the inputs received.
>
>     http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/
>     <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.02/>
>
>     As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with
>     implementation within the derived AquaTruncatedTabbedPaneLayout,
>     extending of TabbedPaneScrollLayout is not needed and management
>     of row and column height is done within it itself. Hence
>     preferredTabAreaWidth and preferredTabAreaHeight need not manage
>     the number of columns and rows respectively and will remain 1 as
>     tabs can be brought forth to the UI by the arrow buttons AQUA
>     provides instead of placing them in another row or column. This is
>     also the expected behaviour for AquaLAF as per javadoc.
>
>     With Regards,
>
>     Avik Niyogi
>
>         On 23-Mar-2016, at 4:14 pm, Alexander Scherbatiy
>         <alexandr.scherbatiy at oracle.com
>         <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>
>         On 23/03/16 14:07, Avik Niyogi wrote:
>
>
>                 On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy
>                 <alexandr.scherbatiy at oracle.com
>                 <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>
>                 On 21/03/16 09:19, Avik Niyogi wrote:
>
>
>                     Hi Alexander,
>
>                     I agree with what you said regarding the look and
>                     feel looking different. But this bug arrises due
>                     to setting of TabbedPaneScrollLayout only. If
>                     Scroll Layout is not meant for Aqua look and feel
>                     should not the setting of this parameter instead
>                     throw a helpful error saying this parameter is not
>                     accepted
>
>                   According to the JTabbedPane.setTabLayoutPolicy(int
>                 tabLayoutPolicy) javadoc:
>                   "Some look and feels might only support a subset of
>                 the possible layout policies, in which case the value
>                 of this property may be ignored."
>
>                   Aqua L&F ignores WRAP_TAB_LAYOUT for JTabbedPane
>                 tabs layouting and always use SCROLL_TAB_LAYOUT. No
>                 exception should be thrown in this case.
>
>             Actually, it is doing the other way around for Aqua L&F.
>             It is defaulting WRAP_TAB_LAYOUT and setting
>             SCROLL_TAB_LAYOUT is still setting a subclass of
>             TabbedPaneLayout and not TabbedPaneScrollLayout.
>
>            According to the JTabbedPane javadoc:
>           SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset
>         of available tabs when all the tabs will not fit within a
>         single run.
>           WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in
>         multiple runs when all tabs will not fit within a single run.
>
>            The Aqua L&F uses only AquaTabbedPaneUI and
>         AquaTabbedPaneContrastUI for tabbed pane UI and they both
>         returns AquaTruncatingTabbedPaneLayout which has been designed
>         for to place tabs according to the SCROLL_TAB_LAYOUT.
>
>           Thanks,
>           Alexandr.
>
>
>
>
>
>                   Thanks,
>                   Alexandr.
>
>
>
>                     instead of absorbing this parameter and letting it
>                     render itself into a dummy node which does not
>                     proceed further with this parameter? Maybe we need
>                     to discuss what the expected behaviour may be.
>                     Also, thank you for the inputs regarding how to
>                     proceed with removing duplicate code.
>
>                     With Regards,
>
>                     Avik Niyogi
>
>                         On 19-Mar-2016, at 1:52 am, Alexander
>                         Scherbatiy <alexandr.scherbatiy at oracle.com
>                         <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>
>
>                         I would think about something like:
>                         -------------
>                             public class TabbedPaneLayout implements
>                         LayoutManager {
>
>                                 protected int
>                         basePreferredTabAreaWidth(final int
>                         tabPlacement, final int height) {
>                                     // TabbedPaneLayout
>                         preferredTabAreaWidth implementation
>                                 }
>
>                                 protected int
>                         truncatingPreferredTabAreaWidth(final int
>                         tabPlacement, final int height) {
>                                     if (tabPlacement ==
>                         SwingConstants.LEFT || tabPlacement ==
>                         SwingConstants.RIGHT) {
>                         return basePreferredTabAreaWidth(tabPlacement,
>                         height);
>                                     }
>
>                                     return
>                         basePreferredTabAreaWidth(tabPlacement, height);
>                                 }
>
>                                 protected int
>                         preferredTabAreaWidth(final int tabPlacement,
>                         final int height) {
>                                     return
>                         basePreferredTabAreaWidth(tabPlacement, height);
>                                 }
>
>                             }
>
>                             class TabbedPaneScrollLayout extends
>                         TabbedPaneLayout {
>                                 @Override
>                                 protected int
>                         basePreferredTabAreaWidth(int tabPlacement,
>                         int height) {
>                                     // TabbedPaneScrollLayout
>                         preferredTabAreaWidth implementation
>                                 }
>                             }
>
>                             protected class
>                         AquaTruncatingTabbedPaneLayout extends
>                         AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
>
>                                 @Override
>                                 protected int
>                         preferredTabAreaWidth(final int tabPlacement,
>                         final int height) {
>                                     return
>                         truncatingPreferredTabAreaWidth(tabPlacement,
>                         height);
>                                 }
>                             }
>
>                             protected class
>                         AquaTruncatingTabbedScrollPaneLayout extends
>                         AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout
>                         {
>
>                                 @Override
>                                 protected int
>                         preferredTabAreaWidth(final int tabPlacement,
>                         final int height) {
>                                     return
>                         truncatingPreferredTabAreaWidth(tabPlacement,
>                         height);
>                                 }
>                             }
>                         -------------
>
>                         I just have one more question. The
>                         TabbedPaneScrollLayout is only created in
>                         AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel
>                         only use AquaTabbedPaneUI or
>                         AquaTabbedPaneContrastUI which do not return
>                         TabbedPaneScrollLayout.
>
>                         Are there any real cases when the
>                         TabbedPaneScrollLayout is created?
>
>                         When you enabled the
>                         AquaTruncatingTabbedScrollPaneLayout in the
>                         AquaTabbedPaneUI the JTabbedPane L&F with
>                         SCROLL_TAB_LAYOUT does not look similar to
>                         Aqua L&F:
>                         http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png
>                         <http://cr.openjdk.java.net/%7Ealexsch/8137169/aqua-scrolled-tabbed-pane.png>
>
>                         The AquaTruncatingTabbedPaneLayout already
>                         contains arrows for hidden tabs navigation.
>                         May be the fix should update the
>                         AquaTruncatingTabbedPaneLayout only?
>
>                         Thanks,
>                         Alexandr.
>
>                         On 18/03/16 14:21, Avik Niyogi wrote:
>
>                             Hi Alexander,
>
>                             Thank you for the inputs. I agree with you
>                             and did feel the need for removing
>                             duplicate code as well. But as per an
>                             earlier review input, changes to the super
>                             call lay outing is not accepted. This was
>                             the only other feasible solution. Created
>                             redundant code in this process, but would
>                             be maintaining with requirements with code
>                             impact to superclasses.
>
>                             Please provide any insight to a probable
>                             compensate to mitigate this dichotomy of
>                             code expectation. Thank you in advance.
>
>                             With Regards,
>
>                             Avik Niyogi
>
>                                 On 18-Mar-2016, at 2:42 pm, Alexander
>                                 Scherbatiy
>                                 <alexandr.scherbatiy at oracle.com
>                                 <mailto:alexandr.scherbatiy at oracle.com>>
>                                 wrote:
>
>
>                                 It is not usually a good idea to have
>                                 a duplicated code which should be
>                                 updated every time in several places.
>
>                                 Is it possible to move the methods
>                                 used both in
>                                 AquaTruncatingTabbedPaneLayout and
>                                 AquaTruncatingTabbedScrollPaneLayout
>                                 to TabbedPaneLayout with different
>                                 names and then reused?
>
>                                 Thanks,
>                                 Alexandr.
>
>                                 On 17/03/16 17:17, Avik Niyogi wrote:
>
>                                     Hi Alexander,
>
>                                     The issue only applies for
>                                     ScrollingTabbedPane and hence this
>                                     fix.
>
>                                     With Regards,
>
>                                     Avik Niyogi
>
>                                         On 16-Mar-2016, at 4:51 pm,
>                                         Alexander Scherbatiy
>                                         <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>                                         wrote:
>
>
>                                         Does the same issue affects
>                                         the AquaTabbedPaneContrastUI?
>
>                                         Thanks,
>                                         Alexandr.
>
>                                         On 14/03/16 09:04, Avik Niyogi
>                                         wrote:
>
>                                             Hi All,
>
>                                             A gentle reminder, please
>                                             review code changes.
>
>                                             With Regards,
>
>                                             Avik Niyogi
>
>                                                 On 08-Mar-2016, at
>                                                 9:51 pm, Avik Niyogi
>                                                 <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>
>                                                 wrote:
>
>                                                 Hi All,
>
>                                                 Please review code
>                                                 changes done as with
>                                                 inputs provided.
>
>                                                 http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/
>                                                 <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>
>
>                                                 Also, albeit the title
>                                                 of issue mentioned is
>                                                 as above, the
>                                                 injection of issue
>                                                 occurs because
>                                                 *pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT);*is
>                                                 not honoured.
>
>                                                 In the new fix as
>                                                 provided, references
>                                                 to base class layout
>                                                 manager is removed in
>                                                 current solution.
>
>                                                 With Regards,
>
>                                                 Avik Niyogi
>
>                                                     On 02-Mar-2016, at
>                                                     7:50 pm, Alexander
>                                                     Potochkin
>                                                     <alexander.potochkin at oracle.com
>                                                     <mailto:alexander.potochkin at oracle.com>>
>                                                     wrote:
>
>                                                     Hello Avik
>
>                                                     Let me make it
>                                                     clear I don't
>                                                     approve the
>                                                     proposed fix
>                                                     and ask you to do
>                                                     additional evaluation.
>
>                                                     Every LookAndFeel
>                                                     is different and
>                                                     it doesn't make
>                                                     much sense
>                                                     to compare Metal
>                                                     LaF with AquaLaf.
>
>                                                     The AquaLaf mimics
>                                                     the native MacOS
>                                                     controls and
>                                                     therefore look
>                                                     quite different
>                                                     from any other Lafs.
>
>                                                     The bug you are
>                                                     fixing has the
>                                                     following subject
>                                                     "Incorrect minimal
>                                                     heigh of
>                                                     JTabbedPane with
>                                                     more tabs"
>
>                                                     Could you please
>                                                     fix exactly the
>                                                     problem with the
>                                                     minimal heights,
>                                                     without changing
>                                                     the UI delegate class.
>
>                                                     Thanks
>                                                     alexp
>
>                                                         Gentle
>                                                         reminder.
>                                                         Please review
>                                                         this fix.
>
>                                                             On
>                                                             26-Feb-2016,
>                                                             at 10:39
>                                                             am, Avik
>                                                             Niyogi
>                                                             <avik.niyogi at oracle.com
>                                                             <mailto:avik.niyogi at oracle.com>>
>                                                             wrote:
>
>                                                             The issue
>                                                             is with
>                                                             setting
>                                                             of TabbedPane*Scroll*Layout()
>                                                             for the
>                                                             option JTabbedPane.SCROLL_TAB_LAYOUT
>                                                             as is
>                                                             enabled in
>                                                             the test code
>
>                                                              and*not*TabbedPaneLayout()
>                                                             as which
>                                                             is the
>                                                             default.
>
>                                                             The
>                                                             minimum
>                                                             size fixes
>                                                             itself
>                                                             because
>                                                             the*ScrollLayout*check
>                                                             fails in
>                                                             *setTabLayoutPolicy*()
>                                                             for the
>                                                             pane. So
>                                                             the issue
>                                                             is with
>                                                             the call
>                                                             to set
>                                                             layout
>                                                             manager.
>
>                                                             There are
>                                                             only two
>                                                             configurations
>                                                             that
>                                                             the*JTabbedPane*can
>                                                             exist in
>                                                             of
>                                                             which*SCROLL_TAB_LAYOUT*is
>                                                             one of them.
>
>                                                             Fixing the
>                                                             minimum
>                                                             size
>                                                             in*AquaTabbedPaneUI*will
>                                                             fix it
>                                                             for*TabbedPaneLayout*()
>                                                             only which
>                                                             is
>                                                             the*WRAP_TAB_LAYOUT*.
>
>                                                             Also, I
>                                                             have
>                                                             checked
>                                                             other
>                                                             implementations
>                                                             such as
>                                                             for
>                                                             *Metal*and*Motif*and*they
>                                                             have
>                                                             similar
>                                                             code for
>                                                             doing this
>                                                             process*.
>
>                                                             Hence,
>                                                             with
>                                                             in-depth
>                                                             analysis,
>                                                             this fix
>                                                             has no
>                                                             other
>                                                             impact
>                                                             apart from
>                                                             this fix.
>
>                                                             In case
>                                                             the impact
>                                                             caused by
>                                                             this
>                                                             change has
>                                                             caused
>                                                             some
>                                                             definitive
>                                                             regressions,
>                                                             please
>                                                             mention
>                                                             them so
>                                                             they can
>                                                             be
>                                                             addressed.
>                                                             Thank you.
>
>                                                             With Regards,
>
>                                                             Avik Niyogi
>
>                                                                 On
>                                                                 25-Feb-2016,
>                                                                 at
>                                                                 6:45
>                                                                 pm,
>                                                                 Alexander
>                                                                 Potochkin
>                                                                 <alexander.potochkin at oracle.com
>                                                                 <mailto:alexander.potochkin at oracle.com>>
>                                                                 wrote:
>
>                                                                 Hello Avik
>
>                                                                 AquaTruncatingTabbedPaneLayout
>                                                                 has a
>                                                                 lot of
>                                                                 code
>                                                                 which
>                                                                 is
>                                                                 specific
>                                                                 for
>                                                                 the
>                                                                 AquaTabbedPaneUI.
>                                                                 I
>                                                                 don't
>                                                                 think
>                                                                 setting the
>                                                                 layout
>                                                                 manager from
>                                                                 the
>                                                                 base
>                                                                 class
>                                                                 is the
>                                                                 right
>                                                                 solution
>                                                                 here.
>
>                                                                 If
>                                                                 there
>                                                                 is a
>                                                                 problem with
>                                                                 minimum size
>                                                                 it
>                                                                 should
>                                                                 be
>                                                                 fixed
>                                                                 inside
>                                                                 the
>                                                                 AquaTabbedPaneUI
>
>                                                                 Thanks
>                                                                 alexp
>
>                                                                 On
>                                                                 2/24/2016
>                                                                 12:07,
>                                                                 Avik
>                                                                 Niyogi
>                                                                 wrote:
>
>                                                                     Hi
>                                                                     All,
>
>                                                                     Kindly
>                                                                     review
>                                                                     the bug
>                                                                     fix for
>                                                                     JDK 9.
>
>                                                                     *Bug:*
>
>                                                                     https://bugs.openjdk.java.net/browse/JDK-8137169
>
>                                                                     *Webrev:*
>
>                                                                     http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/
>                                                                     <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>
>
>                                                                     *Issue:*
>
>                                                                     For Aqua
>                                                                     Look&Feel,
>                                                                     multiple
>                                                                     calls
>                                                                     to pane.getMinimumSize().height
>                                                                     causes
>                                                                     incremental
>                                                                     return
>                                                                     of
>                                                                     values.
>
>                                                                     *Cause:*
>
>                                                                     The impact
>                                                                     was caused
>                                                                     by
>                                                                     a
>                                                                     major
>                                                                     broken
>                                                                     code
>                                                                     within
>                                                                     AquaTabbedPaneUI.java
>                                                                     for createLayoutManager()
>
>                                                                     *Fix:*
>
>                                                                     Major
>                                                                     linking
>                                                                     calls
>                                                                     to
>                                                                     super
>                                                                     class
>                                                                     fix done
>                                                                     within
>                                                                     createLayoutManager().
>
>                                                                     With
>                                                                     Regards,
>
>                                                                     Avik
>                                                                     Niyogi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160329/9389b969/attachment.html>

From alexander.potochkin at oracle.com  Tue Mar 29 14:20:35 2016
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Tue, 29 Mar 2016 17:20:35 +0300
Subject: <Swing Dev> CFV: New Swing Group Member: Semyon Sadetsky
In-Reply-To: <56EF8E29.4070605@oracle.com>
References: <56EF8E29.4070605@oracle.com>
Message-ID: <56FA8F33.4000201@oracle.com>


Vote: yes

On 3/21/2016 09:01, Alexander Scherbatiy wrote:
>
> I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to 
> Membership in the Swing Group.
>
> Semyon is active member of Swing group and contributed a lot of fixes 
> which include Swing TimerQueue race condition improvement, UndoManager 
> deadlock resolving, proposing and implementation a public API for 
> internal Swing functionality which is part of Swing modularization 
> support for JDK 9, and others (see Semyon?s list OpenJDK changesets [1])
>
> Semyon proposed a big change for the Swing part of the JEP 283 ?Enable 
> GTK 3 on Linux? [2] implementation [3].
>
> Semyon not only provides fixes for Swing issues but also regularly 
> reviews fixes suggested by other members.
>
> Votes are due by Apr 5, 2016.
>
> Only current Members of the Swing  Group [4] are eligible
> to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [5].
>
> Thanks,
> Alexandr.
>
> [1] 
> http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ssadetsky%22%29
> [2] http://openjdk.java.net/jeps/283
> [3] 
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005440.html
> [4] http://openjdk.java.net/census#swing
> [5] http://openjdk.java.net/groups/#member-vote



From alexandr.scherbatiy at oracle.com  Tue Mar 29 15:16:56 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 29 Mar 2016 19:16:56 +0400
Subject: <Swing Dev> [9] Review request for 8149631: rgb(...) CSS color
 values are not parsed properly
In-Reply-To: <56E6D4FE.80905@oracle.com>
References: <56E6A082.8040405@oracle.com> <56E6BB21.40606@oracle.com>
	<56E6D4FE.80905@oracle.com>
Message-ID: <56FA9C68.7010008@oracle.com>


Should white spaces be removed within parentheses?

Thanks,
Alexandr.

On 14/03/16 19:13, Semyon Sadetsky wrote:
> Thanks, Sergey. The webrev is corrected.
>
> On 3/14/2016 4:22 PM, Sergey Bylokhov wrote:
>> Something strange occurs in the webrev for the testcase, there is no 
>> diff.
>>
>> On 14.03.16 14:29, Semyon Sadetsky wrote:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149631
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8149631/webrev.00/
>>>
>>> The issue is a regression of 4419748 which added support for border
>>> sides but it parse the rgb(...) color values wrong. Also before 4419748
>>> the parenthesis notations worked only for CSS attribute that is not
>>> expected to contain several values. The reason is splitting the
>>> multi-value CSS attribute (for example, "background: rgb(0, 0, 0) url(
>>> 'b.gif' ) no-repeat;") using space divider didn't take into account 
>>> that
>>> spaces within parenthesis should not be used as top-level dividers.
>>> Fixing the value splitting should correct the situation for (...)
>>> entries in all multi-value CSS attributes.
>>>
>>> --Semyon
>>
>>
>



From semyon.sadetsky at oracle.com  Tue Mar 29 15:29:27 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 29 Mar 2016 18:29:27 +0300
Subject: <Swing Dev> [9] Review request for 8149631: rgb(...) CSS color
 values are not parsed properly
In-Reply-To: <56FA9C68.7010008@oracle.com>
References: <56E6A082.8040405@oracle.com> <56E6BB21.40606@oracle.com>
	<56E6D4FE.80905@oracle.com> <56FA9C68.7010008@oracle.com>
Message-ID: <56FA9F57.3060905@oracle.com>

On 3/29/2016 6:16 PM, Alexander Scherbatiy wrote:
>
> Should white spaces be removed within parentheses?
I think it is better to preserve the format user specified.
Spaces are a valid symbols in CSS, they improve readability.

--Semyon
>
> Thanks,
> Alexandr.
>
> On 14/03/16 19:13, Semyon Sadetsky wrote:
>> Thanks, Sergey. The webrev is corrected.
>>
>> On 3/14/2016 4:22 PM, Sergey Bylokhov wrote:
>>> Something strange occurs in the webrev for the testcase, there is no 
>>> diff.
>>>
>>> On 14.03.16 14:29, Semyon Sadetsky wrote:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149631
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8149631/webrev.00/
>>>>
>>>> The issue is a regression of 4419748 which added support for border
>>>> sides but it parse the rgb(...) color values wrong. Also before 
>>>> 4419748
>>>> the parenthesis notations worked only for CSS attribute that is not
>>>> expected to contain several values. The reason is splitting the
>>>> multi-value CSS attribute (for example, "background: rgb(0, 0, 0) url(
>>>> 'b.gif' ) no-repeat;") using space divider didn't take into account 
>>>> that
>>>> spaces within parenthesis should not be used as top-level dividers.
>>>> Fixing the value splitting should correct the situation for (...)
>>>> entries in all multi-value CSS attributes.
>>>>
>>>> --Semyon
>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Tue Mar 29 15:52:54 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Tue, 29 Mar 2016 08:52:54 -0700
Subject: <Swing Dev> [9] Review request for 8149631: rgb(...) CSS color
 values are not parsed properly
In-Reply-To: <56FA9F57.3060905@oracle.com>
References: <56E6A082.8040405@oracle.com> <56E6BB21.40606@oracle.com>
	<56E6D4FE.80905@oracle.com> <56FA9C68.7010008@oracle.com>
	<56FA9F57.3060905@oracle.com>
Message-ID: <56FAA4D6.4030609@oracle.com>


  The fix looks good to me.

  Thanks,
  Alexandr.

On 3/29/2016 8:29 AM, Semyon Sadetsky wrote:
> On 3/29/2016 6:16 PM, Alexander Scherbatiy wrote:
>>
>> Should white spaces be removed within parentheses?
> I think it is better to preserve the format user specified.
> Spaces are a valid symbols in CSS, they improve readability.
>
> --Semyon
>>
>> Thanks,
>> Alexandr.
>>
>> On 14/03/16 19:13, Semyon Sadetsky wrote:
>>> Thanks, Sergey. The webrev is corrected.
>>>
>>> On 3/14/2016 4:22 PM, Sergey Bylokhov wrote:
>>>> Something strange occurs in the webrev for the testcase, there is 
>>>> no diff.
>>>>
>>>> On 14.03.16 14:29, Semyon Sadetsky wrote:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149631
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8149631/webrev.00/
>>>>>
>>>>> The issue is a regression of 4419748 which added support for border
>>>>> sides but it parse the rgb(...) color values wrong. Also before 
>>>>> 4419748
>>>>> the parenthesis notations worked only for CSS attribute that is not
>>>>> expected to contain several values. The reason is splitting the
>>>>> multi-value CSS attribute (for example, "background: rgb(0, 0, 0) 
>>>>> url(
>>>>> 'b.gif' ) no-repeat;") using space divider didn't take into 
>>>>> account that
>>>>> spaces within parenthesis should not be used as top-level dividers.
>>>>> Fixing the value splitting should correct the situation for (...)
>>>>> entries in all multi-value CSS attributes.
>>>>>
>>>>> --Semyon
>>>>
>>>>
>>>
>>
>



From philip.race at oracle.com  Tue Mar 29 19:15:46 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 29 Mar 2016 12:15:46 -0700
Subject: <Swing Dev> [9] Review request for 8146301: Enter key does not
 work in a deserialized JFileChooser
In-Reply-To: <56F037FB.802@oracle.com>
References: <56EAC145.6050209@oracle.com> <56EAD36E.8090108@oracle.com>
	<56F0255C.4090800@oracle.com> <56F02ABD.3020604@oracle.com>
	<56F037FB.802@oracle.com>
Message-ID: <56FAD462.1060102@oracle.com>

The fix looks fine to me and I agree the OS X problem is a distinct one.

-phil.

On 03/21/2016 11:05 AM, Semyon Sadetsky wrote:
> On 3/21/2016 8:09 PM, Sergey Bylokhov wrote:
>> On 21.03.16 19:46, Semyon Sadetsky wrote:
>>> yes. This a generic code issue.
>>
>> It is failed on OSX even after the fix, please double check.
> This problem is unrelated to the current issue. I have filed a 
> separate bug: https://bugs.openjdk.java.net/browse/JDK-8152332.
>>
>>>
>>> On 3/17/2016 6:55 PM, Sergey Bylokhov wrote:
>>>> Does the test is passed on all platforms?
>>>>
>>>> On 17.03.16 17:37, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146301
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8146301/webrev.00/
>>>>>
>>>>> This is a regression of JDK-8021253 in which explicit setting the
>>>>> default button was moved to the hierarchy listener but this listener
>>>>> disappears after serialization/deserialization cycle because it is 
>>>>> not
>>>>> serializable. The solution is to make it serializable.
>>>>>
>>>>> --Semyon
>>>>
>>>>
>>>
>>
>>
>



From philip.race at oracle.com  Tue Mar 29 19:24:31 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 29 Mar 2016 12:24:31 -0700
Subject: <Swing Dev> [9] Review request for 8151015: JTextArea.insert()
 does not behave as expected with invalid position
In-Reply-To: <56F0099E.7050705@oracle.com>
References: <56E6EB5C.7000305@oracle.com> <56E9A0A5.8070102@oracle.com>
	<56F0099E.7050705@oracle.com>
Message-ID: <56FAD66F.6010108@oracle.com>

There is actually a test for the previous bug - called bug4496801.java, 
but it is in closed.

I suggest it be opened as part of this fix.

Also run any (all) related Swing regression tests that might cover this 
area.

I am a little nervous that since the original fix was 13 years ago that some
code out there may rely on the 'incorrect' fix by now ..

-phil.


On 03/21/2016 07:47 AM, Sergey Bylokhov wrote:
> Should the test also cover the html based string(and cover the changes 
> in HTMLDocument)?
>
> On 16.03.16 21:06, Alexander Scherbatiy wrote:
>>
>> The fix looks good to me.
>>
>> Just a small comment: if it is a new test it probably should not contain
>> 1998 year in the copyright.
>>
>> Thanks,
>> Alexandr.
>>
>> On 14/03/16 20:48, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151015
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8151015/webrev.00/
>>>
>>> It is regression of 4496801. The fix for 4496801 was wrong and the
>>> correct fix should be taking into account the implied character at the
>>> end of the document. Reverting 4496801 fixes 8151015. Also the correct
>>> fix for 4496801 is provided.
>>>
>>> --Semyon
>>
>
>



From prem.balakrishnan at oracle.com  Wed Mar 30 12:02:15 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Wed, 30 Mar 2016 05:02:15 -0700 (PDT)
Subject: <Swing Dev> Review Request JDK-6897701 : In Nimbus Disabled Menus
 and Menu Items don't look disabled
Message-ID: <dd6748bf-e63c-441c-9a8a-9301920cf85e@default>

Hi,

Please review fix for JDK9,

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

Webrev: http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.00/

  

Issue:

In Nimbus Disabled Menus and Menu Items don't look disabled

 

Cause:

For JMenu and JMenuItem, Developer specified TEXT_FOREGROUND color was set even when they were Disabled.

(Instead of setting Color for the State)

 

Fix:

When JMenu and JMenuItem is disabled, Color for the State is used.

 

Test: Manual Test(since visual validation is required)

 

Regards,
Prem

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160330/10acbd0d/attachment.html>

From prem.balakrishnan at oracle.com  Wed Mar 30 12:08:24 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Wed, 30 Mar 2016 05:08:24 -0700 (PDT)
Subject: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of
 6439354) Manual Test always passes
Message-ID: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>

Hi,

Please review fix for JDK9,

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

Webrev: http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.00/

 

  

Issue:

8152647(duplicate of 6439354) Manual Test always passes

 

Fix:

Enhanced Test(with Pass, Fail and Timeout)

 

Regards,
Prem

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160330/aa270719/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed Mar 30 16:45:42 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 30 Mar 2016 20:45:42 +0400
Subject: <Swing Dev> Review Request JDK-6897701 : In Nimbus Disabled
 Menus and Menu Items don't look disabled
In-Reply-To: <dd6748bf-e63c-441c-9a8a-9301920cf85e@default>
References: <dd6748bf-e63c-441c-9a8a-9301920cf85e@default>
Message-ID: <56FC02B6.3090807@oracle.com>

On 30/03/16 16:02, Prem Balakrishnan wrote:
>
> Hi*,*
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-6897701
>
> *Webrev:*http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/6897701/webrev.00/>
>
> *Issue:*
>
> In Nimbus Disabled Menus and Menu Items don't look disabled
>
> *Cause:*
>
> For JMenu and JMenuItem, Developer specified TEXT_FOREGROUND color was 
> set even when they were Disabled.
>
> (Instead of setting Color for the State)
>
> *Fix:*
>
> When JMenu and JMenuItem is disabled, Color for the State is used.
>
> *Test: *Manual Test(since visual validation is required)
>

   - if it is a new test the 1999 year should be removed
   - it is better to use public 
javax.swing.plaf.nimbus.NimbusLookAndFeel in the test instead of 
internal com.sun.java.swing.plaf.nimbus
   - is it possible to draw the menu and menu item to a buffered image 
and check its color to make the test automated?

   Thanks,
   Alexandr.
>
> **
>
> Regards,
> Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160330/f6f31fe5/attachment.html>

From semyon.sadetsky at oracle.com  Wed Mar 30 17:00:22 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 30 Mar 2016 20:00:22 +0300
Subject: <Swing Dev> Review Request JDK-6897701 : In Nimbus Disabled
 Menus and Menu Items don't look disabled
In-Reply-To: <dd6748bf-e63c-441c-9a8a-9301920cf85e@default>
References: <dd6748bf-e63c-441c-9a8a-9301920cf85e@default>
Message-ID: <56FC0626.1060801@oracle.com>

Hi Prem,

In the block above the line you've changed:

  764         if ((context.getComponentState() & 
SynthConstants.DISABLED) != 0) {
  765             //This component is disabled, so return the disabled 
color.
  766             //In some cases this means ignoring the color 
specified by the
  767             //developer on the component. In other cases it means 
using a
  768             //specified disabledTextColor, such as on JTextComponents.
  769             //For example, JLabel doesn't specify a disabled color 
that the
  770             //developer can set, yet it should have a disabled 
color to the
  771             //text when the label is disabled. This code allows 
for that.

does not it solve the similar problem? Maybe it would be just better to 
add JMenu and JMenuItem case in it?

I'm just not sure that the condition (state == SynthConstants.ENABLED) 
will work if the menu item is a radio or a checkbox because the may have 
SynthConstants.SELECTED flag as well. Will this work for selected radio 
& checkbox?

--Semyon

On 3/30/2016 3:02 PM, Prem Balakrishnan wrote:
>
> Hi*,*
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-6897701
>
> *Webrev:*http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/6897701/webrev.00/>
>
> *Issue:*
>
> In Nimbus Disabled Menus and Menu Items don't look disabled
>
> *Cause:*
>
> For JMenu and JMenuItem, Developer specified TEXT_FOREGROUND color was 
> set even when they were Disabled.
>
> (Instead of setting Color for the State)
>
> *Fix:*
>
> When JMenu and JMenuItem is disabled, Color for the State is used.
>
> *Test: *Manual Test(since visual validation is required)**
>
> Regards,
> Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160330/1a6cec52/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed Mar 30 17:09:48 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 30 Mar 2016 21:09:48 +0400
Subject: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of
 6439354) Manual Test always passes
In-Reply-To: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>
References: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>
Message-ID: <56FC085C.2010206@oracle.com>

On 30/03/16 16:08, Prem Balakrishnan wrote:
>
> Hi*,*
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-8153056
>
> *Webrev:*http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.00/>
>
> *Issue:*
>
> 8152647(duplicate of 6439354) Manual Test always passes
>
> *Fix:*
>
> Enhanced Test(with Pass, Fail and Timeout)
>

    It does not look as issue in the test but rather as jtreg does not 
wait for new created JFrame.
    Could you run the test without the fix with previous version of 
jtreg? Is the JFrame is shown in this case?

   Thanks,
   Alexandr.
>
> Regards,
> Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160330/e391c069/attachment.html>

From alexandr.scherbatiy at oracle.com  Thu Mar 31 06:50:28 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 30 Mar 2016 23:50:28 -0700
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
Message-ID: <56FCC8B4.1040406@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8136366
   webrev: http://cr.openjdk.java.net/~alexsch/8136366/webrev.00

   Some Swing L&Fs are not public. It is not possible to create them 
using reflection now in JDK 9 because of the modularization feature.

   There are use cases when some information should be obtained from a 
L&F without its installation
    - check if L&F is supported
    - take some defaults to use it in custom L&F

   The proposed solution adds UIManager.createLookAndFeel(className) 
method which allows to create a given L&F without installation.

  Thanks,
  Alexandr.



From prem.balakrishnan at oracle.com  Thu Mar 31 10:59:18 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 31 Mar 2016 03:59:18 -0700 (PDT)
Subject: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of
 6439354) Manual Test always passes
In-Reply-To: <56FC085C.2010206@oracle.com>
References: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>
	<56FC085C.2010206@oracle.com>
Message-ID: <092365d9-5be2-487a-be4d-8c169a1820ed@default>

Hi Alexander,

 

Thankyou for the review.

I agree with what you said ,jtreg  does not wait for new created JFrame.

Executed test on : 

Jtreg version: 4.2.0 and 4.1 , facing same issue, even without user/tester validating the output test status shows passed.

 

Hence test enhanced to overcome the above scenario.

 

 

Regards,

Prem

 

From: Alexander Scherbatiy 
Sent: Wednesday, March 30, 2016 10:40 PM
To: Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re: Review Request JDK-8153056 : 8152647(duplicate of 6439354) Manual Test always passes

 

On 30/03/16 16:08, Prem Balakrishnan wrote:



Hi,

Please review fix for JDK9,

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.00/"http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.00/

 

  

Issue:

8152647(duplicate of 6439354) Manual Test always passes

 

Fix:

Enhanced Test(with Pass, Fail and Timeout)


   It does not look as issue in the test but rather as jtreg does not wait for new created JFrame.
   Could you run the test without the fix with previous version of jtreg? Is the JFrame is shown in this case?

  Thanks,
  Alexandr.



 

Regards,
Prem

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160331/d44ee6a2/attachment.html>

From prem.balakrishnan at oracle.com  Thu Mar 31 11:30:55 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 31 Mar 2016 04:30:55 -0700 (PDT)
Subject: <Swing Dev> Review Request JDK-6897701 : In Nimbus Disabled
 Menus and Menu Items don't look disabled
In-Reply-To: <56FC0626.1060801@oracle.com>
References: <dd6748bf-e63c-441c-9a8a-9301920cf85e@default>
	<56FC0626.1060801@oracle.com>
Message-ID: <0e92d730-eae3-492e-840b-d531171a262b@default>

Hi Semyon and Alexander

 

Thankyou for the review.

 

As per review comments,

 

Suggested fix will affect JRadioButton and JCheckBox states. 

Hence modified with the NEW Fix .

Also Test automated. 

Please review the updated patch.

http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.01/

 

Regards,

Prem

 

 

From: Semyon Sadetsky 
Sent: Wednesday, March 30, 2016 10:30 PM
To: Prem Balakrishnan; Sergey Bylokhov; Alexander Scherbatiy; Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re: Review Request JDK-6897701 : In Nimbus Disabled Menus and Menu Items don't look disabled

 

Hi Prem,

In the block above the line you've changed:

 764         if ((context.getComponentState() & SynthConstants.DISABLED) != 0) {
 765             //This component is disabled, so return the disabled color.
 766             //In some cases this means ignoring the color specified by the
 767             //developer on the component. In other cases it means using a
 768             //specified disabledTextColor, such as on JTextComponents.
 769             //For example, JLabel doesn't specify a disabled color that the
 770             //developer can set, yet it should have a disabled color to the
 771             //text when the label is disabled. This code allows for that.

does not it solve the similar problem? Maybe it would be just better to add JMenu and JMenuItem case in it?

I'm just not sure that the condition (state == SynthConstants.ENABLED) will work if the menu item is a radio or a checkbox because the may have SynthConstants.SELECTED flag as well. Will this work for selected radio & checkbox?

--Semyon

On 3/30/2016 3:02 PM, Prem Balakrishnan wrote:

Hi,

Please review fix for JDK9,

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/prem/6897701/webrev.00/"http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.00/

  

Issue:

In Nimbus Disabled Menus and Menu Items don't look disabled

 

Cause:

For JMenu and JMenuItem, Developer specified TEXT_FOREGROUND color was set even when they were Disabled.

(Instead of setting Color for the State)

 

Fix:

When JMenu and JMenuItem is disabled, Color for the State is used.

 

Test: Manual Test(since visual validation is required)

 

Regards,
Prem

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160331/2a6849bf/attachment.html>

From alexandr.scherbatiy at oracle.com  Thu Mar 31 17:15:20 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 31 Mar 2016 21:15:20 +0400
Subject: <Swing Dev> Review Request JDK-6897701 : In Nimbus Disabled
 Menus and Menu Items don't look disabled
In-Reply-To: <0e92d730-eae3-492e-840b-d531171a262b@default>
References: <dd6748bf-e63c-441c-9a8a-9301920cf85e@default>
	<56FC0626.1060801@oracle.com>
	<0e92d730-eae3-492e-840b-d531171a262b@default>
Message-ID: <56FD5B28.2030101@oracle.com>

On 31/03/16 15:30, Prem Balakrishnan wrote:
>
> Hi Semyon and Alexander
>
> Thankyou for the review.
>
> As per review comments,
>
> Suggested fix will affect JRadioButton and JCheckBox states.
>
> Hence modified with the NEW Fix .
>
> Also Test automated.
>
> Please review the updated patch.
>
> http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.01/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/6897701/webrev.01/>
>
  - JMenu extends JMenuItem so the "c instanceof JMenu" is not necessary
  - The caught exception in the test should be re-thrown

  Thanks,
  Alexandr.
>
> Regards,
>
> Prem
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, March 30, 2016 10:30 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; Alexander Scherbatiy; Rajeev 
> Chamyal; swing-dev at openjdk.java.net
> *Subject:* Re: Review Request JDK-6897701 : In Nimbus Disabled Menus 
> and Menu Items don't look disabled
>
> Hi Prem,
>
> In the block above the line you've changed:
>
>  764         if ((context.getComponentState() & 
> SynthConstants.DISABLED) != 0) {
>  765             //This component is disabled, so return the disabled 
> color.
>  766             //In some cases this means ignoring the color 
> specified by the
>  767             //developer on the component. In other cases it means 
> using a
>  768             //specified disabledTextColor, such as on 
> JTextComponents.
>  769             //For example, JLabel doesn't specify a disabled 
> color that the
>  770             //developer can set, yet it should have a disabled 
> color to the
>  771             //text when the label is disabled. This code allows 
> for that.
>
> does not it solve the similar problem? Maybe it would be just better 
> to add JMenu and JMenuItem case in it?
>
> I'm just not sure that the condition (state == SynthConstants.ENABLED) 
> will work if the menu item is a radio or a checkbox because the may 
> have SynthConstants.SELECTED flag as well. Will this work for selected 
> radio & checkbox?
>
> --Semyon
>
> On 3/30/2016 3:02 PM, Prem Balakrishnan wrote:
>
>     Hi*,*
>
>     Please review fix for JDK9,
>
>     *Bug:*https://bugs.openjdk.java.net/browse/JDK-6897701
>
>     *Webrev:*http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.00/ <http://cr.openjdk.java.net/%7Earapte/prem/6897701/webrev.00/>
>
>     *Issue:*
>
>     In Nimbus Disabled Menus and Menu Items don't look disabled
>
>     *Cause:*
>
>     For JMenu and JMenuItem, Developer specified TEXT_FOREGROUND color
>     was set even when they were Disabled.
>
>     (Instead of setting Color for the State)
>
>     *Fix:*
>
>     When JMenu and JMenuItem is disabled, Color for the State is used.
>
>     *Test: *Manual Test(since visual validation is required)
>
>     Regards,
>     Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160331/f4ea0df0/attachment.html>

From alexandr.scherbatiy at oracle.com  Thu Mar 31 18:02:07 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 31 Mar 2016 22:02:07 +0400
Subject: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of
 6439354) Manual Test always passes
In-Reply-To: <092365d9-5be2-487a-be4d-8c169a1820ed@default>
References: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>
	<56FC085C.2010206@oracle.com>
	<092365d9-5be2-487a-be4d-8c169a1820ed@default>
Message-ID: <56FD661F.7030803@oracle.com>

On 31/03/16 14:59, Prem Balakrishnan wrote:
>
> Hi Alexander,
>
> Thankyou for the review.
>
> I agree with what you said ,jtreg  does not wait for new created JFrame.
>
> Executed test on :
>
> Jtreg version: 4.2.0 and 4.1 , facing same issue, even without 
> user/tester validating the output test status shows passed.
>

   It looks like jtreg does not wait for UI closing for manual main tests.
   May be it is better to use CountDownLatch in this case? It least 
there will not be necessary to distinguish InterruptedException 
generated by program of by other reasons.

  Thanks,
  Alexandr.
>
> Hence test enhanced to overcome the above scenario.
>
> Regards,
>
> Prem
>
> *From:*Alexander Scherbatiy
> *Sent:* Wednesday, March 30, 2016 10:40 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev 
> Chamyal; swing-dev at openjdk.java.net
> *Subject:* Re: Review Request JDK-8153056 : 8152647(duplicate of 
> 6439354) Manual Test always passes
>
> On 30/03/16 16:08, Prem Balakrishnan wrote:
>
> Hi*,*
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-8153056
>
> *Webrev:*http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.00/>
>
> *Issue:*
>
> 8152647(duplicate of 6439354) Manual Test always passes
>
> *Fix:*
>
> Enhanced Test(with Pass, Fail and Timeout)
>
>
>    It does not look as issue in the test but rather as jtreg does not 
> wait for new created JFrame.
>    Could you run the test without the fix with previous version of 
> jtreg? Is the JFrame is shown in this case?
>
>   Thanks,
>   Alexandr.
>
> Regards,
> Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160331/4a56ca01/attachment.html>

From alexandr.scherbatiy at oracle.com  Thu Mar 31 18:14:55 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 31 Mar 2016 22:14:55 +0400
Subject: <Swing Dev> [9] Review Request: 8144166 [macosx] Test
 java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java
 fails
In-Reply-To: <56E1DA78.1080000@oracle.com>
References: <56E1DA78.1080000@oracle.com>
Message-ID: <56FD691F.1080604@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 11/03/16 00:35, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk9.
>
> Problem description:
>  - CompEventOnHiddenComponent test was written not according the 
> specification but according an assumption(performance related) - "the 
> component should not post move/resize events if no listeners were 
> registered". The test creates a JInternalFrame and adds 
> ComponentListener to it. No events should come to the listeners, 
> because the frame is not resized or moved by the test(except initial 
> layout). Initial move/resize events are skipped usually, because 
> during initialization there are no any listeners. But this is not the 
> case in Aqua. AquaInternalFrameDockIconUI adds a listeners to the 
> JInternalFrame during initialization -> move/resize events are posted 
> -> the test adds own listeners -> events dispatched -> the test 
> listeners called -> boom.
>
> According above description the bug could be closed as not a defect. 
> But I found another related problem in the AquaInternalFrameDockIconUI.
>
>  - These component listeners in AquaInternalFrameDockIconUI are used 
> to maintain the cache of image for the dock(the icon which is used 
> when the internal frame is minimized). The logic is next:
>    * Before the frame will be minimized it draws to the special 
> ImageIcon which will be used as an icon for the dock.
>    * After the frame is minimized and dock is showing the saved image 
> will be used(and placed to the cache)
>    * If the frame will be resized/show the cache will be reset.
>    * When in the next time the same frame will be minimized the cached 
> image will be used.
>
> The bug is in the last step. When the frame will be minimized in the 
> second time, it can have another content. But minimized icon will show 
> the miniature from the previous minimization. Note this is the only 
> step where the cache is used.
>
> Solution:
> As a solution all cache related stuff were dropped. The new test was 
> added.
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144166
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8144166/webrev.01
>



From philip.race at oracle.com  Thu Mar 31 19:23:10 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 31 Mar 2016 12:23:10 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56F3F83C.3010706@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com>
Message-ID: <56FD791E.1050707@oracle.com>

Another webrev where you have to slip past 40_ files to get to the two 
that really matter :-)
I would have put SwingUtilities2.java and TextUIDrawing.java as the 
first files.


Some of what I have to say here is more along the lines of things to think
about rather than things that are wrong .. but there are also maybe some 
things
that need to be fixed.

Is javax.swing.plaf really the right package for the new class ?
I suppose it is for the use by the UI classes so maybe its right.

Should the methods be taking "double" instead of "int" for location ?
This means the measurement APIs too.
None of the JDK 1.2 text APIs use ints. That is all 1.0 legacy.
So if Swing internally wants to use ints that is OK but maybe the API
should be floating point (double).

Would that  help hi-dpi at all ?
I suppose it would add over-head since all the existing code uses int
and we are no worse off and can add double methods later if we want to.


Regarding FontMetrics we need to add a caution that is must be a FontMetrics
*obtained from the correct font and graphics*.


  i.e what about attributes on the font such as "tracking" ?
or on the graphics such as FRACTIONALMETRICS
It looks like Swing might already fail if that were used.

Look at this code :-

    public static int stringWidth(JComponent c, FontMetrics fm, String 
string){
         if (string == null || string.equals("")) {
             return 0;
         }
         boolean needsTextLayout = ((c != null) &&
(c.getClientProperty(TextAttribute.NUMERIC_SHAPING) != null));
         if (needsTextLayout) {
             synchronized(charsBufferLock) {
                 int length = syncCharsBuffer(string);
                 needsTextLayout = isComplexLayout(charsBuffer, 0, length);
             }
         }
         if (needsTextLayout) {
             TextLayout layout = createTextLayout(c, string,
                                     fm.getFont(), 
fm.getFontRenderContext());
             return (int) layout.getAdvance();
         } else {
             return fm.stringWidth(string);
         }
     }

The only thing Swing is looking at is one TextAttribute and whether we 
have complex text.
That is not enough. This is an existing implementation issue but one we 
should fix here.
You need to examine all the methods for similar issues.

The usage of default methods is worth thinking about.
There is a significant subjective element to this and I've really 
thought only myself about
using them for the case where default methods are useful when you need 
to extend an
existing interface.

But I can imagine they may also be handy when someone would typically 
want to implement
only one or two out of a larger number in an interface and the default 
and you for some
reason don't want to do that with an abstract class (notably you want an 
other class to
be able to implement the interface).

So what do I think about the case where the interface is brand new and
what you've done is more or less implement a concrete class, but it's 
one that
can be mixed in to another class ? Is that an appropriate use ?

Maybe the test to pass in that case is whether the default implementation
is going to be satisfactory for 90% of uses. If they are frequently 
over-ridden
it would not be an appropriate use.

Based on that criterion I think it is OK to use here.

Another thought:
When you add default implementations you should also be on the hook
for explaining what that does. It is a deeper contract than you would
otherwise have as an interface and maybe needs to be an @implNote
or you need to call out the default implementation.
ie there is what someone must code to satisfy the contract of the
interface and what is a behaviour in the default method ?


Also here is a link to some comments by Brian Goetz on default methods :

http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 


   75      * No character is underlined if the index is negative or greater
   76      * than the string length {@code (index < 0 || index >= string.length())}
   77      * or if the char value specified at the given index
   78      * is in the low-surrogate range.


I suppose if you point at the last char and it is a hi-surrogate nothing is underlined in that case either.

But I find the whole writing of this a bit inadequate as if you are going to
this kind of detail you perhaps also need to say what happens in a complex
script where what happens is two unicode characters end up as a ligature,
and/or perhaps you aren't even pointing to a base character.
Maybe it is in fact over-specified. I see that the implementation draws
the underline itself rather than delegate to TextLayout. This might
make sense for performance reasons where it is simple text but some day
this maybe should be re-examined and so I would not over-specify it.

How about :
"The underline will be positioned at the base glyph which
represents the valid char indicated by the index.
If the char index is not valid or is not the index of a
valid unicode code point then no underline is drawn"

-phil.



On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>> Hi Alexander,
>>>
>>> Could you answer one question:
>>> Why did you choose default interface methods to implement
>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>> declarations only in the interface?
>>> AFAIK the common point of view is default methods should be used
>>> rarely because they may lead to unreadable code.
>>>
>>    The only problem which I know about default methods is multiple
>> inheritance which has its own solution.
>
> What kind of problems? The benefit is obvious: it will not be 
> necessary to implement all methods if only one of them should be tweaked.
>
>>
>>    Could you give links to discussion or provide use cases where default
>> methods leads to the unreadable code and show how does it relate to the
>> TextUIDrawing  implementation?
>>
>>    Thanks,
>>    Alexandr.
>>> --Semyon
>>>
>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>
>>>> Could you review the updated fix:
>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>
>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>> package
>>>>   - TextUIDrawing methods description does not mention component
>>>> properties to be more general
>>>>   - TextUIDrawing methods are made default
>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>> defaults using "uiDrawing.text" property
>>>>   - ComponentUI class is not changed
>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>   - There is an interesting issue described in
>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html 
>>>>
>>>>     which is related to the fact that MetalLabelUI returns a static
>>>> field from createUI() method.
>>>>     TitleBorder creates a JLabel but does not put it to any component
>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() method
>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>> label UI is not changed in this case and it still uses the
>>>> metalLabelUI field which is not initialized.
>>>>     It seems that other applications can also use components just for
>>>> drawing and have the same issue.
>>>>     For this case the textUIDrawing field is not cleared in the
>>>> uninstallDefaults but just set to a static default value which should
>>>> not lead to memory leaks.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>> Hi Alexandr,
>>>>>>
>>>>>>> Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>> ....
>>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>> package
>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>>>>> ComponentUI class
>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>> defaults using
>>>>>>> "uiDrawing.text" property
>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>> for text
>>>>>>> drawing and measuring
>>>>>> Some thoughts on the current design/implementation:
>>>>>>
>>>>>> By adding a field to the ComponentUI class the current
>>>>>> implementation increases
>>>>>> memory consumption for all Swing applications. And you get the
>>>>>> feeling that
>>>>>> there are different implementations of TextUIDrawing per
>>>>>> ComponentUI instances.
>>>>>> Personally I can't imagine to have different implementations of
>>>>>> TextUIDrawing for
>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>> implement it as
>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) and not
>>>>>> the ComponentUI.
>>>>>> Developers can use then the following code to obtain the instance of
>>>>>> TextUIDrawing:
>>>>>>
>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>>> short cut for the line above.
>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>> the LookAndFeel
>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>   It means that accessing an instance of a TextUIDrawing will leads
>>>>> to a time consumption.
>>>>>
>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...) usage:
>>>>>   1. ComponentUI classes
>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>   3. Public utilities methods (like WindowsGraphicsUtils.paintText())
>>>>>
>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>> UIDrawing instance during installUI()/updateUI() calls to decrease a
>>>>> time access to it.
>>>>>
>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>> time (which is taken from an App context)
>>>>>   or use the passed JComponent object. It requires to have a public
>>>>> method and the associated variable for each instance of
>>>>> JComponent/ComponentUI/... class.
>>>>>> You can use this methods then in JDK too.
>>>>>>
>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>>> more useful methods,
>>>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>>>> to pixels.
>>>>>   UIDrawing name may look like it should be used for any UI drawing,
>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Andrej Golovnin
>>>>>
>>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Thu Mar 31 20:09:12 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 31 Mar 2016 23:09:12 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56FD791E.1050707@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
Message-ID: <56FD83E8.3060202@oracle.com>

Just a small clarification. In general implementations of these methods 
can make some "magic", but the purpose of the change is to provide to 
the user this "magic", I mean the user's components will be able to 
apply this "magic" to the custom components(or change behavior of 
standard l&f). So in the latest webrev some of implementations details 
of these methods were hidden.
I am not sure we express this goal successfully or not.

On 31.03.16 22:23, Phil Race wrote:
> Maybe the test to pass in that case is whether the default implementation
> is going to be satisfactory for 90% of uses. If they are frequently
> over-ridden
> it would not be an appropriate use.
>
> Based on that criterion I think it is OK to use here.
>
> Another thought:
> When you add default implementations you should also be on the hook
> for explaining what that does. It is a deeper contract than you would
> otherwise have as an interface and maybe needs to be an @implNote
> or you need to call out the default implementation.
> ie there is what someone must code to satisfy the contract of the
> interface and what is a behaviour in the default method ?
>
>
> Also here is a link to some comments by Brian Goetz on default methods :
>
> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917
>
>
>    75      * No character is underlined if the index is negative or greater
>    76      * than the string length {@code (index < 0 || index >=
> string.length())}
>    77      * or if the char value specified at the given index
>    78      * is in the low-surrogate range.
>
>
> I suppose if you point at the last char and it is a hi-surrogate nothing
> is underlined in that case either.
>
> But I find the whole writing of this a bit inadequate as if you are
> going to
> this kind of detail you perhaps also need to say what happens in a complex
> script where what happens is two unicode characters end up as a ligature,
> and/or perhaps you aren't even pointing to a base character.
> Maybe it is in fact over-specified. I see that the implementation draws
> the underline itself rather than delegate to TextLayout. This might
> make sense for performance reasons where it is simple text but some day
> this maybe should be re-examined and so I would not over-specify it.
>
> How about :
> "The underline will be positioned at the base glyph which
> represents the valid char indicated by the index.
> If the char index is not valid or is not the index of a
> valid unicode code point then no underline is drawn"
>
> -phil.
>
>
>
> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>> Hi Alexander,
>>>>
>>>> Could you answer one question:
>>>> Why did you choose default interface methods to implement
>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>>> declarations only in the interface?
>>>> AFAIK the common point of view is default methods should be used
>>>> rarely because they may lead to unreadable code.
>>>>
>>>    The only problem which I know about default methods is multiple
>>> inheritance which has its own solution.
>>
>> What kind of problems? The benefit is obvious: it will not be
>> necessary to implement all methods if only one of them should be tweaked.
>>
>>>
>>>    Could you give links to discussion or provide use cases where default
>>> methods leads to the unreadable code and show how does it relate to the
>>> TextUIDrawing  implementation?
>>>
>>>    Thanks,
>>>    Alexandr.
>>>> --Semyon
>>>>
>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Could you review the updated fix:
>>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>
>>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>>> package
>>>>>   - TextUIDrawing methods description does not mention component
>>>>> properties to be more general
>>>>>   - TextUIDrawing methods are made default
>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>> defaults using "uiDrawing.text" property
>>>>>   - ComponentUI class is not changed
>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>   - There is an interesting issue described in
>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>>>>>
>>>>>     which is related to the fact that MetalLabelUI returns a static
>>>>> field from createUI() method.
>>>>>     TitleBorder creates a JLabel but does not put it to any component
>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() method
>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>> label UI is not changed in this case and it still uses the
>>>>> metalLabelUI field which is not initialized.
>>>>>     It seems that other applications can also use components just for
>>>>> drawing and have the same issue.
>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>> uninstallDefaults but just set to a static default value which should
>>>>> not lead to memory leaks.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>> Hi Alexandr,
>>>>>>>
>>>>>>>> Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>> ....
>>>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>>> package
>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>>>>>> ComponentUI class
>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>> defaults using
>>>>>>>> "uiDrawing.text" property
>>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>>> for text
>>>>>>>> drawing and measuring
>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>
>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>> implementation increases
>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>> feeling that
>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>> ComponentUI instances.
>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>> TextUIDrawing for
>>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>>> implement it as
>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) and not
>>>>>>> the ComponentUI.
>>>>>>> Developers can use then the following code to obtain the instance of
>>>>>>> TextUIDrawing:
>>>>>>>
>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>>>> short cut for the line above.
>>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>>> the LookAndFeel
>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>   It means that accessing an instance of a TextUIDrawing will leads
>>>>>> to a time consumption.
>>>>>>
>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...) usage:
>>>>>>   1. ComponentUI classes
>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>   3. Public utilities methods (like WindowsGraphicsUtils.paintText())
>>>>>>
>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>> UIDrawing instance during installUI()/updateUI() calls to decrease a
>>>>>> time access to it.
>>>>>>
>>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>>> time (which is taken from an App context)
>>>>>>   or use the passed JComponent object. It requires to have a public
>>>>>> method and the associated variable for each instance of
>>>>>> JComponent/ComponentUI/... class.
>>>>>>> You can use this methods then in JDK too.
>>>>>>>
>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>>>> more useful methods,
>>>>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>>>>> to pixels.
>>>>>>   UIDrawing name may look like it should be used for any UI drawing,
>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Andrej Golovnin
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Thu Mar 31 22:36:58 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 31 Mar 2016 15:36:58 -0700
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <56FCC8B4.1040406@oracle.com>
References: <56FCC8B4.1040406@oracle.com>
Message-ID: <56FDA68A.1020805@oracle.com>

This looks good to me.

-phil.

On 03/30/2016 11:50 PM, Alexandr Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8136366
>   webrev: http://cr.openjdk.java.net/~alexsch/8136366/webrev.00
>
>   Some Swing L&Fs are not public. It is not possible to create them 
> using reflection now in JDK 9 because of the modularization feature.
>
>   There are use cases when some information should be obtained from a 
> L&F without its installation
>    - check if L&F is supported
>    - take some defaults to use it in custom L&F
>
>   The proposed solution adds UIManager.createLookAndFeel(className) 
> method which allows to create a given L&F without installation.
>
>  Thanks,
>  Alexandr.
>