From rajeev.chamyal at oracle.com  Sat Jan  2 06:15:37 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Fri, 1 Jan 2016 22:15:37 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8145896 JInternalFrame
 setMaximum before adding to desktop throws null pointer exception
In-Reply-To: <5683F273.2000808@oracle.com>
References: <e9072916-7d94-4d7d-b90b-d79741458bd3@default>
	<567AAC2C.4060203@oracle.com>
	<55a23711-f731-458d-a4f9-c88718db88d8@default>
	<5683F273.2000808@oracle.com>
Message-ID: <6c9af273-8385-4b40-8e11-83d1e0d8212f@default>

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 avik.niyogi at oracle.com  Mon Jan  4 08:52:16 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 4 Jan 2016 14:22:16 +0530
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
	behaviour doesn't comply API documentation
	(setComponentOrientation method), Aqua LAF
In-Reply-To: <FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
Message-ID: <7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>

Hi All,

Please review the webrev.01 : http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/>
incorporated with the inputs received.

With Regards,
Avik Niyogi

> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi Alexandr,
> 
> Automated test may fail based on folder contents on individual systems irrespective of the fix directly not depending on the same. 
> Also, to confirm this fix, it will need visual confirmation and hence, no automated test was provided.
> 
> With Regards,
> Avik Niyogi
>> On 23-Dec-2015, at 7:32 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>> 
>> 
>> 
>>   The fix looks good to me.
>> 
>>   Is it possible to write an automated test for the fix?
>> 
>>   Thanks,
>>   Alexandr.
>> 
>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>> Hi All,
>>> 
>>> Kindly review the bug fix for JDK 9.
>>> 
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8016665 <https://bugs.openjdk.java.net/browse/JDK-8016665>
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>> 
>>> Issue:
>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>> in testsuite fails.
>>> 
>>> Cause:
>>> Due to not honouring of RIGHT_TO_LEFT parameter for setOrientation method applied for a JFileChooser for the AquaLookAndFeel only,
>>> the fileChooser does not get displayed in RIGHT_TO_LEFT orientation. 
>>> This issue was verified to exist only in AquaLookAndFeel for JFileChooser only due to wrong implementation in AquaFileSystemModel.
>>> Also, as provided in comments: "The Aqua LAF must support the RTL orientation of JFileChooser."
>>> 
>>> Fix:
>>> Added implementation for the check of RIGHT_TO_LEFT ComponentOrientation and verified with test suite.
>>> 
>>> 
>>> With Regards,
>>> Avik Niyogi
>> 
> 

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

From avik.niyogi at oracle.com  Mon Jan  4 09:41:00 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 4 Jan 2016 15:11:00 +0530
Subject: <Swing Dev> Review request for 8041894: Test
	javax/swing/JSpinner/8008657/bug8008657.java failed on Mac
In-Reply-To: <56813AB4.2070503@oracle.com>
References: <D47FB485-40D8-4C2D-9F78-499E79A0A1C5@oracle.com>
	<567493EC.6030304@oracle.com>
	<3AF15B6F-06D6-4E4A-B8C8-EB68A4DF0379@oracle.com>
	<56813AB4.2070503@oracle.com>
Message-ID: <F6AB5612-764C-4900-92C1-DA8D35CD3F74@oracle.com>

Hi All,
Please review the following incorporated with inputs provided
http://cr.openjdk.java.net/~aniyogi/8041894/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8041894/webrev.01/>

With Regards,
Avik Niyogi
> On 28-Dec-2015, at 7:05 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Avik
> On 21/12/15 07:17, Avik Niyogi wrote:
>> Hi Sergey,
>> I verified that the issue is only with Aqua Look and feel and not other
>> look and feels.
> 
> It will be better to prove it in the test, so the bug will not occur again in some other/new L&F.
> 
>> The type cast for ComponentOrientation was done in the code just for two
>> reasons:
>> 1) User readability for the component within the event e.
>> 2) The cast for which type it is specified. For example, it can be noted
>> that in the older code,
> 
> This is unrelated to the code style. The cases which you selected are necessary because we pass these values to the replaceEditor(), note that parameters of replaceEditor are JComponent, so we must cast in these cases. Same for (ComponentOrientation) e.getNewValue() because we pass it to applyComponentOrientation(ComponentOrientation), but in case of getOldValue it is not necessary because we compare it to null only.
> 
> Also please do not remove the empty line before package com.apple.laf;
> 
>> 
>> if ("editor".equals(propertyName)) {
>>                     final JComponent oldEditor = *(JComponent)*
>> e.getOldValue();
>>                     final JComponent newEditor = *(JComponent)*
>> e.getNewValue();
>>                     ui.replaceEditor(oldEditor, newEditor);
>>                     ui.updateEnabledState();
>>                 } else if ("componentOrientation".equals(propertyName)) {
>>                     ComponentOrientation o
>>                             = (ComponentOrientation) e.getNewValue();
>>                     if (o != (ComponentOrientation) e.getOldValue()) {
>>                         JComponent editor = spinner.getEditor();
>>                         if (editor != null) {
>>                             editor.applyComponentOrientation(o);
>>                         }
>>                         spinner.revalidate();
>>                         spinner.repaint();
>>                     }
>> Casting of JComponent is done explicitly for the values there.
>> Maintaining same standard
>> and scoping out uncertainty seems correct in the context.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 19-Dec-2015, at 4:47 am, 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.
>>> Looks fine to me. It seems that the cast here is not necessary?
>>> if (o != (ComponentOrientation) e.getOldValue())
>>> 
>>> Can you confirm that this bug not affectes our other looks and feels?
>>> It will be good to update the test to prove that.
>>> 
>>> On 17/12/15 10:21, Avik Niyogi wrote:
>>>> 
>>>> 
>>>> Hi All,
>>>> 
>>>> Kindly review the fix for JDK9.
>>>> *Bug*:https://bugs.openjdk.java.net/browse/JDK-8041894 <https://bugs.openjdk.java.net/browse/JDK-8041894>
>>>> 
>>>> *Webrev*: http://cr.openjdk.java.net/~aniyogi/8041894/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8041894/webrev.00/>
>>>> 
>>>> *Issue*: Test case throws an exception as subcomponents of were not
>>>> getting orientation
>>>> property assignment.
>>>> 
>>>> *Cause*: The case where property name as Component orientation not
>>>> present to traverse
>>>> the property to subcomponents of spinner for Aqua look and feel.
>>>> 
>>>> *Fix*: The else if clause for this property name was added while
>>>> checking for for editor to
>>>> take charge of applying the component orientation to all subsequent
>>>> subcomponents.
>>>> 
>>>> 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/20160104/2773e2e1/attachment.html>

From avik.niyogi at oracle.com  Tue Jan  5 10:22:13 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 5 Jan 2016 15:52:13 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <567AA8BF.5030407@oracle.com>
References: <EB8A0826-B75D-4FB7-8BF0-41C1E7C40CBA@oracle.com>
	<567AA8BF.5030407@oracle.com>
Message-ID: <F8D8FE05-3A26-40B4-98A2-3BF0724EE408@oracle.com>

Hi All,
Please find webrev with inputs as provided: http://cr.openjdk.java.net/~aniyogi/8015748/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.01/>
With Regards,
Avik Niyogi

> On 23-Dec-2015, at 7:29 pm, Alexander Scherbatiy <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 <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/>
>> 
>> 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 <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
> 

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

From rajeev.chamyal at oracle.com  Mon Jan 11 09:57:03 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Mon, 11 Jan 2016 01:57:03 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8145896 JInternalFrame
 setMaximum before adding to desktop throws null pointer exception
In-Reply-To: <6c9af273-8385-4b40-8e11-83d1e0d8212f@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>
Message-ID: <9f2eba3e-a1e2-400a-b251-d7769e403349@default>

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 rajeev.chamyal at oracle.com  Mon Jan 11 09:57:34 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Mon, 11 Jan 2016 01:57:34 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8145060 Minimizing a
 JInternal frame not shifting focus to frame below it
In-Reply-To: <fdcfa73b-1bfb-4ed9-8aa7-a46f73348f5a@default>
References: <6e594a8b-fc5b-4d4d-abfa-ed54d5718323@default>
	<567D666A.9010008@oracle.com>
	<7de3ac7e-b723-465e-b179-7bffa38b1eb6@default>
	<56829611.2030704@oracle.com>
	<fdcfa73b-1bfb-4ed9-8aa7-a46f73348f5a@default>
Message-ID: <fffba5ec-4c9a-438f-bb6b-545f0258112a@default>

Hello Sergey,

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

Regards,
Rajeev Chamyal

-----Original Message-----
From: Rajeev Chamyal 
Sent: 30 December 2015 13:33
To: Sergey Bylokhov; Alexander Scherbatiy; Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: RE: Review request for JDK-8145060 Minimizing a JInternal frame not shifting focus to frame below it

Hello Sergey,

I have updated the webrev.
http://cr.openjdk.java.net/~rchamyal/8145060/webrev.01/

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov
Sent: 29 December 2015 19:48
To: Rajeev Chamyal; Alexander Scherbatiy; Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: Review request for JDK-8145060 Minimizing a JInternal frame not shifting focus to frame below it

On 28/12/15 10:45, Rajeev Chamyal wrote:
> Hello Sergey,
>
> Thanks for the review. I have updated the code.
> http://cr.openjdk.java.net/~rchamyal/8145060/webrev.01/

This patch has some additional changes.

>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 25 December 2015 21:23
> To: Rajeev Chamyal; Alexander Scherbatiy; Prasanta Sadhukhan; 
> swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8145060 Minimizing a JInternal 
> frame not shifting focus to frame below it
>
> Hi, Rajeev.
> I guess "d.setComponentOrderCheckingEnabled(false);" should be moved also for consistency.
>
> On 14/12/15 08:32, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145060
>>
>> Webrev:http://cr.openjdk.java.net/~rchamyal/8145060/webrev.00/
>>
>> Issue: On minimizing the successive internal frames the focus is not 
>> shifting to frame below it.
>>
>> Cause: During minimize internal frame is removed from container.
>> Removal of internal frames from container also removes the internal 
>> frame entry from internal frame cache.
>>
>> During focus shift cache is checked for current internal frame entry 
>> and then focus is shifted to frame below it. As removal from 
>> container has already updated the cache so
>>
>> Current frame is not found in cache and focus shift fails.
>>
>> Fix: Internal frame removal from container is done after focus shift.
>>
>> Regards,
>>
>> Rajeev Chamyal
>>
>
>
> --
> Best regards, Sergey.
>


--
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Mon Jan 11 10:25:07 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 11 Jan 2016 13:25:07 +0300
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <F8D8FE05-3A26-40B4-98A2-3BF0724EE408@oracle.com>
References: <EB8A0826-B75D-4FB7-8BF0-41C1E7C40CBA@oracle.com>
	<567AA8BF.5030407@oracle.com>
	<F8D8FE05-3A26-40B4-98A2-3BF0724EE408@oracle.com>
Message-ID: <56938303.8050907@oracle.com>

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/>
> 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>> 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/>
>>>
>>> *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
>>
>

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

From alexandr.scherbatiy at oracle.com  Mon Jan 11 15:15:31 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 11 Jan 2016 19:15:31 +0400
Subject: <Swing Dev> Review request for JDK-4769772
 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
 state
In-Reply-To: <582d26a5-e3d9-4904-9d43-e8385fc8d928@default>
References: <34136115-bd25-43f6-bbdd-c98bc1dbfe17@default>
	<567AA5A5.3090901@oracle.com> <567AA83C.9080308@oracle.com>
	<f72acbe9-3286-4f31-b6c8-5c8a4f446bbc@default>
	<567D39FE.1080906@oracle.com>
	<c7df14dd-ff6c-4ace-abe4-bacdfbfba2a1@default>
	<56811B7D.7050700@oracle.com>
	<ec263842-57e7-423d-92ec-ddb0f2b86688@default>
	<56813CD8.4040301@oracle.com>
	<582d26a5-e3d9-4904-9d43-e8385fc8d928@default>
Message-ID: <5693C713.3030208@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 30/12/15 11:26, Rajeev Chamyal wrote:
> Hello All,
>
> I need one more review for this webrev.
> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.03/
>
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexey Ivanov
> Sent: 28 December 2015 19:15
> To: Rajeev Chamyal; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> Review request for JDK-4769772 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong state
>
> Hi Rajeev,
>
> The updated version looks good to me.
>
> Regards,
> Alexey
>
> On 28.12.2015 16:25, Rajeev Chamyal wrote:
>> Hello Alexey,
>>
>> Thanks for the review. I have updated the code.
>> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.03/
>>
>> 1) I suggest moving these lines:
>>
>>                if (c == null || d == null) {
>>                     return;
>>                 }
>>
>> above calculations of desktopIcon position. Why shall we waste time calculating the position if we ignore the operation eventually?
>> [Rajeev Chamyal] Updated the code as suggested.
>>
>> 2) Yet your new errorMessage filed has the same issue. It should be marked volatile since it's accessed from different threads without synchronization. Actually I suggest storing the exception itself rather than the error message only. If exception is null, the test passed, if it's not, the test failed and you just print the exception and re-throw it to the test framework. What do you think?
>> [Rajeev Chamyal] Test updated to make errorMessage volatile. errorMessage stores all exception messages which may occur in different LAFs and on test completion message is thrown with RunTimeException to mark test failure.
> I got your idea: you iterate over all LaFs accumulating failed LaFs rather than fail the test at the first failure.
>
>> 3) robot.delay(1000) in executeTest() is unnecessary, isn't it?
>> [Rajeev Chamyal] Removed the robot.delay and added robot.waitForIdle() call.
>>
>>
>> 4) You change the code for Synth and Aqua LaF but your test does not cover them. I suggest iterating over all installed LaFs and run the test case in all the LaFs.
>> Does it make it sense to print the current LaF at least for the failed test?
>>    [Rajeev Chamyal]  Test prints all exception messages along with  failed LaF names on test completion.
>>
>> 5) Shouldn't test fail if PropertyVetoException is thrown for f.setIcon(true)? I believe it's not expected in this case.
>>    [Rajeev Chamyal]  PropertyVetoException exception is considered test failure.
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexey Ivanov
>> Sent: 28 December 2015 16:53
>> To: Rajeev Chamyal; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> Review request for JDK-4769772
>> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
>> state
>>
>> Hi Rajeev,
>>
>> Thank you for updating the code and the test.
>>
>> Please see my comments inline.
>>
>> On 28.12.2015 10:37, Rajeev Chamyal wrote:
>>> Hello Alexey,
>>>
>>> Thanks for the review. I have updated the code as suggested.
>>> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.02/
>>> Please see response to questions inline.
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Alexey Ivanov
>>> Sent: 25 December 2015 18:14
>>> To: Rajeev Chamyal; swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> Review request for JDK-4769772
>>> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes
>>> wrong state
>>>
>>> Hi Rajeev,
>>>
>>> Thank you for updating the code.
>>>
>>> I have a couple more questions though.
>>>
>>> 1. SynthDesktopPaneUI
>>> What is the purpose of this line?
>>>         d.setBounds(r.x, r.y, r.width, r.height);
>>>
>>> Since d is a JDesktopPane which contains the frame, you change the location and size of the desktop pane to those of the iconified frame.
>>> It doesn't seem right to me. Could you please clarify your intention?
>>> [Rajeev Chamyal] It's a typo updated the code. We need to set bounds for desktopIcon instead of desktop pane.
>> I suggest moving these lines:
>>
>>                if (c == null || d == null) {
>>                     return;
>>                 }
>>
>> above calculations of desktopIcon position. Why shall we waste time calculating the position if we ignore the operation eventually?
>>> 2. dispose() method is never used in the test, so it could be removed.
>>> [Rajeev Chamyal] Removed from test code.
>>>
>>> 3. Since testFailed field is accessed from different threads, it should be marked volatile.
>>> [Rajeev Chamyal] Test updated to check all LAF. testFailed variable is not used now.
>> Yet your new errorMessage filed has the same issue. It should be marked volatile since it's accessed from different threads without synchronization. Actually I suggest storing the exception itself rather than the error message only. If exception is null, the test passed, if it's not, the test failed and you just print the exception and re-throw it to the test framework. What do you think?
>>> 4. robot.delay(1000) in executeTest() is unnecessary, isn't it?
>>> [Rajeev Chamyal]  As its UI test so added delay for user to check visually as well.
>> Think about it this way: you have, let's say, 20 automated UI tests which are similar to this one. There are five LaFs available on Windows, so the test takes at least 12 seconds. Thus you need at least 4 minutes to execute all 20 tests which is spent in delays. I don't think it's good.
>>
>> So I propose to remove all delays. If the test fails, the user could add a delay to visually inspect the result of the test.
>>
>> At the same time, to make test more stable, you should keep
>>
>> robot.waitForIdle();
>>
>> after createUI() which was in the test code in the previous webrevs.
>>> 5. You change the code for Synth and Aqua LaF but your test does not cover them. I suggest iterating over all installed LaFs and run the test case in all the LaFs.
>>> [Rajeev Chamyal]  Updated the test for all LAF's
>> Does it make it sense to print the current LaF at least for the failed test?
>>> 6. Shouldn't test fail if PropertyVetoException is thrown for f.setIcon(true)? I believe it's not expected in this case.
>>> [Rajeev Chamyal]  Updated code. But this exception is not expected.
>> Since this exception is not expected, it could be considered a test failure.
>>
>> Regards,
>> Alexey
>>> 7. Probably any exception thrown during test execution should also be considered as failure, otherwise catch in executeTest().Runnable{}.run() is redundant.
>>> [Rajeev Chamyal] Test code is updated to handle all exceptions as failures.
>>>
>>> Regards,
>>> Alexey
>>>
>>> On 24.12.2015 10:19, Rajeev Chamyal wrote:
>>>> Hello Alexey,
>>>>
>>>> Thanks for the review.
>>>> I have updated webrev as per review comments.
>>>>
>>>> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.01/
>>>>
>>>> Regards,
>>>> Rajeev Chamyal
>>>>
>>>> -----Original Message-----
>>>> From: Alexey Ivanov
>>>> Sent: 23 December 2015 19:27
>>>> To: swing-dev at openjdk.java.net
>>>> Subject: Re: <Swing Dev> Review request for JDK-4769772
>>>> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes
>>>> wrong state
>>>>
>>>> Hi Rajeev,
>>>>
>>>> One more comment:
>>>> You should call dispose() in finally block in main so that the frame is closed automatically if the test fails.
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>> On 23.12.2015 16:46, Alexey Ivanov wrote:
>>>>> Hi Rajeev,
>>>>>
>>>>> There's a potential NullPointerException in this line of
>>>>> BasicInternalFrameUI.java:
>>>>>         if(value.equals(Boolean.FALSE))
>>>>>
>>>>> I suggest eliminating it using this construct:
>>>>>         if (Boolean.FALSE.equals(value))
>>>>>
>>>>> This way the code is safer.
>>>>>
>>>>>
>>>>> Can the test be simplified? Is it really required to create menu
>>>>> and use robot to invoke commands?
>>>>> Wouldn't it be enough to programmatically add minimized internal
>>>>> frame and then check its properties?
>>>>>
>>>>> JFrame in test should also be instantiated on EDT, in createUI() method.
>>>>>
>>>>>
>>>>> And a general recommendation to follow Java Coding Style [1] and in
>>>>> particular to add a space [2] after 'if',  after comma in argument
>>>>> lists, and after cast operator.
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>> [1] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
>>>>> [2]
>>>>> http://www.oracle.com/technetwork/java/javase/documentation/codecon
>>>>> v
>>>>> e
>>>>> n
>>>>> tions-141388.html#682
>>>>>
>>>>> On 18.12.2015 11:44, Rajeev Chamyal wrote:
>>>>>> Hello All,
>>>>>>
>>>>>> Please review the following fix for Jdk9:
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4769772
>>>>>>
>>>>>> Webrev:http://cr.openjdk.java.net/~rchamyal/4769772/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/4769772/webrev.00/>
>>>>>>
>>>>>> Issue: Iconifying a frame before adding it to desktop pane is not
>>>>>> working.
>>>>>>
>>>>>> Cause: Setting setIcon property of a JInternalFrame before
>>>>>> addition to desktop pane fails to find the desktop as a result its
>>>>>> always in maximized state.
>>>>>> Fix: Added method to check if frame is already iconified before
>>>>>> addition.
>>>>>> Verified the fix on windows,Ubuntu and Mac with all layouts.
>>>>>> Also, removed unused imports from JDesktopPane.java as part of fix.
>>>>>> Regards,
>>>>>> Rajeev Chamyal
>>>>>>



From alexandr.scherbatiy at oracle.com  Mon Jan 11 15:42:09 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 11 Jan 2016 19:42:09 +0400
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
 behaviour doesn't comply API documentation (setComponentOrientation method),
 Aqua LAF
In-Reply-To: <7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
	<7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
Message-ID: <5693CD51.50504@oracle.com>


Is it possible to make an automated test which compare colors from the 
5/6 part of the progress bar
when its value is set to 0 and 30? If these colors are the same it means 
that the progress has been painted on the left side instead of right.

Thanks,
Alexandr.


On 04/01/16 12:52, Avik Niyogi wrote:
> Hi All,
>
> Please review the webrev.01 : 
> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.01/>
> incorporated with the inputs received.
>
> With Regards,
> Avik Niyogi
>
>> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niyogi at oracle.com 
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi Alexandr,
>>
>> Automated test may fail based on folder contents on individual 
>> systems irrespective of the fix directly not depending on the same.
>> Also, to confirm this fix, it will need visual confirmation and 
>> hence, no automated test was provided.
>>
>> With Regards,
>> Avik Niyogi
>>> On 23-Dec-2015, at 7:32 pm, Alexander Scherbatiy 
>>> <alexandr.scherbatiy at oracle.com 
>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>
>>>
>>>
>>>   The fix looks good to me.
>>>
>>>   Is it possible to write an automated test for the fix?
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>>> Hi All,
>>>>
>>>> Kindly review the bug fix for JDK 9.
>>>>
>>>> *Bug:*
>>>> https://bugs.openjdk.java.net/browse/JDK-8016665
>>>>
>>>> *Webrev:*
>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>>>
>>>> *Issue:*
>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>> in testsuite fails.
>>>>
>>>> *Cause:*
>>>> Due to not honouring of RIGHT_TO_LEFT parameter for setOrientation 
>>>> method applied for a JFileChooser for the AquaLookAndFeel only,
>>>> the fileChooser does not get displayed in RIGHT_TO_LEFT orientation.
>>>> This issue was verified to exist only in AquaLookAndFeel for 
>>>> JFileChooser only due to wrong implementation in AquaFileSystemModel.
>>>> Also, as provided in comments: "The Aqua LAF must support the RTL 
>>>> orientation of JFileChooser."
>>>>
>>>> *Fix:*
>>>> Added implementation for the check of RIGHT_TO_LEFT 
>>>> ComponentOrientation and verified with test suite.
>>>>
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>
>>
>

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

From peter.brunet at oracle.com  Mon Jan 11 21:47:22 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 11 Jan 2016 15:47:22 -0600
Subject: <Swing Dev> RfR JDK-8145735,
 Tests api/javax_swing/JTabbedPane/AccessibleJTabbedPane/* are
 failing
Message-ID: <569422EA.7030501@oracle.com>

Please review this patch:

http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.00/

The issue being resolved is that the JTabbedPane code can't solely rely
on tabComponent when fetching the index in the parent component. 
tabComponent is optionally used and its presence indicates that the
associated Component will render the tab title; otherwise the
JTabbedPane tab will.  In those cases where tabComponent is used, if it
is null then the tab's title must be used when determining the index in
parent, i.e. parent.indexofTab(getTitle()) vs
parent.indexOfTabComponent(tabComponent).

The regression test was improved to catch the cases where the fix to
JTabbedPane was not applied.  The regression test was also changed so
the exception message is more cleanly displayed when the test fails.


From rajeev.chamyal at oracle.com  Tue Jan 12 04:21:17 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Mon, 11 Jan 2016 20:21:17 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8146276 : Right aligned ToolBar
 component does not appear
Message-ID: <37426965-3e73-4526-9ead-1acf10616ce5@default>

Hello All,

Please review the following fix for Jdk9:

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

Issue : Right aligned ToolBar component does not appear
Cause: While calculating the minimum layout size for the components SynthToolBar is not checking if preferred size is set for the components.

Fix: Updated the minimumLayoutSize method of SynthToolBarUI.java to check preferred size of components as well.

Regards,
Rajeev Chamyal


From avik.niyogi at oracle.com  Tue Jan 12 09:22:58 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 12 Jan 2016 14:52:58 +0530
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
	behaviour doesn't comply API documentation
	(setComponentOrientation method), Aqua LAF
In-Reply-To: <5693CD51.50504@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
	<7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
	<5693CD51.50504@oracle.com>
Message-ID: <2688F97C-300C-4869-A9D8-058DCA3BD082@oracle.com>

Hi Alexander,

Due to animation effects on Aqua look and feel, the color checks can not be used as seen in the image below:

The Blue color is not homogeneously distributed and varies continuously. Since this is a fix for Aqua look and feel mainly, we need to perform a visual confirmation itself.
Hence, manual test is essential in this case.

With Regards,
Avik Niyogi

> On 11-Jan-2016, at 9:12 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> 
> Is it possible to make an automated test which compare colors from the 5/6 part of the progress bar
> when its value is set to 0 and 30? If these colors are the same it means that the progress has been painted on the left side instead of right.
> 
> Thanks,
> Alexandr.
>  
> 
> On 04/01/16 12:52, Avik Niyogi wrote:
>> Hi All,
>> 
>> Please review the webrev.01 :  <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.01/>http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/>
>> incorporated with the inputs received.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>> 
>>> Hi Alexandr,
>>> 
>>> Automated test may fail based on folder contents on individual systems irrespective of the fix directly not depending on the same. 
>>> Also, to confirm this fix, it will need visual confirmation and hence, no automated test was provided.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 23-Dec-2015, at 7:32 pm, Alexander Scherbatiy < <mailto:alexandr.scherbatiy at oracle.com>alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>   The fix looks good to me.
>>>> 
>>>>   Is it possible to write an automated test for the fix?
>>>> 
>>>>   Thanks,
>>>>   Alexandr.
>>>> 
>>>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the bug fix for JDK 9.
>>>>> 
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8016665 <https://bugs.openjdk.java.net/browse/JDK-8016665>
>>>>> 
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>>>> 
>>>>> Issue:
>>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>>> in testsuite fails.
>>>>> 
>>>>> Cause:
>>>>> Due to not honouring of RIGHT_TO_LEFT parameter for setOrientation method applied for a JFileChooser for the AquaLookAndFeel only,
>>>>> the fileChooser does not get displayed in RIGHT_TO_LEFT orientation. 
>>>>> This issue was verified to exist only in AquaLookAndFeel for JFileChooser only due to wrong implementation in AquaFileSystemModel.
>>>>> Also, as provided in comments: "The Aqua LAF must support the RTL orientation of JFileChooser."
>>>>> 
>>>>> Fix:
>>>>> Added implementation for the check of RIGHT_TO_LEFT ComponentOrientation and verified with test suite.
>>>>> 
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160112/87434df0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 16906 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160112/87434df0/PastedGraphic-1.tiff>

From avik.niyogi at oracle.com  Tue Jan 12 09:34:21 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 12 Jan 2016 15:04:21 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <56938303.8050907@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>
Message-ID: <DAD2ACAB-5640-40E4-89B2-B1256EB53A5B@oracle.com>

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/~aniyogi/8015748/webrev.02/>

With Regards,
Avik Niyogi

> On 11-Jan-2016, at 3:55 pm, Semyon Sadetsky <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/%7Eaniyogi/8015748/webrev.01/>http://cr.openjdk.java.net/~aniyogi/8015748/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/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>> 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 <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/>
>>>> 
>>>> 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 <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
>>> 
>> 
> 

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

From avik.niyogi at oracle.com  Tue Jan 12 09:44:47 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 12 Jan 2016 15:14:47 +0530
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
	behaviour doesn't comply API documentation
	(setComponentOrientation method), Aqua LAF
In-Reply-To: <2688F97C-300C-4869-A9D8-058DCA3BD082@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
	<7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
	<5693CD51.50504@oracle.com>
	<2688F97C-300C-4869-A9D8-058DCA3BD082@oracle.com>
Message-ID: <1282DA7B-AD51-4BDE-9EE6-D2C9C9838004@oracle.com>

Hi All,
The comment in the mail trail is regarding different bug 8015748. Since, No inputs remain for code review related to this fix, please provide +1 for the fixes.
Thank you in advance.
With Regards,
Avik Niyogi
> On 12-Jan-2016, at 2:52 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi Alexander,
> 
> Due to animation effects on Aqua look and feel, the color checks can not be used as seen in the image below:
> <PastedGraphic-1.tiff>
> The Blue color is not homogeneously distributed and varies continuously. Since this is a fix for Aqua look and feel mainly, we need to perform a visual confirmation itself.
> Hence, manual test is essential in this case.
> 
> With Regards,
> Avik Niyogi
> 
>> On 11-Jan-2016, at 9:12 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>> 
>> 
>> Is it possible to make an automated test which compare colors from the 5/6 part of the progress bar
>> when its value is set to 0 and 30? If these colors are the same it means that the progress has been painted on the left side instead of right.
>> 
>> Thanks,
>> Alexandr.
>>  
>> 
>> On 04/01/16 12:52, Avik Niyogi wrote:
>>> Hi All,
>>> 
>>> Please review the webrev.01 :  <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.01/>http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/>
>>> incorporated with the inputs received.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>> 
>>>> Hi Alexandr,
>>>> 
>>>> Automated test may fail based on folder contents on individual systems irrespective of the fix directly not depending on the same. 
>>>> Also, to confirm this fix, it will need visual confirmation and hence, no automated test was provided.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 23-Dec-2015, at 7:32 pm, Alexander Scherbatiy < <mailto:alexandr.scherbatiy at oracle.com>alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>   The fix looks good to me.
>>>>> 
>>>>>   Is it possible to write an automated test for the fix?
>>>>> 
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>> 
>>>>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> Kindly review the bug fix for JDK 9.
>>>>>> 
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8016665 <https://bugs.openjdk.java.net/browse/JDK-8016665>
>>>>>> 
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>>>>> 
>>>>>> Issue:
>>>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>>>> in testsuite fails.
>>>>>> 
>>>>>> Cause:
>>>>>> Due to not honouring of RIGHT_TO_LEFT parameter for setOrientation method applied for a JFileChooser for the AquaLookAndFeel only,
>>>>>> the fileChooser does not get displayed in RIGHT_TO_LEFT orientation. 
>>>>>> This issue was verified to exist only in AquaLookAndFeel for JFileChooser only due to wrong implementation in AquaFileSystemModel.
>>>>>> Also, as provided in comments: "The Aqua LAF must support the RTL orientation of JFileChooser."
>>>>>> 
>>>>>> Fix:
>>>>>> Added implementation for the check of RIGHT_TO_LEFT ComponentOrientation and verified with test suite.
>>>>>> 
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>> 
>>>> 
>>> 
>> 
> 

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

From avik.niyogi at oracle.com  Tue Jan 12 09:51:56 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 12 Jan 2016 15:21:56 +0530
Subject: <Swing Dev> Review request for 8041894: Test
	javax/swing/JSpinner/8008657/bug8008657.java failed on Mac
In-Reply-To: <F6AB5612-764C-4900-92C1-DA8D35CD3F74@oracle.com>
References: <D47FB485-40D8-4C2D-9F78-499E79A0A1C5@oracle.com>
	<567493EC.6030304@oracle.com>
	<3AF15B6F-06D6-4E4A-B8C8-EB68A4DF0379@oracle.com>
	<56813AB4.2070503@oracle.com>
	<F6AB5612-764C-4900-92C1-DA8D35CD3F74@oracle.com>
Message-ID: <6D46995A-2183-44E3-B0DE-ED03072BCCBA@oracle.com>

Hi All,
Gentle reminder: Please provide review and provide +1 for the review in case it is acceptable.
Thank you in advance.
With Regards,
Avik Niyogi

> On 04-Jan-2016, at 3:11 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi All,
> Please review the following incorporated with inputs provided
> http://cr.openjdk.java.net/~aniyogi/8041894/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8041894/webrev.01/>
> 
> With Regards,
> Avik Niyogi
>> On 28-Dec-2015, at 7:05 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>> 
>> Hi, Avik
>> On 21/12/15 07:17, Avik Niyogi wrote:
>>> Hi Sergey,
>>> I verified that the issue is only with Aqua Look and feel and not other
>>> look and feels.
>> 
>> It will be better to prove it in the test, so the bug will not occur again in some other/new L&F.
>> 
>>> The type cast for ComponentOrientation was done in the code just for two
>>> reasons:
>>> 1) User readability for the component within the event e.
>>> 2) The cast for which type it is specified. For example, it can be noted
>>> that in the older code,
>> 
>> This is unrelated to the code style. The cases which you selected are necessary because we pass these values to the replaceEditor(), note that parameters of replaceEditor are JComponent, so we must cast in these cases. Same for (ComponentOrientation) e.getNewValue() because we pass it to applyComponentOrientation(ComponentOrientation), but in case of getOldValue it is not necessary because we compare it to null only.
>> 
>> Also please do not remove the empty line before package com.apple.laf;
>> 
>>> 
>>> if ("editor".equals(propertyName)) {
>>>                     final JComponent oldEditor = *(JComponent)*
>>> e.getOldValue();
>>>                     final JComponent newEditor = *(JComponent)*
>>> e.getNewValue();
>>>                     ui.replaceEditor(oldEditor, newEditor);
>>>                     ui.updateEnabledState();
>>>                 } else if ("componentOrientation".equals(propertyName)) {
>>>                     ComponentOrientation o
>>>                             = (ComponentOrientation) e.getNewValue();
>>>                     if (o != (ComponentOrientation) e.getOldValue()) {
>>>                         JComponent editor = spinner.getEditor();
>>>                         if (editor != null) {
>>>                             editor.applyComponentOrientation(o);
>>>                         }
>>>                         spinner.revalidate();
>>>                         spinner.repaint();
>>>                     }
>>> Casting of JComponent is done explicitly for the values there.
>>> Maintaining same standard
>>> and scoping out uncertainty seems correct in the context.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 19-Dec-2015, at 4:47 am, 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.
>>>> Looks fine to me. It seems that the cast here is not necessary?
>>>> if (o != (ComponentOrientation) e.getOldValue())
>>>> 
>>>> Can you confirm that this bug not affectes our other looks and feels?
>>>> It will be good to update the test to prove that.
>>>> 
>>>> On 17/12/15 10:21, Avik Niyogi wrote:
>>>>> 
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the fix for JDK9.
>>>>> *Bug*:https://bugs.openjdk.java.net/browse/JDK-8041894 <https://bugs.openjdk.java.net/browse/JDK-8041894>
>>>>> 
>>>>> *Webrev*: http://cr.openjdk.java.net/~aniyogi/8041894/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8041894/webrev.00/>
>>>>> 
>>>>> *Issue*: Test case throws an exception as subcomponents of were not
>>>>> getting orientation
>>>>> property assignment.
>>>>> 
>>>>> *Cause*: The case where property name as Component orientation not
>>>>> present to traverse
>>>>> the property to subcomponents of spinner for Aqua look and feel.
>>>>> 
>>>>> *Fix*: The else if clause for this property name was added while
>>>>> checking for for editor to
>>>>> take charge of applying the component orientation to all subsequent
>>>>> subcomponents.
>>>>> 
>>>>> 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/20160112/dcd9eda3/attachment.html>

From alexandr.scherbatiy at oracle.com  Tue Jan 12 11:04:48 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Tue, 12 Jan 2016 03:04:48 -0800
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
 behaviour doesn't comply API documentation (setComponentOrientation method),
 Aqua LAF
In-Reply-To: <1282DA7B-AD51-4BDE-9EE6-D2C9C9838004@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
	<7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
	<5693CD51.50504@oracle.com>
	<2688F97C-300C-4869-A9D8-058DCA3BD082@oracle.com>
	<1282DA7B-AD51-4BDE-9EE6-D2C9C9838004@oracle.com>
Message-ID: <5694DDD0.8010006@oracle.com>


I am sorry. The comment really was about the issue 8015748.

The fix looks good for me.

Thanks,
Alexandr.

On 1/12/2016 1:44 AM, Avik Niyogi wrote:
> Hi All,
> The comment in the mail trail is regarding different bug 8015748. 
> Since, No inputs remain for code review related to this fix, please 
> provide +1 for the fixes.
> Thank you in advance.
> With Regards,
> Avik Niyogi
>> On 12-Jan-2016, at 2:52 pm, Avik Niyogi <avik.niyogi at oracle.com 
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi Alexander,
>>
>> Due to animation effects on Aqua look and feel, the color checks can 
>> not be used as seen in the image below:
>> <PastedGraphic-1.tiff>
>> The Blue color is not homogeneously distributed and varies 
>> continuously. Since this is a fix for Aqua look and feel mainly, we 
>> need to perform a visual confirmation itself.
>> Hence, manual test is essential in this case.
>>
>> With Regards,
>> Avik Niyogi
>>
>>> On 11-Jan-2016, at 9:12 pm, Alexander Scherbatiy 
>>> <alexandr.scherbatiy at oracle.com 
>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>
>>>
>>> Is it possible to make an automated test which compare colors from 
>>> the 5/6 part of the progress bar
>>> when its value is set to 0 and 30? If these colors are the same it 
>>> means that the progress has been painted on the left side instead of 
>>> right.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>>
>>> On 04/01/16 12:52, Avik Niyogi wrote:
>>>> Hi All,
>>>>
>>>> Please review the webrev.01 : 
>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/
>>>> incorporated with the inputs received.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>
>>>>> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niyogi at oracle.com 
>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>
>>>>> Hi Alexandr,
>>>>>
>>>>> Automated test may fail based on folder contents on individual 
>>>>> systems irrespective of the fix directly not depending on the same.
>>>>> Also, to confirm this fix, it will need visual confirmation and 
>>>>> hence, no automated test was provided.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>> On 23-Dec-2015, at 7:32 pm, Alexander Scherbatiy 
>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>   The fix looks good to me.
>>>>>>
>>>>>>   Is it possible to write an automated test for the fix?
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>
>>>>>>> *Bug:*
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8016665
>>>>>>>
>>>>>>> *Webrev:*
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/ 
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>>>>>>
>>>>>>> *Issue:*
>>>>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>>>>> in testsuite fails.
>>>>>>>
>>>>>>> *Cause:*
>>>>>>> Due to not honouring of RIGHT_TO_LEFT parameter for 
>>>>>>> setOrientation method applied for a JFileChooser for the 
>>>>>>> AquaLookAndFeel only,
>>>>>>> the fileChooser does not get displayed in RIGHT_TO_LEFT 
>>>>>>> orientation.
>>>>>>> This issue was verified to exist only in AquaLookAndFeel for 
>>>>>>> JFileChooser only due to wrong implementation 
>>>>>>> in AquaFileSystemModel.
>>>>>>> Also, as provided in comments: "The Aqua LAF must support the 
>>>>>>> RTL orientation of JFileChooser."
>>>>>>>
>>>>>>> *Fix:*
>>>>>>> Added implementation for the check of RIGHT_TO_LEFT 
>>>>>>> ComponentOrientation and verified with test suite.
>>>>>>>
>>>>>>>
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Tue Jan 12 12:25:39 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 12 Jan 2016 15:25:39 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <566986FD.9020207@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>
Message-ID: <5694F0C3.8020203@oracle.com>

Hi Alexander,

I see that you've added the next clarifications to the methods specs:

 > draws string/returns width ... using text properties and 
anti-aliasing hints from the provided component

It still seems too brief and even incorrect for getStringWidth().

For drawString():

For non-printing case I would write:

Sets the anti-aliasing rendering hints to the Graphics object if those 
are specified in the component properties. Then the string is drawn 
using the provided Graphics object with the numeric shaper taken into 
account if it is defined for the component.

Please consider the printing case...

For getStringWidth():

Did not get which anti-aliasing hints it takes into account while there 
is no Graphics in the params list...
On the contrary, it does not take into account the rendering context.
My suggestion:

Returns string pixel width by the provided font metrics and according to 
the numeric shaper if it is defined for the component.

--Semyon

For
On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>
>  Hello,
>
>  Could you review the updated fix:
>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>
> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>> Hi Alexandr,
>>
>> I suggest using {@code underlinedIndex} in this sentence:
>>
>> * The {@code underlinedIndex} parameter points to a char value 
>> (Unicode code unit) in the
>> * given string.
>>
>> in the Javadoc for drawStringUnderlineCharAt().
>>
>>
>> And I suggest using "fits" instead of "can fit" in @return for 
>> getClippedString() and rephrasing the conditions where empty string 
>> is returned:
>>
>> * @return the clipped string that fits in the provided space, an empty
>> *         string if the given string argument is {@code null} or empty.
>
>    The fix is updated according to the provided comments.
>
>    Thanks,
>    Alexandr.
>>
>>
>> Regards,
>> Alexey
>>
>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>> Hello,
>>>
>>> Could you review the updated fix:
>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>
>>> - methods description is updated to mention used text properties and 
>>> anti-aliasing hints from the provided component
>>> - the drawStringUnderlineCharAt method description is updated
>>> - @since tag is added for the drawString() method
>>> - the description that some parameters may/must not be null is added
>>> - the test is updated to call the methods on EDT
>>> - the test is updated to check passed null arguments
>>>
>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>> Hi Alexandr,
>>>>
>>>> Shouldn't drawString() also have @since tag?
>>>>
>>>>
>>>> Could you please also clarify whether underlinedIndex in 
>>>> drawStringUnderlineCharAt refers to the char index in the string?
>>>>
>>>> The statement
>>>> * The underlined index refers to char values (Unicode code units).
>>>> makes it unclear: underlinedIndex is an *index* or a *char* 
>>>> (Unicode code point).
>>>
>>>  I updated it to "The underlined index points to a char value 
>>> (Unicode code unit) in the given string."
>>>  The 'refers' word was used for a value at the given index.
>>>  However, I am not sure that the new variant is better.
>>>>
>>>>
>>>> * Nothing is drawn for null string. No character is underlined for the
>>>> * index {@code < 0}, {@code >=} than the string width or if the 
>>>> char value
>>>> * specified at the given index is in the low-surrogate range.
>>>>
>>>> I think it will be better to spell comparison operators, I mean to 
>>>> use  "greater than" rather than ">=". And "length" must be used 
>>>> instead of "width".
>>>>
>>>> I propose the following text:
>>>>
>>>> No character is underlined if the index is negative or greater than 
>>>> the string length or if the char value specified at the given index 
>>>> is in the low-surrogate range.
>>>>
>>>> For the first part of condition, you can add clarification in 
>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>  Updated.
>>>>
>>>>
>>>> For consistency, please remove the full stop in @return tag in 
>>>> description of getClippedString.
>>>
>>> Updated.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>
>>>>> The javadoc references for the #drawStringUnderlineCharAt and 
>>>>> #getClippedString methods are moved after parameters description.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>>
>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>
>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with 
>>>>>> chars that have
>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>> The whole glyph is underlined.
>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>
>>>>>> The char value specified the the underlined index should point to 
>>>>>> the high-surrogate range of a supplementary character.
>>>>>> I updated the javadoc for the 
>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>> -----------------------------
>>>>>> /**
>>>>>> * Draws the given string at the specified location underlining
>>>>>> * the specified character.
>>>>>> * <p>
>>>>>> * The underlined index refers to char values (Unicode code units).
>>>>>> * If the char value specified at the given underlined index is in
>>>>>> * the high-surrogate range and the char value at the following 
>>>>>> index is in
>>>>>> * the low-surrogate range then the supplementary character 
>>>>>> corresponding
>>>>>> * to this surrogate pair is underlined.
>>>>>> * <p>
>>>>>> * Nothing is drawn for null string. No character is underlined 
>>>>>> for the
>>>>>> * index {@code < 0}, {@code >=} than the string width or if the 
>>>>>> char value
>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>> -----------------------------
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>> I don't remember or know how Swing resolves this but the 
>>>>>>>> measurement ones
>>>>>>>> are not reliable since they do not take a Graphics context, so 
>>>>>>>> you cannot
>>>>>>>> measure the string properly. You need a FontRenderContext to 
>>>>>>>> measure.
>>>>>>>
>>>>>>> The provided methods use 
>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method which 
>>>>>>> returns the FontRenderContext associated with the component.
>>>>>>>
>>>>>>>>
>>>>>>>> So as it stands these APIs do not appear suitable to be made 
>>>>>>>> public as they
>>>>>>>> are not reliable.
>>>>>>>>
>>>>>>>> Whilst I could look at the code, if I instead just look at the 
>>>>>>>> API, I am scratching my
>>>>>>>> head over :-
>>>>>>>>
>>>>>>>> public static void drawString(JComponent c, Graphics g, String 
>>>>>>>> text, int x, int y)
>>>>>>>>
>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>> And it says the JComponent may be null.
>>>>>>>> So I am supposing that there is optional information that may 
>>>>>>>> be pulled from the
>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>
>>>>>>> The optional information provided by the component is:
>>>>>>> - java.awt.font.NumericShaper
>>>>>>> - java.awt.font.FontRenderContext
>>>>>>> - antialiasing hints
>>>>>>>
>>>>>>>>
>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if the 
>>>>>>>> index is code point
>>>>>>>> or UTF16 char index and what happens if there is not 1:1 code 
>>>>>>>> point:glyph mapping.
>>>>>>> I will update this.
>>>>>>>>
>>>>>>>> Are we sure that (any of) these really ought/need to be public 
>>>>>>>> - particularly given the
>>>>>>>> resolution of https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>
>>>>>>> These methods are used by JDK L&Fs to draw text. The initial 
>>>>>>> request was to provide public methods that can be used by a 
>>>>>>> custom L&F to draw strings consistently with other L&Fs.
>>>>>>>
>>>>>>> They are also designed to properly render text for printing. To 
>>>>>>> do that they use call to internal ProxyPrintGraphics class to 
>>>>>>> obtain the print graphics context.
>>>>>>>
>>>>>>> Even if printing staff will be public, these methods are just 
>>>>>>> utility methods (in the same way as other text methods in the 
>>>>>>> javax.swing.text.Utilities class) that help easily to draw and 
>>>>>>> print text in the same way as JDK L&Fs do that.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you review the fix:
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>
>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt, 
>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From Sergey.Bylokhov at oracle.com  Tue Jan 12 13:49:49 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Jan 2016 16:49:49 +0300
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
 behaviour doesn't comply API documentation (setComponentOrientation method),
 Aqua LAF
In-Reply-To: <7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
	<7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
Message-ID: <5695047D.3050701@oracle.com>

Hi, Avik.
Is it possible that fFileList can be null? I see that in other places we 
do not check it to null?

On 04/01/16 11:52, Avik Niyogi wrote:
> Hi All,
>
> Please review the webrev.01 :
> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/
> incorporated with the inputs received.
>
> With Regards,
> Avik Niyogi
>
>> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niyogi at oracle.com
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi Alexandr,
>>
>> Automated test may fail based on folder contents on individual systems
>> irrespective of the fix directly not depending on the same.
>> Also, to confirm this fix, it will need visual confirmation and hence,
>> no automated test was provided.
>>
>> With Regards,
>> Avik Niyogi
>>> On 23-Dec-2015, at 7:32 pm, Alexander Scherbatiy
>>> <alexandr.scherbatiy at oracle.com
>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>
>>>
>>>
>>>   The fix looks good to me.
>>>
>>>   Is it possible to write an automated test for the fix?
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>>> Hi All,
>>>>
>>>> Kindly review the bug fix for JDK 9.
>>>>
>>>> *Bug:*
>>>> https://bugs.openjdk.java.net/browse/JDK-8016665
>>>>
>>>> *Webrev:*
>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>>>
>>>> *Issue:*
>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>> in testsuite fails.
>>>>
>>>> *Cause:*
>>>> Due to not honouring of RIGHT_TO_LEFT parameter for setOrientation
>>>> method applied for a JFileChooser for the AquaLookAndFeel only,
>>>> the fileChooser does not get displayed in RIGHT_TO_LEFT orientation.
>>>> This issue was verified to exist only in AquaLookAndFeel for
>>>> JFileChooser only due to wrong implementation in AquaFileSystemModel.
>>>> Also, as provided in comments: "The Aqua LAF must support the RTL
>>>> orientation of JFileChooser."
>>>>
>>>> *Fix:*
>>>> Added implementation for the check of RIGHT_TO_LEFT
>>>> ComponentOrientation and verified with test suite.
>>>>
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Jan 12 13:53:42 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Jan 2016 16:53:42 +0300
Subject: <Swing Dev> Review request for 8041894: Test
 javax/swing/JSpinner/8008657/bug8008657.java failed on Mac
In-Reply-To: <F6AB5612-764C-4900-92C1-DA8D35CD3F74@oracle.com>
References: <D47FB485-40D8-4C2D-9F78-499E79A0A1C5@oracle.com>
	<567493EC.6030304@oracle.com>
	<3AF15B6F-06D6-4E4A-B8C8-EB68A4DF0379@oracle.com>
	<56813AB4.2070503@oracle.com>
	<F6AB5612-764C-4900-92C1-DA8D35CD3F74@oracle.com>
Message-ID: <56950566.2090806@oracle.com>

Looks fine.

On 04/01/16 12:41, Avik Niyogi wrote:
> Hi All,
> Please review the following incorporated with inputs provided
> http://cr.openjdk.java.net/~aniyogi/8041894/webrev.01/
>
> With Regards,
> Avik Niyogi
>> On 28-Dec-2015, at 7:05 pm, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Avik
>> On 21/12/15 07:17, Avik Niyogi wrote:
>>> Hi Sergey,
>>> I verified that the issue is only with Aqua Look and feel and not other
>>> look and feels.
>>
>> It will be better to prove it in the test, so the bug will not occur
>> again in some other/new L&F.
>>
>>> The type cast for ComponentOrientation was done in the code just for two
>>> reasons:
>>> 1) User readability for the component within the event e.
>>> 2) The cast for which type it is specified. For example, it can be noted
>>> that in the older code,
>>
>> This is unrelated to the code style. The cases which you selected are
>> necessary because we pass these values to the replaceEditor(), note
>> that parameters of replaceEditor are JComponent, so we must cast in
>> these cases. Same for (ComponentOrientation) e.getNewValue() because
>> we pass it to applyComponentOrientation(ComponentOrientation), but in
>> case of getOldValue it is not necessary because we compare it to null
>> only.
>>
>> Also please do not remove the empty line before package com.apple.laf;
>>
>>>
>>> if ("editor".equals(propertyName)) {
>>>                     final JComponent oldEditor = *(JComponent)*
>>> e.getOldValue();
>>>                     final JComponent newEditor = *(JComponent)*
>>> e.getNewValue();
>>>                     ui.replaceEditor(oldEditor, newEditor);
>>>                     ui.updateEnabledState();
>>>                 } else if ("componentOrientation".equals(propertyName)) {
>>>                     ComponentOrientation o
>>>                             = (ComponentOrientation) e.getNewValue();
>>>                     if (o != (ComponentOrientation) e.getOldValue()) {
>>>                         JComponent editor = spinner.getEditor();
>>>                         if (editor != null) {
>>>                             editor.applyComponentOrientation(o);
>>>                         }
>>>                         spinner.revalidate();
>>>                         spinner.repaint();
>>>                     }
>>> Casting of JComponent is done explicitly for the values there.
>>> Maintaining same standard
>>> and scoping out uncertainty seems correct in the context.
>>>
>>> With Regards,
>>> Avik Niyogi
>>>
>>>> On 19-Dec-2015, at 4:47 am, Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com
>>>> <mailto:Sergey.Bylokhov at oracle.com><mailto:Sergey.Bylokhov at oracle.com>>
>>>> wrote:
>>>>
>>>> Hi, Avik.
>>>> Looks fine to me. It seems that the cast here is not necessary?
>>>> if (o != (ComponentOrientation) e.getOldValue())
>>>>
>>>> Can you confirm that this bug not affectes our other looks and feels?
>>>> It will be good to update the test to prove that.
>>>>
>>>> On 17/12/15 10:21, Avik Niyogi wrote:
>>>>>
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Kindly review the fix for JDK9.
>>>>> *Bug*:https://bugs.openjdk.java.net/browse/JDK-8041894
>>>>>
>>>>> *Webrev*:http://cr.openjdk.java.net/~aniyogi/8041894/webrev.00/
>>>>>
>>>>> *Issue*: Test case throws an exception as subcomponents of were not
>>>>> getting orientation
>>>>> property assignment.
>>>>>
>>>>> *Cause*: The case where property name as Component orientation not
>>>>> present to traverse
>>>>> the property to subcomponents of spinner for Aqua look and feel.
>>>>>
>>>>> *Fix*: The else if clause for this property name was added while
>>>>> checking for for editor to
>>>>> take charge of applying the component orientation to all subsequent
>>>>> subcomponents.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From rajeev.chamyal at oracle.com  Tue Jan 12 14:28:39 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 12 Jan 2016 06:28:39 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8075084
 JOptionPane.showMessageDialog causes JScrollBar to move
In-Reply-To: <6a9ba228-fbfb-41d8-bb59-01f98f449a0a@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>
Message-ID: <3396fa45-2f9d-4c1b-8d4c-dc30e1ce751e@default>

Hello All,

Gentle reminder to review the fix.
http://cr.openjdk.java.net/~rchamyal/8075084/webrev.02/


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 alexandr.scherbatiy at oracle.com  Tue Jan 12 17:53:00 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 12 Jan 2016 21:53:00 +0400
Subject: <Swing Dev> Review request for 8041894: Test
 javax/swing/JSpinner/8008657/bug8008657.java failed on Mac
In-Reply-To: <56950566.2090806@oracle.com>
References: <D47FB485-40D8-4C2D-9F78-499E79A0A1C5@oracle.com>
	<567493EC.6030304@oracle.com>
	<3AF15B6F-06D6-4E4A-B8C8-EB68A4DF0379@oracle.com>
	<56813AB4.2070503@oracle.com>
	<F6AB5612-764C-4900-92C1-DA8D35CD3F74@oracle.com>
	<56950566.2090806@oracle.com>
Message-ID: <56953D7C.7000401@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 12/01/16 17:53, Sergey Bylokhov wrote:
> Looks fine.
>
> On 04/01/16 12:41, Avik Niyogi wrote:
>> Hi All,
>> Please review the following incorporated with inputs provided
>> http://cr.openjdk.java.net/~aniyogi/8041894/webrev.01/
>>
>> With Regards,
>> Avik Niyogi
>>> On 28-Dec-2015, at 7:05 pm, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>
>>> Hi, Avik
>>> On 21/12/15 07:17, Avik Niyogi wrote:
>>>> Hi Sergey,
>>>> I verified that the issue is only with Aqua Look and feel and not 
>>>> other
>>>> look and feels.
>>>
>>> It will be better to prove it in the test, so the bug will not occur
>>> again in some other/new L&F.
>>>
>>>> The type cast for ComponentOrientation was done in the code just 
>>>> for two
>>>> reasons:
>>>> 1) User readability for the component within the event e.
>>>> 2) The cast for which type it is specified. For example, it can be 
>>>> noted
>>>> that in the older code,
>>>
>>> This is unrelated to the code style. The cases which you selected are
>>> necessary because we pass these values to the replaceEditor(), note
>>> that parameters of replaceEditor are JComponent, so we must cast in
>>> these cases. Same for (ComponentOrientation) e.getNewValue() because
>>> we pass it to applyComponentOrientation(ComponentOrientation), but in
>>> case of getOldValue it is not necessary because we compare it to null
>>> only.
>>>
>>> Also please do not remove the empty line before package com.apple.laf;
>>>
>>>>
>>>> if ("editor".equals(propertyName)) {
>>>>                     final JComponent oldEditor = *(JComponent)*
>>>> e.getOldValue();
>>>>                     final JComponent newEditor = *(JComponent)*
>>>> e.getNewValue();
>>>>                     ui.replaceEditor(oldEditor, newEditor);
>>>>                     ui.updateEnabledState();
>>>>                 } else if 
>>>> ("componentOrientation".equals(propertyName)) {
>>>>                     ComponentOrientation o
>>>>                             = (ComponentOrientation) e.getNewValue();
>>>>                     if (o != (ComponentOrientation) e.getOldValue()) {
>>>>                         JComponent editor = spinner.getEditor();
>>>>                         if (editor != null) {
>>>> editor.applyComponentOrientation(o);
>>>>                         }
>>>>                         spinner.revalidate();
>>>>                         spinner.repaint();
>>>>                     }
>>>> Casting of JComponent is done explicitly for the values there.
>>>> Maintaining same standard
>>>> and scoping out uncertainty seems correct in the context.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>
>>>>> On 19-Dec-2015, at 4:47 am, Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com
>>>>> <mailto:Sergey.Bylokhov at oracle.com><mailto:Sergey.Bylokhov at oracle.com>> 
>>>>>
>>>>> wrote:
>>>>>
>>>>> Hi, Avik.
>>>>> Looks fine to me. It seems that the cast here is not necessary?
>>>>> if (o != (ComponentOrientation) e.getOldValue())
>>>>>
>>>>> Can you confirm that this bug not affectes our other looks and feels?
>>>>> It will be good to update the test to prove that.
>>>>>
>>>>> On 17/12/15 10:21, Avik Niyogi wrote:
>>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Kindly review the fix for JDK9.
>>>>>> *Bug*:https://bugs.openjdk.java.net/browse/JDK-8041894
>>>>>>
>>>>>> *Webrev*:http://cr.openjdk.java.net/~aniyogi/8041894/webrev.00/
>>>>>>
>>>>>> *Issue*: Test case throws an exception as subcomponents of were not
>>>>>> getting orientation
>>>>>> property assignment.
>>>>>>
>>>>>> *Cause*: The case where property name as Component orientation not
>>>>>> present to traverse
>>>>>> the property to subcomponents of spinner for Aqua look and feel.
>>>>>>
>>>>>> *Fix*: The else if clause for this property name was added while
>>>>>> checking for for editor to
>>>>>> take charge of applying the component orientation to all subsequent
>>>>>> subcomponents.
>>>>>>
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>



From alexandr.scherbatiy at oracle.com  Tue Jan 12 18:19:17 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 12 Jan 2016 22:19:17 +0400
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <DAD2ACAB-5640-40E4-89B2-B1256EB53A5B@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>
Message-ID: <569543A5.7040109@oracle.com>


- 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/>
>
> 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>> 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/
>>> 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>> 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/>
>>>>>
>>>>> *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
>>>>
>>>
>>
>

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

From alexandr.scherbatiy at oracle.com  Tue Jan 12 19:03:25 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 12 Jan 2016 23:03:25 +0400
Subject: <Swing Dev> RfR JDK-8145735,
 Tests api/javax_swing/JTabbedPane/AccessibleJTabbedPane/* are
 failing
In-Reply-To: <569422EA.7030501@oracle.com>
References: <569422EA.7030501@oracle.com>
Message-ID: <56954DFD.4090200@oracle.com>


It seems that there still is the case when tab titles are empty string, 
tab components are null, components are not null and the correct index 
should be returned for the given page.

May be it is better to replace searching the page index by tab component 
to by component?
We already do this in the getTitle() method.

Thanks,
Alexandr.

On 12/01/16 01:47, Pete Brunet wrote:
> Please review this patch:
>
> http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.00/
>
> The issue being resolved is that the JTabbedPane code can't solely rely
> on tabComponent when fetching the index in the parent component.
> tabComponent is optionally used and its presence indicates that the
> associated Component will render the tab title; otherwise the
> JTabbedPane tab will.  In those cases where tabComponent is used, if it
> is null then the tab's title must be used when determining the index in
> parent, i.e. parent.indexofTab(getTitle()) vs
> parent.indexOfTabComponent(tabComponent).
>
> The regression test was improved to catch the cases where the fix to
> JTabbedPane was not applied.  The regression test was also changed so
> the exception message is more cleanly displayed when the test fails.



From philip.race at oracle.com  Tue Jan 12 19:42:39 2016
From: philip.race at oracle.com (Philip Race)
Date: Tue, 12 Jan 2016 11:42:39 -0800
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5694F0C3.8020203@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>
Message-ID: <5695572F.6070709@oracle.com>

@since needs to be just "9" as of the updated verona versioning scheme.

-phil.

On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
> Hi Alexander,
>
> I see that you've added the next clarifications to the methods specs:
>
> > draws string/returns width ... using text properties and 
> anti-aliasing hints from the provided component
>
> It still seems too brief and even incorrect for getStringWidth().
>
> For drawString():
>
> For non-printing case I would write:
>
> Sets the anti-aliasing rendering hints to the Graphics object if those 
> are specified in the component properties. Then the string is drawn 
> using the provided Graphics object with the numeric shaper taken into 
> account if it is defined for the component.
>
> Please consider the printing case...
>
> For getStringWidth():
>
> Did not get which anti-aliasing hints it takes into account while 
> there is no Graphics in the params list...
> On the contrary, it does not take into account the rendering context.
> My suggestion:
>
> Returns string pixel width by the provided font metrics and according 
> to the numeric shaper if it is defined for the component.
>
> --Semyon
>
> For
> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>
>>  Hello,
>>
>>  Could you review the updated fix:
>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>
>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>> Hi Alexandr,
>>>
>>> I suggest using {@code underlinedIndex} in this sentence:
>>>
>>> * The {@code underlinedIndex} parameter points to a char value 
>>> (Unicode code unit) in the
>>> * given string.
>>>
>>> in the Javadoc for drawStringUnderlineCharAt().
>>>
>>>
>>> And I suggest using "fits" instead of "can fit" in @return for 
>>> getClippedString() and rephrasing the conditions where empty string 
>>> is returned:
>>>
>>> * @return the clipped string that fits in the provided space, an empty
>>> *         string if the given string argument is {@code null} or empty.
>>
>>    The fix is updated according to the provided comments.
>>
>>    Thanks,
>>    Alexandr.
>>>
>>>
>>> Regards,
>>> Alexey
>>>
>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>> Hello,
>>>>
>>>> Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>
>>>> - methods description is updated to mention used text properties 
>>>> and anti-aliasing hints from the provided component
>>>> - the drawStringUnderlineCharAt method description is updated
>>>> - @since tag is added for the drawString() method
>>>> - the description that some parameters may/must not be null is added
>>>> - the test is updated to call the methods on EDT
>>>> - the test is updated to check passed null arguments
>>>>
>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>> Hi Alexandr,
>>>>>
>>>>> Shouldn't drawString() also have @since tag?
>>>>>
>>>>>
>>>>> Could you please also clarify whether underlinedIndex in 
>>>>> drawStringUnderlineCharAt refers to the char index in the string?
>>>>>
>>>>> The statement
>>>>> * The underlined index refers to char values (Unicode code units).
>>>>> makes it unclear: underlinedIndex is an *index* or a *char* 
>>>>> (Unicode code point).
>>>>
>>>>  I updated it to "The underlined index points to a char value 
>>>> (Unicode code unit) in the given string."
>>>>  The 'refers' word was used for a value at the given index.
>>>>  However, I am not sure that the new variant is better.
>>>>>
>>>>>
>>>>> * Nothing is drawn for null string. No character is underlined for 
>>>>> the
>>>>> * index {@code < 0}, {@code >=} than the string width or if the 
>>>>> char value
>>>>> * specified at the given index is in the low-surrogate range.
>>>>>
>>>>> I think it will be better to spell comparison operators, I mean to 
>>>>> use  "greater than" rather than ">=". And "length" must be used 
>>>>> instead of "width".
>>>>>
>>>>> I propose the following text:
>>>>>
>>>>> No character is underlined if the index is negative or greater 
>>>>> than the string length or if the char value specified at the given 
>>>>> index is in the low-surrogate range.
>>>>>
>>>>> For the first part of condition, you can add clarification in 
>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>  Updated.
>>>>>
>>>>>
>>>>> For consistency, please remove the full stop in @return tag in 
>>>>> description of getClippedString.
>>>>
>>>> Updated.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>
>>>>>> The javadoc references for the #drawStringUnderlineCharAt and 
>>>>>> #getClippedString methods are moved after parameters description.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>
>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>
>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with 
>>>>>>> chars that have
>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>> The whole glyph is underlined.
>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>
>>>>>>> The char value specified the the underlined index should point 
>>>>>>> to the high-surrogate range of a supplementary character.
>>>>>>> I updated the javadoc for the 
>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>> -----------------------------
>>>>>>> /**
>>>>>>> * Draws the given string at the specified location underlining
>>>>>>> * the specified character.
>>>>>>> * <p>
>>>>>>> * The underlined index refers to char values (Unicode code units).
>>>>>>> * If the char value specified at the given underlined index is in
>>>>>>> * the high-surrogate range and the char value at the following 
>>>>>>> index is in
>>>>>>> * the low-surrogate range then the supplementary character 
>>>>>>> corresponding
>>>>>>> * to this surrogate pair is underlined.
>>>>>>> * <p>
>>>>>>> * Nothing is drawn for null string. No character is underlined 
>>>>>>> for the
>>>>>>> * index {@code < 0}, {@code >=} than the string width or if the 
>>>>>>> char value
>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>> -----------------------------
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>> I don't remember or know how Swing resolves this but the 
>>>>>>>>> measurement ones
>>>>>>>>> are not reliable since they do not take a Graphics context, so 
>>>>>>>>> you cannot
>>>>>>>>> measure the string properly. You need a FontRenderContext to 
>>>>>>>>> measure.
>>>>>>>>
>>>>>>>> The provided methods use 
>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method which 
>>>>>>>> returns the FontRenderContext associated with the component.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> So as it stands these APIs do not appear suitable to be made 
>>>>>>>>> public as they
>>>>>>>>> are not reliable.
>>>>>>>>>
>>>>>>>>> Whilst I could look at the code, if I instead just look at the 
>>>>>>>>> API, I am scratching my
>>>>>>>>> head over :-
>>>>>>>>>
>>>>>>>>> public static void drawString(JComponent c, Graphics g, String 
>>>>>>>>> text, int x, int y)
>>>>>>>>>
>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>> So I am supposing that there is optional information that may 
>>>>>>>>> be pulled from the
>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>
>>>>>>>> The optional information provided by the component is:
>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>> - antialiasing hints
>>>>>>>>
>>>>>>>>>
>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if the 
>>>>>>>>> index is code point
>>>>>>>>> or UTF16 char index and what happens if there is not 1:1 code 
>>>>>>>>> point:glyph mapping.
>>>>>>>> I will update this.
>>>>>>>>>
>>>>>>>>> Are we sure that (any of) these really ought/need to be public 
>>>>>>>>> - particularly given the
>>>>>>>>> resolution of https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>
>>>>>>>> These methods are used by JDK L&Fs to draw text. The initial 
>>>>>>>> request was to provide public methods that can be used by a 
>>>>>>>> custom L&F to draw strings consistently with other L&Fs.
>>>>>>>>
>>>>>>>> They are also designed to properly render text for printing. To 
>>>>>>>> do that they use call to internal ProxyPrintGraphics class to 
>>>>>>>> obtain the print graphics context.
>>>>>>>>
>>>>>>>> Even if printing staff will be public, these methods are just 
>>>>>>>> utility methods (in the same way as other text methods in the 
>>>>>>>> javax.swing.text.Utilities class) that help easily to draw and 
>>>>>>>> print text in the same way as JDK L&Fs do that.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you review the fix:
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>
>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt, 
>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160112/1b3e4a0b/attachment.html>

From peter.brunet at oracle.com  Tue Jan 12 22:12:30 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 12 Jan 2016 16:12:30 -0600
Subject: <Swing Dev> RfR JDK-8145735,
 Tests api/javax_swing/JTabbedPane/AccessibleJTabbedPane/* are
 failing
In-Reply-To: <56954DFD.4090200@oracle.com>
References: <569422EA.7030501@oracle.com> <56954DFD.4090200@oracle.com>
Message-ID: <56957A4E.3060006@oracle.com>

Hi Alexandr,

On 1/12/16 1:03 PM, Alexander Scherbatiy wrote:
>
> It seems that there still is the case when tab titles are empty
> string, tab components are null, components are not null and the
> correct index should be returned for the given page.
In the code of the current webrev (webrev.00) if the tab component is
null then getTitle() is the fallback and it uses
parent.indexOfComponent().  I tested using add("", myPanel) and that
worked OK.
>
> May be it is better to replace searching the page index by tab
> component to by component?
> We already do this in the getTitle() method.
In any event, are you suggesting just always using
parent.indexOfComponent(), i.e. always using getTitle()?  The regression
test runs OK with that change.  Is there a case where indexOfComponent
would not work but indexOfTabComponent would?

Pete
>
> Thanks,
> Alexandr.
>
> On 12/01/16 01:47, Pete Brunet wrote:
>> Please review this patch:
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.00/
>>
>> The issue being resolved is that the JTabbedPane code can't solely rely
>> on tabComponent when fetching the index in the parent component.
>> tabComponent is optionally used and its presence indicates that the
>> associated Component will render the tab title; otherwise the
>> JTabbedPane tab will.  In those cases where tabComponent is used, if it
>> is null then the tab's title must be used when determining the index in
>> parent, i.e. parent.indexofTab(getTitle()) vs
>> parent.indexOfTabComponent(tabComponent).
>>
>> The regression test was improved to catch the cases where the fix to
>> JTabbedPane was not applied.  The regression test was also changed so
>> the exception message is more cleanly displayed when the test fails.
>



From avik.niyogi at oracle.com  Wed Jan 13 06:20:23 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 13 Jan 2016 11:50:23 +0530
Subject: <Swing Dev> Review request for 8041894: Test
	javax/swing/JSpinner/8008657/bug8008657.java failed on Mac
In-Reply-To: <56953D7C.7000401@oracle.com>
References: <D47FB485-40D8-4C2D-9F78-499E79A0A1C5@oracle.com>
	<567493EC.6030304@oracle.com>
	<3AF15B6F-06D6-4E4A-B8C8-EB68A4DF0379@oracle.com>
	<56813AB4.2070503@oracle.com>
	<F6AB5612-764C-4900-92C1-DA8D35CD3F74@oracle.com>
	<56950566.2090806@oracle.com> <56953D7C.7000401@oracle.com>
Message-ID: <0FD2E266-C31C-4D34-979C-7451B8138830@oracle.com>

Hi All,
Thank you for the reviews. Kindly request to commit the changes for the same.
With Regards,
Avik Niyogi

> On 12-Jan-2016, at 11:23 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 12/01/16 17:53, Sergey Bylokhov wrote:
>> Looks fine.
>> 
>> On 04/01/16 12:41, Avik Niyogi wrote:
>>> Hi All,
>>> Please review the following incorporated with inputs provided
>>> http://cr.openjdk.java.net/~aniyogi/8041894/webrev.01/
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 28-Dec-2015, at 7:05 pm, Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>> 
>>>> Hi, Avik
>>>> On 21/12/15 07:17, Avik Niyogi wrote:
>>>>> Hi Sergey,
>>>>> I verified that the issue is only with Aqua Look and feel and not other
>>>>> look and feels.
>>>> 
>>>> It will be better to prove it in the test, so the bug will not occur
>>>> again in some other/new L&F.
>>>> 
>>>>> The type cast for ComponentOrientation was done in the code just for two
>>>>> reasons:
>>>>> 1) User readability for the component within the event e.
>>>>> 2) The cast for which type it is specified. For example, it can be noted
>>>>> that in the older code,
>>>> 
>>>> This is unrelated to the code style. The cases which you selected are
>>>> necessary because we pass these values to the replaceEditor(), note
>>>> that parameters of replaceEditor are JComponent, so we must cast in
>>>> these cases. Same for (ComponentOrientation) e.getNewValue() because
>>>> we pass it to applyComponentOrientation(ComponentOrientation), but in
>>>> case of getOldValue it is not necessary because we compare it to null
>>>> only.
>>>> 
>>>> Also please do not remove the empty line before package com.apple.laf;
>>>> 
>>>>> 
>>>>> if ("editor".equals(propertyName)) {
>>>>>                    final JComponent oldEditor = *(JComponent)*
>>>>> e.getOldValue();
>>>>>                    final JComponent newEditor = *(JComponent)*
>>>>> e.getNewValue();
>>>>>                    ui.replaceEditor(oldEditor, newEditor);
>>>>>                    ui.updateEnabledState();
>>>>>                } else if ("componentOrientation".equals(propertyName)) {
>>>>>                    ComponentOrientation o
>>>>>                            = (ComponentOrientation) e.getNewValue();
>>>>>                    if (o != (ComponentOrientation) e.getOldValue()) {
>>>>>                        JComponent editor = spinner.getEditor();
>>>>>                        if (editor != null) {
>>>>> editor.applyComponentOrientation(o);
>>>>>                        }
>>>>>                        spinner.revalidate();
>>>>>                        spinner.repaint();
>>>>>                    }
>>>>> Casting of JComponent is done explicitly for the values there.
>>>>> Maintaining same standard
>>>>> and scoping out uncertainty seems correct in the context.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>> 
>>>>>> On 19-Dec-2015, at 4:47 am, Sergey Bylokhov
>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>> <mailto:Sergey.Bylokhov at oracle.com><mailto:Sergey.Bylokhov at oracle.com>> 
>>>>>> wrote:
>>>>>> 
>>>>>> Hi, Avik.
>>>>>> Looks fine to me. It seems that the cast here is not necessary?
>>>>>> if (o != (ComponentOrientation) e.getOldValue())
>>>>>> 
>>>>>> Can you confirm that this bug not affectes our other looks and feels?
>>>>>> It will be good to update the test to prove that.
>>>>>> 
>>>>>> On 17/12/15 10:21, Avik Niyogi wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Kindly review the fix for JDK9.
>>>>>>> *Bug*:https://bugs.openjdk.java.net/browse/JDK-8041894
>>>>>>> 
>>>>>>> *Webrev*:http://cr.openjdk.java.net/~aniyogi/8041894/webrev.00/
>>>>>>> 
>>>>>>> *Issue*: Test case throws an exception as subcomponents of were not
>>>>>>> getting orientation
>>>>>>> property assignment.
>>>>>>> 
>>>>>>> *Cause*: The case where property name as Component orientation not
>>>>>>> present to traverse
>>>>>>> the property to subcomponents of spinner for Aqua look and feel.
>>>>>>> 
>>>>>>> *Fix*: The else if clause for this property name was added while
>>>>>>> checking for for editor to
>>>>>>> take charge of applying the component orientation to all subsequent
>>>>>>> subcomponents.
>>>>>>> 
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Best regards, Sergey.
>>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Best regards, Sergey.
>>> 
>> 
>> 
> 



From avik.niyogi at oracle.com  Wed Jan 13 06:27:20 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 13 Jan 2016 11:57:20 +0530
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
	behaviour doesn't comply API documentation
	(setComponentOrientation method), Aqua LAF
In-Reply-To: <5695047D.3050701@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
	<7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
	<5695047D.3050701@oracle.com>
Message-ID: <8FE44E53-E991-4629-8DD0-86703A373A65@oracle.com>

Hi Sergey,
If fFileList refers to a soft linked empty folder, we will  will not need to apply orientation to it?s sub-components.

With Regards,
Avik Niyogi

> On 12-Jan-2016, at 7:19 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Avik.
> Is it possible that fFileList can be null? I see that in other places we do not check it to null?
> 
> On 04/01/16 11:52, Avik Niyogi wrote:
>> Hi All,
>> 
>> Please review the webrev.01 :
>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/>
>> incorporated with the inputs received.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 28-Dec-2015, at 10:23 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 Alexandr,
>>> 
>>> Automated test may fail based on folder contents on individual systems
>>> irrespective of the fix directly not depending on the same.
>>> Also, to confirm this fix, it will need visual confirmation and hence,
>>> no automated test was provided.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 23-Dec-2015, at 7:32 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.
>>>> 
>>>>  Is it possible to write an automated test for the fix?
>>>> 
>>>>  Thanks,
>>>>  Alexandr.
>>>> 
>>>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the bug fix for JDK 9.
>>>>> 
>>>>> *Bug:*
>>>>> https://bugs.openjdk.java.net/browse/JDK-8016665 <https://bugs.openjdk.java.net/browse/JDK-8016665>
>>>>> 
>>>>> *Webrev:*
>>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/>
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>>
>>>>> 
>>>>> *Issue:*
>>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>>> in testsuite fails.
>>>>> 
>>>>> *Cause:*
>>>>> Due to not honouring of RIGHT_TO_LEFT parameter for setOrientation
>>>>> method applied for a JFileChooser for the AquaLookAndFeel only,
>>>>> the fileChooser does not get displayed in RIGHT_TO_LEFT orientation.
>>>>> This issue was verified to exist only in AquaLookAndFeel for
>>>>> JFileChooser only due to wrong implementation in AquaFileSystemModel.
>>>>> Also, as provided in comments: "The Aqua LAF must support the RTL
>>>>> orientation of JFileChooser."
>>>>> 
>>>>> *Fix:*
>>>>> Added implementation for the check of RIGHT_TO_LEFT
>>>>> ComponentOrientation and verified with test suite.
>>>>> 
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.

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

From avik.niyogi at oracle.com  Wed Jan 13 06:28:42 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 13 Jan 2016 11:58:42 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <569543A5.7040109@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>
Message-ID: <B2381901-6398-4C69-8077-1144175E461C@oracle.com>

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/~aniyogi/8015748/webrev.03/>

With Regards,
Avik Niyogi
> On 12-Jan-2016, at 11:49 pm, Alexander Scherbatiy <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 <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/>
>> 
>> 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>> 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/>
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 23-Dec-2015, at 7:29 pm, Alexander Scherbatiy < <mailto:alexandr.scherbatiy at oracle.com>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 <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/>
>>>>>> 
>>>>>> 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>http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/7/swing <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
>>>>> 
>>>> 
>>> 
>> 
> 

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

From rajeev.chamyal at oracle.com  Wed Jan 13 11:06:35 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 13 Jan 2016 03:06:35 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8139213 : Mac OS X Aqua Look and
 Feel: JOptionPane can truncate the first button.
Message-ID: <567b8957-bded-44ad-83de-65e16a529910@default>

Hello All,

Please review the following fix for Jdk9:

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

Issue : In Mac OS X Aqua LAF JOptionPane truncates the first button if multiple buttons are added to it.

Cause: AquaButtonAreaLayout class is not overriding base class method minimumLayoutSize as a result it is not taking to account the default button width for Aqua LAF.
Hence it is calculating incorrect dimensions for JOptionPane which results in truncation of button.

Fix: Overriding minimumLayoutSize in AquaButtonAreaLayout to consider default button width and height while calculating minimum size for JOptionPane.

Regards,
Rajeev Chamyal


From alexandr.scherbatiy at oracle.com  Wed Jan 13 13:16:53 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 Jan 2016 16:16:53 +0300
Subject: <Swing Dev> RfR JDK-8145735,
 Tests api/javax_swing/JTabbedPane/AccessibleJTabbedPane/* are
 failing
In-Reply-To: <56957A4E.3060006@oracle.com>
References: <569422EA.7030501@oracle.com> <56954DFD.4090200@oracle.com>
	<56957A4E.3060006@oracle.com>
Message-ID: <56964E45.7090002@oracle.com>

On 1/13/2016 1:12 AM, Pete Brunet wrote:
> Hi Alexandr,
>
> On 1/12/16 1:03 PM, Alexander Scherbatiy wrote:
>> It seems that there still is the case when tab titles are empty
>> string, tab components are null, components are not null and the
>> correct index should be returned for the given page.
> In the code of the current webrev (webrev.00) if the tab component is
> null then getTitle() is the fallback and it uses
> parent.indexOfComponent().  I tested using add("", myPanel) and that
> worked OK.
>> May be it is better to replace searching the page index by tab
>> component to by component?
>> We already do this in the getTitle() method.
> In any event, are you suggesting just always using
> parent.indexOfComponent(), i.e. always using getTitle()?  The regression
> test runs OK with that change.  Is there a case where indexOfComponent
> would not work but indexOfTabComponent would?
   There is a possible case that  a component is null, title is empty 
but a tabComponent is not null.
   May be it is better to have a method like getPageIndex() which search 
the page index by component if it is not null, then by tabComponent and 
by title at the last.

   Thanks,
   Alexandr.

>
> Pete
>> Thanks,
>> Alexandr.
>>
>> On 12/01/16 01:47, Pete Brunet wrote:
>>> Please review this patch:
>>>
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.00/
>>>
>>> The issue being resolved is that the JTabbedPane code can't solely rely
>>> on tabComponent when fetching the index in the parent component.
>>> tabComponent is optionally used and its presence indicates that the
>>> associated Component will render the tab title; otherwise the
>>> JTabbedPane tab will.  In those cases where tabComponent is used, if it
>>> is null then the tab's title must be used when determining the index in
>>> parent, i.e. parent.indexofTab(getTitle()) vs
>>> parent.indexOfTabComponent(tabComponent).
>>>
>>> The regression test was improved to catch the cases where the fix to
>>> JTabbedPane was not applied.  The regression test was also changed so
>>> the exception message is more cleanly displayed when the test fails.



From alexandr.scherbatiy at oracle.com  Wed Jan 13 13:32:03 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 Jan 2016 16:32:03 +0300
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <B2381901-6398-4C69-8077-1144175E461C@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>
Message-ID: <569651D3.4080604@oracle.com>

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/>
>

   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>> 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/>
>>>
>>> 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>> 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/
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>
>>>>>> On 23-Dec-2015, at 7:29 pm, Alexander Scherbatiy 
>>>>>> <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/>
>>>>>>>
>>>>>>> *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
>>>>>>
>>>>>
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Wed Jan 13 15:03:12 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 Jan 2016 18:03:12 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5695572F.6070709@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>
Message-ID: <56966730.7000701@oracle.com>


   Hello,

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

   - the methods description are updated to mention a component numeric 
shaper and non-print graphics context
   - @since tag value is updated to 9

  Thanks,
  Alexandr.

On 1/12/2016 10:42 PM, Philip Race wrote:
> @since needs to be just "9" as of the updated verona versioning scheme.
>
> -phil.
>
> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>> Hi Alexander,
>>
>> I see that you've added the next clarifications to the methods specs:
>>
>> > draws string/returns width ... using text properties and 
>> anti-aliasing hints from the provided component
>>
>> It still seems too brief and even incorrect for getStringWidth().
>>
>> For drawString():
>>
>> For non-printing case I would write:
>>
>> Sets the anti-aliasing rendering hints to the Graphics object if 
>> those are specified in the component properties. Then the string is 
>> drawn using the provided Graphics object with the numeric shaper 
>> taken into account if it is defined for the component.
>>
>> Please consider the printing case...
>>
>> For getStringWidth():
>>
>> Did not get which anti-aliasing hints it takes into account while 
>> there is no Graphics in the params list...
>> On the contrary, it does not take into account the rendering context.
>> My suggestion:
>>
>> Returns string pixel width by the provided font metrics and according 
>> to the numeric shaper if it is defined for the component.
>>
>> --Semyon
>>
>> For
>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>
>>>  Hello,
>>>
>>>  Could you review the updated fix:
>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>
>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>> Hi Alexandr,
>>>>
>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>
>>>> * The {@code underlinedIndex} parameter points to a char value 
>>>> (Unicode code unit) in the
>>>> * given string.
>>>>
>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>
>>>>
>>>> And I suggest using "fits" instead of "can fit" in @return for 
>>>> getClippedString() and rephrasing the conditions where empty string 
>>>> is returned:
>>>>
>>>> * @return the clipped string that fits in the provided space, an empty
>>>> *         string if the given string argument is {@code null} or 
>>>> empty.
>>>
>>>    The fix is updated according to the provided comments.
>>>
>>>    Thanks,
>>>    Alexandr.
>>>>
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>> Hello,
>>>>>
>>>>> Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>
>>>>> - methods description is updated to mention used text properties 
>>>>> and anti-aliasing hints from the provided component
>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>> - @since tag is added for the drawString() method
>>>>> - the description that some parameters may/must not be null is added
>>>>> - the test is updated to call the methods on EDT
>>>>> - the test is updated to check passed null arguments
>>>>>
>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>> Hi Alexandr,
>>>>>>
>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>
>>>>>>
>>>>>> Could you please also clarify whether underlinedIndex in 
>>>>>> drawStringUnderlineCharAt refers to the char index in the string?
>>>>>>
>>>>>> The statement
>>>>>> * The underlined index refers to char values (Unicode code units).
>>>>>> makes it unclear: underlinedIndex is an *index* or a *char* 
>>>>>> (Unicode code point).
>>>>>
>>>>>  I updated it to "The underlined index points to a char value 
>>>>> (Unicode code unit) in the given string."
>>>>>  The 'refers' word was used for a value at the given index.
>>>>>  However, I am not sure that the new variant is better.
>>>>>>
>>>>>>
>>>>>> * Nothing is drawn for null string. No character is underlined 
>>>>>> for the
>>>>>> * index {@code < 0}, {@code >=} than the string width or if the 
>>>>>> char value
>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>
>>>>>> I think it will be better to spell comparison operators, I mean 
>>>>>> to use  "greater than" rather than ">=". And "length" must be 
>>>>>> used instead of "width".
>>>>>>
>>>>>> I propose the following text:
>>>>>>
>>>>>> No character is underlined if the index is negative or greater 
>>>>>> than the string length or if the char value specified at the 
>>>>>> given index is in the low-surrogate range.
>>>>>>
>>>>>> For the first part of condition, you can add clarification in 
>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>  Updated.
>>>>>>
>>>>>>
>>>>>> For consistency, please remove the full stop in @return tag in 
>>>>>> description of getClippedString.
>>>>>
>>>>> Updated.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alexey
>>>>>>
>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>
>>>>>>> The javadoc references for the #drawStringUnderlineCharAt and 
>>>>>>> #getClippedString methods are moved after parameters description.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>>
>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>
>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with 
>>>>>>>> chars that have
>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>>> The whole glyph is underlined.
>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>>
>>>>>>>> The char value specified the the underlined index should point 
>>>>>>>> to the high-surrogate range of a supplementary character.
>>>>>>>> I updated the javadoc for the 
>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>> -----------------------------
>>>>>>>> /**
>>>>>>>> * Draws the given string at the specified location underlining
>>>>>>>> * the specified character.
>>>>>>>> * <p>
>>>>>>>> * The underlined index refers to char values (Unicode code units).
>>>>>>>> * If the char value specified at the given underlined index is in
>>>>>>>> * the high-surrogate range and the char value at the following 
>>>>>>>> index is in
>>>>>>>> * the low-surrogate range then the supplementary character 
>>>>>>>> corresponding
>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>> * <p>
>>>>>>>> * Nothing is drawn for null string. No character is underlined 
>>>>>>>> for the
>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if the 
>>>>>>>> char value
>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>> -----------------------------
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>> I don't remember or know how Swing resolves this but the 
>>>>>>>>>> measurement ones
>>>>>>>>>> are not reliable since they do not take a Graphics context, 
>>>>>>>>>> so you cannot
>>>>>>>>>> measure the string properly. You need a FontRenderContext to 
>>>>>>>>>> measure.
>>>>>>>>>
>>>>>>>>> The provided methods use 
>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method which 
>>>>>>>>> returns the FontRenderContext associated with the component.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So as it stands these APIs do not appear suitable to be made 
>>>>>>>>>> public as they
>>>>>>>>>> are not reliable.
>>>>>>>>>>
>>>>>>>>>> Whilst I could look at the code, if I instead just look at 
>>>>>>>>>> the API, I am scratching my
>>>>>>>>>> head over :-
>>>>>>>>>>
>>>>>>>>>> public static void drawString(JComponent c, Graphics g, 
>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>
>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>> So I am supposing that there is optional information that may 
>>>>>>>>>> be pulled from the
>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>
>>>>>>>>> The optional information provided by the component is:
>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>> - antialiasing hints
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if 
>>>>>>>>>> the index is code point
>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1 code 
>>>>>>>>>> point:glyph mapping.
>>>>>>>>> I will update this.
>>>>>>>>>>
>>>>>>>>>> Are we sure that (any of) these really ought/need to be 
>>>>>>>>>> public - particularly given the
>>>>>>>>>> resolution of https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>
>>>>>>>>> These methods are used by JDK L&Fs to draw text. The initial 
>>>>>>>>> request was to provide public methods that can be used by a 
>>>>>>>>> custom L&F to draw strings consistently with other L&Fs.
>>>>>>>>>
>>>>>>>>> They are also designed to properly render text for printing. 
>>>>>>>>> To do that they use call to internal ProxyPrintGraphics class 
>>>>>>>>> to obtain the print graphics context.
>>>>>>>>>
>>>>>>>>> Even if printing staff will be public, these methods are just 
>>>>>>>>> utility methods (in the same way as other text methods in the 
>>>>>>>>> javax.swing.text.Utilities class) that help easily to draw and 
>>>>>>>>> print text in the same way as JDK L&Fs do that.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -phil.
>>>>>>>>>>
>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>
>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt, 
>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>



From alexandr.scherbatiy at oracle.com  Wed Jan 13 16:17:39 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 Jan 2016 19:17:39 +0300
Subject: <Swing Dev> Review request for JDK-8075084
 JOptionPane.showMessageDialog causes JScrollBar to move
In-Reply-To: <3396fa45-2f9d-4c1b-8d4c-dc30e1ce751e@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>
Message-ID: <569678A3.6090500@oracle.com>

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  Wed Jan 13 18:08:41 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Jan 2016 21:08:41 +0300
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
 behaviour doesn't comply API documentation (setComponentOrientation method),
 Aqua LAF
In-Reply-To: <8FE44E53-E991-4629-8DD0-86703A373A65@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
	<7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
	<5695047D.3050701@oracle.com>
	<8FE44E53-E991-4629-8DD0-86703A373A65@oracle.com>
Message-ID: <569692A9.8010709@oracle.com>

On 13/01/16 09:27, Avik Niyogi wrote:
> Hi Sergey,
> If fFileList refers to a soft linked empty folder, we will  will not
> need to apply orientation to it?s sub-components.
I didn't understand what "soft linked empty folder" means here =((

Just to clarify. In the fix you have this code:
   95             if (fFileList != null) {
   96                 fFileList.setComponentOrientation(o);
...
   98             }

Which means that fFileList can be null, but it is a final field in the 
AquaFileSystemModel and it is initialized in the 
AquaFileChooserUI.createList() to a non null value:

         fFileList = new JTableExtension();
.....
         model = new AquaFileSystemModel(fc, fFileList, fColumnNames);

Or am I missing something?

>
> With Regards,
> Avik Niyogi
>
>> On 12-Jan-2016, at 7:19 pm, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Avik.
>> Is it possible that fFileList can be null? I see that in other places
>> we do not check it to null?
>>
>> On 04/01/16 11:52, Avik Niyogi wrote:
>>> Hi All,
>>>
>>> Please review the webrev.01 :
>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/
>>> incorporated with the inputs received.
>>>
>>> With Regards,
>>> Avik Niyogi
>>>
>>>> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niyogi at oracle.com
>>>> <mailto:avik.niyogi at oracle.com>
>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>
>>>> Hi Alexandr,
>>>>
>>>> Automated test may fail based on folder contents on individual systems
>>>> irrespective of the fix directly not depending on the same.
>>>> Also, to confirm this fix, it will need visual confirmation and hence,
>>>> no automated test was provided.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 23-Dec-2015, at 7:32 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.
>>>>>
>>>>>  Is it possible to write an automated test for the fix?
>>>>>
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>>
>>>>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>
>>>>>> *Bug:*
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8016665
>>>>>>
>>>>>> *Webrev:*
>>>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>>>>>
>>>>>> *Issue:*
>>>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>>>> in testsuite fails.
>>>>>>
>>>>>> *Cause:*
>>>>>> Due to not honouring of RIGHT_TO_LEFT parameter for setOrientation
>>>>>> method applied for a JFileChooser for the AquaLookAndFeel only,
>>>>>> the fileChooser does not get displayed in RIGHT_TO_LEFT orientation.
>>>>>> This issue was verified to exist only in AquaLookAndFeel for
>>>>>> JFileChooser only due to wrong implementation in AquaFileSystemModel.
>>>>>> Also, as provided in comments: "The Aqua LAF must support the RTL
>>>>>> orientation of JFileChooser."
>>>>>>
>>>>>> *Fix:*
>>>>>> Added implementation for the check of RIGHT_TO_LEFT
>>>>>> ComponentOrientation and verified with test suite.
>>>>>>
>>>>>>
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>
>>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From peter.brunet at oracle.com  Wed Jan 13 21:06:18 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 13 Jan 2016 15:06:18 -0600
Subject: <Swing Dev> RfR JDK-8145735,
 Tests api/javax_swing/JTabbedPane/AccessibleJTabbedPane/* are
 failing
In-Reply-To: <56964E45.7090002@oracle.com>
References: <569422EA.7030501@oracle.com> <56954DFD.4090200@oracle.com>
	<56957A4E.3060006@oracle.com> <56964E45.7090002@oracle.com>
Message-ID: <5696BC4A.9060802@oracle.com>

How does this look?
http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.01/

Pete

On 1/13/16 7:16 AM, Alexander Scherbatiy wrote:
> On 1/13/2016 1:12 AM, Pete Brunet wrote:
>> Hi Alexandr,
>>
>> On 1/12/16 1:03 PM, Alexander Scherbatiy wrote:
>>> It seems that there still is the case when tab titles are empty
>>> string, tab components are null, components are not null and the
>>> correct index should be returned for the given page.
>> In the code of the current webrev (webrev.00) if the tab component is
>> null then getTitle() is the fallback and it uses
>> parent.indexOfComponent().  I tested using add("", myPanel) and that
>> worked OK.
>>> May be it is better to replace searching the page index by tab
>>> component to by component?
>>> We already do this in the getTitle() method.
>> In any event, are you suggesting just always using
>> parent.indexOfComponent(), i.e. always using getTitle()?  The regression
>> test runs OK with that change.  Is there a case where indexOfComponent
>> would not work but indexOfTabComponent would?
>   There is a possible case that  a component is null, title is empty
> but a tabComponent is not null.
>   May be it is better to have a method like getPageIndex() which
> search the page index by component if it is not null, then by
> tabComponent and by title at the last.
>
>   Thanks,
>   Alexandr.
>
>>
>> Pete
>>> Thanks,
>>> Alexandr.
>>>
>>> On 12/01/16 01:47, Pete Brunet wrote:
>>>> Please review this patch:
>>>>
>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.00/
>>>>
>>>> The issue being resolved is that the JTabbedPane code can't solely
>>>> rely
>>>> on tabComponent when fetching the index in the parent component.
>>>> tabComponent is optionally used and its presence indicates that the
>>>> associated Component will render the tab title; otherwise the
>>>> JTabbedPane tab will.  In those cases where tabComponent is used,
>>>> if it
>>>> is null then the tab's title must be used when determining the
>>>> index in
>>>> parent, i.e. parent.indexofTab(getTitle()) vs
>>>> parent.indexOfTabComponent(tabComponent).
>>>>
>>>> The regression test was improved to catch the cases where the fix to
>>>> JTabbedPane was not applied.  The regression test was also changed so
>>>> the exception message is more cleanly displayed when the test fails.
>



From avik.niyogi at oracle.com  Thu Jan 14 04:37:43 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 14 Jan 2016 10:07:43 +0530
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
	behaviour doesn't comply API documentation
	(setComponentOrientation method), Aqua LAF
In-Reply-To: <569692A9.8010709@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
	<7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
	<5695047D.3050701@oracle.com>
	<8FE44E53-E991-4629-8DD0-86703A373A65@oracle.com>
	<569692A9.8010709@oracle.com>
Message-ID: <2F0E2127-FFC0-4BB9-B982-9F28F08C8D5A@oracle.com>

Hi All,

Please find code changes incorporating changes as suggested by inputs provided:

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

With Regards,
Avik Niyogi

> On 13-Jan-2016, at 11:38 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 13/01/16 09:27, Avik Niyogi wrote:
>> Hi Sergey,
>> If fFileList refers to a soft linked empty folder, we will  will not
>> need to apply orientation to it?s sub-components.
> I didn't understand what "soft linked empty folder" means here =((
> 
> Just to clarify. In the fix you have this code:
>  95             if (fFileList != null) {
>  96                 fFileList.setComponentOrientation(o);
> ...
>  98             }
> 
> Which means that fFileList can be null, but it is a final field in the AquaFileSystemModel and it is initialized in the AquaFileChooserUI.createList() to a non null value:
> 
>        fFileList = new JTableExtension();
> .....
>        model = new AquaFileSystemModel(fc, fFileList, fColumnNames);
> 
> Or am I missing something?
> 
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 12-Jan-2016, at 7:19 pm, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>> 
>>> Hi, Avik.
>>> Is it possible that fFileList can be null? I see that in other places
>>> we do not check it to null?
>>> 
>>> On 04/01/16 11:52, Avik Niyogi wrote:
>>>> Hi All,
>>>> 
>>>> Please review the webrev.01 :
>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/
>>>> incorporated with the inputs received.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niyogi at oracle.com
>>>>> <mailto:avik.niyogi at oracle.com>
>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>> 
>>>>> Hi Alexandr,
>>>>> 
>>>>> Automated test may fail based on folder contents on individual systems
>>>>> irrespective of the fix directly not depending on the same.
>>>>> Also, to confirm this fix, it will need visual confirmation and hence,
>>>>> no automated test was provided.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>> On 23-Dec-2015, at 7:32 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.
>>>>>> 
>>>>>> Is it possible to write an automated test for the fix?
>>>>>> 
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>> 
>>>>>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>> 
>>>>>>> *Bug:*
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8016665
>>>>>>> 
>>>>>>> *Webrev:*
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>>>>>> 
>>>>>>> *Issue:*
>>>>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>>>>> in testsuite fails.
>>>>>>> 
>>>>>>> *Cause:*
>>>>>>> Due to not honouring of RIGHT_TO_LEFT parameter for setOrientation
>>>>>>> method applied for a JFileChooser for the AquaLookAndFeel only,
>>>>>>> the fileChooser does not get displayed in RIGHT_TO_LEFT orientation.
>>>>>>> This issue was verified to exist only in AquaLookAndFeel for
>>>>>>> JFileChooser only due to wrong implementation in AquaFileSystemModel.
>>>>>>> Also, as provided in comments: "The Aqua LAF must support the RTL
>>>>>>> orientation of JFileChooser."
>>>>>>> 
>>>>>>> *Fix:*
>>>>>>> Added implementation for the check of RIGHT_TO_LEFT
>>>>>>> ComponentOrientation and verified with test suite.
>>>>>>> 
>>>>>>> 
>>>>>>> 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/20160114/3588ca12/attachment.html>

From avik.niyogi at oracle.com  Thu Jan 14 04:49:57 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 14 Jan 2016 10:19:57 +0530
Subject: <Swing Dev> Review Request of 8146321: [macosx] JInternalFrame
	frame icon in wrong position on Mac L&F if icon is not ImageIcon
Message-ID: <431B2640-2D19-4EFC-824E-52AE3D25D2D8@oracle.com>

Hi All,

Kindly review the bug fix for JDK 9.

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

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

Issue:
Under the Mac Look&Feel, if an icon type other than an ImageIcon is used in JInternalFrame.setFrameIcon(),
the icon will show up in the wrong position. 

Cause:
the "instanceof Icon" was not checked for. Also, customs ImageIcon with color fill (and no image URL) which would 
have resulted in null value for resized ImageIcon image was not well handled.

Fix:
All places in Aqua LAF where "instanceof Icon? (and not just ImageIcon class) is required, 
inputs were added after significant analyses.
Check for null for getImage was done to remove a Null Pointer Exception.

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

From avik.niyogi at oracle.com  Thu Jan 14 05:18:15 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 14 Jan 2016 10:48:15 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <569651D3.4080604@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>
Message-ID: <A14D4B21-B5D3-4A08-BDB8-0956008BF208@oracle.com>

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/~aniyogi/8015748/webrev.04/>

With Regards,
Avik Niyogi
> On 13-Jan-2016, at 7:02 pm, Alexander Scherbatiy <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/>
>> 
> 
>  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>> 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/>
>>>> 
>>>> 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>> 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/
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>> 
>>>>>>> On 23-Dec-2015, at 7:29 pm, Alexander Scherbatiy <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/>
>>>>>>>> 
>>>>>>>> *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
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

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

From Sergey.Bylokhov at oracle.com  Thu Jan 14 06:02:13 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Jan 2016 09:02:13 +0300
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
 behaviour doesn't comply API documentation (setComponentOrientation method),
 Aqua LAF
In-Reply-To: <2F0E2127-FFC0-4BB9-B982-9F28F08C8D5A@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
	<7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
	<5695047D.3050701@oracle.com>
	<8FE44E53-E991-4629-8DD0-86703A373A65@oracle.com>
	<569692A9.8010709@oracle.com>
	<2F0E2127-FFC0-4BB9-B982-9F28F08C8D5A@oracle.com>
Message-ID: <569739E5.2030608@oracle.com>

Looks fine.

On 14/01/16 07:37, Avik Niyogi wrote:
> Hi All,
>
> Please find code changes incorporating changes as suggested by inputs
> provided:
>
> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.02/
>
> With Regards,
> Avik Niyogi
>
>> On 13-Jan-2016, at 11:38 pm, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> On 13/01/16 09:27, Avik Niyogi wrote:
>>> Hi Sergey,
>>> If fFileList refers to a soft linked empty folder, we will  will not
>>> need to apply orientation to it?s sub-components.
>> I didn't understand what "soft linked empty folder" means here =((
>>
>> Just to clarify. In the fix you have this code:
>>  95             if (fFileList != null) {
>>  96                 fFileList.setComponentOrientation(o);
>> ...
>>  98             }
>>
>> Which means that fFileList can be null, but it is a final field in the
>> AquaFileSystemModel and it is initialized in the
>> AquaFileChooserUI.createList() to a non null value:
>>
>>        fFileList = new JTableExtension();
>> .....
>>        model = new AquaFileSystemModel(fc, fFileList, fColumnNames);
>>
>> Or am I missing something?
>>
>>>
>>> With Regards,
>>> Avik Niyogi
>>>
>>>> On 12-Jan-2016, at 7:19 pm, Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>
>>>> Hi, Avik.
>>>> Is it possible that fFileList can be null? I see that in other places
>>>> we do not check it to null?
>>>>
>>>> On 04/01/16 11:52, Avik Niyogi wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review the webrev.01 :
>>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/
>>>>> incorporated with the inputs received.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>
>>>>>> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niyogi at oracle.com
>>>>>> <mailto:avik.niyogi at oracle.com>
>>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>
>>>>>> Hi Alexandr,
>>>>>>
>>>>>> Automated test may fail based on folder contents on individual systems
>>>>>> irrespective of the fix directly not depending on the same.
>>>>>> Also, to confirm this fix, it will need visual confirmation and hence,
>>>>>> no automated test was provided.
>>>>>>
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>> On 23-Dec-2015, at 7:32 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.
>>>>>>>
>>>>>>> Is it possible to write an automated test for the fix?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>
>>>>>>>> *Bug:*
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8016665
>>>>>>>>
>>>>>>>> *Webrev:*
>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/
>>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>>>>>>>
>>>>>>>> *Issue:*
>>>>>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>>>>>> in testsuite fails.
>>>>>>>>
>>>>>>>> *Cause:*
>>>>>>>> Due to not honouring of RIGHT_TO_LEFT parameter for setOrientation
>>>>>>>> method applied for a JFileChooser for the AquaLookAndFeel only,
>>>>>>>> the fileChooser does not get displayed in RIGHT_TO_LEFT orientation.
>>>>>>>> This issue was verified to exist only in AquaLookAndFeel for
>>>>>>>> JFileChooser only due to wrong implementation in
>>>>>>>> AquaFileSystemModel.
>>>>>>>> Also, as provided in comments: "The Aqua LAF must support the RTL
>>>>>>>> orientation of JFileChooser."
>>>>>>>>
>>>>>>>> *Fix:*
>>>>>>>> Added implementation for the check of RIGHT_TO_LEFT
>>>>>>>> ComponentOrientation and verified with test suite.
>>>>>>>>
>>>>>>>>
>>>>>>>> With Regards,
>>>>>>>> Avik Niyogi
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Jan 14 06:06:34 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Jan 2016 09:06:34 +0300
Subject: <Swing Dev> Review Request of 8146321: [macosx] JInternalFrame
 frame icon in wrong position on Mac L&F if icon is not ImageIcon
In-Reply-To: <431B2640-2D19-4EFC-824E-52AE3D25D2D8@oracle.com>
References: <431B2640-2D19-4EFC-824E-52AE3D25D2D8@oracle.com>
Message-ID: <56973AEA.1040308@oracle.com>

Hi, Avik.
In the fix you update getIconWidth() and getIconHeight, so now we take 
the Icon into account. but it seems if the Icon is bigger that the 
maximum size it will not be resided to 16x16, right?

On 14/01/16 07:49, Avik Niyogi wrote:
> Hi All,
>
> Kindly review the bug fix for JDK 9.
>
> *Bug:*
> https://bugs.openjdk.java.net/browse/JDK-8146321
>
> *Webrev:*
> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/
>
> *Issue:*
> Under the Mac Look&Feel, if an icon type other than an ImageIcon is used
> in JInternalFrame.setFrameIcon(),
> the icon will show up in the wrong position.
>
> *Cause:*
> the "instanceof Icon" was not checked for. Also, customs ImageIcon with
> color fill (and no image URL) which would
> have resulted in null value for resized ImageIcon image was not well
> handled.
>
> *Fix:*
> All places in Aqua LAF where "instanceof Icon? (and not just ImageIcon
> class) is required,
> inputs were added after significant analyses.
> Check for null for getImage was done to remove a Null Pointer Exception.
>
> With Regards,
> Avik Niyogi


-- 
Best regards, Sergey.


From avik.niyogi at oracle.com  Thu Jan 14 07:25:05 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 14 Jan 2016 12:55:05 +0530
Subject: <Swing Dev> Review Request of 8146321: [macosx] JInternalFrame
	frame icon in wrong position on Mac L&F if icon is not ImageIcon
In-Reply-To: <56973AEA.1040308@oracle.com>
References: <431B2640-2D19-4EFC-824E-52AE3D25D2D8@oracle.com>
	<56973AEA.1040308@oracle.com>
Message-ID: <BEB3BF05-B31A-4595-BCBB-E9DC915AED19@oracle.com>

Hi Sergey,
I have verified it with the test case as well. If a test case overrides these methods to imply a change with icons larger than 16x16 it will show that for ImageIcon and Icon as before. The resize of ImageIcon is only in case it has an image file that it will try to fit. I had a similar query myself and have found out that getImage() exists for ImageIcon class only and not Icon class.
Example:
private static void createImageIconUI(final String lookAndFeelString)
            throws Exception {
        SwingUtilities.invokeAndWait(new Runnable() {
            @Override
            public void run() {
                desktopPane = new JDesktopPane();
                internalFrame = new JInternalFrame();
                frame = new JFrame();
                internalFrame.setTitle(lookAndFeelString);
                titleImageIcon = new ImageIcon() {
                    @Override
                    public int getIconWidth() {
                        return 16;
                    }

                    @Override
                    public int getIconHeight() {
                        return 16;
                    }

                    @Override
                    public void paintIcon(
                            Component c, Graphics g, int x, int y) {
                        g.setColor(java.awt.Color.black);
                        g.fillRect(x, y, 50, 50);
                    }
                };
                internalFrame.setFrameIcon(titleImageIcon);
                internalFrame.setSize(500, 200);
                internalFrame.setVisible(true);
                desktopPane.add(internalFrame);

                frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                frame.getContentPane().setLayout(new BorderLayout());
                frame.getContentPane().add(desktopPane, "Center");
                frame.setSize(500, 500);
                frame.setLocationRelativeTo(null);
                frame.setVisible(true);
                frame.toFront();
            }
        });
    }
In this case the ImageIcon will NOT be resized to 16 x 16 even before my fix was implemented. That resize as shown in code is only for Image files to fit in default ImageIcon size as returned from the getIconHeight() and getIconWidth() methods. If user changes the ImageIcon size as in the example, that is upto to user to choose to do so and no control exists to prevent that. So, with or without my fix, this behaviour will be same for ImageIcon and Icon custom instances.
Hope this clarifies the query. 

With Regards,
Avik Niyogi

> On 14-Jan-2016, at 11:36 am, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Avik.
> In the fix you update getIconWidth() and getIconHeight, so now we take the Icon into account. but it seems if the Icon is bigger that the maximum size it will not be resided to 16x16, right?
> 
> On 14/01/16 07:49, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the bug fix for JDK 9.
>> 
>> *Bug:*
>> https://bugs.openjdk.java.net/browse/JDK-8146321
>> 
>> *Webrev:*
>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/
>> 
>> *Issue:*
>> Under the Mac Look&Feel, if an icon type other than an ImageIcon is used
>> in JInternalFrame.setFrameIcon(),
>> the icon will show up in the wrong position.
>> 
>> *Cause:*
>> the "instanceof Icon" was not checked for. Also, customs ImageIcon with
>> color fill (and no image URL) which would
>> have resulted in null value for resized ImageIcon image was not well
>> handled.
>> 
>> *Fix:*
>> All places in Aqua LAF where "instanceof Icon? (and not just ImageIcon
>> class) is required,
>> inputs were added after significant analyses.
>> Check for null for getImage was done to remove a Null Pointer Exception.
>> 
>> With Regards,
>> Avik Niyogi
> 
> 
> -- 
> Best regards, Sergey.

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

From alexandr.scherbatiy at oracle.com  Thu Jan 14 09:42:18 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 14 Jan 2016 12:42:18 +0300
Subject: <Swing Dev> Review request for 8016665: [macosx] JComponent
 behaviour doesn't comply API documentation (setComponentOrientation method),
 Aqua LAF
In-Reply-To: <569739E5.2030608@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
	<FCD0176E-2266-41A7-9EED-AFDD9CFBA761@oracle.com>
	<7181B5DD-1FA3-4849-AEE8-43A0A8834F95@oracle.com>
	<5695047D.3050701@oracle.com>
	<8FE44E53-E991-4629-8DD0-86703A373A65@oracle.com>
	<569692A9.8010709@oracle.com>
	<2F0E2127-FFC0-4BB9-B982-9F28F08C8D5A@oracle.com>
	<569739E5.2030608@oracle.com>
Message-ID: <56976D7A.2000201@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 1/14/2016 9:02 AM, Sergey Bylokhov wrote:
> Looks fine.
>
> On 14/01/16 07:37, Avik Niyogi wrote:
>> Hi All,
>>
>> Please find code changes incorporating changes as suggested by inputs
>> provided:
>>
>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.02/
>>
>> With Regards,
>> Avik Niyogi
>>
>>> On 13-Jan-2016, at 11:38 pm, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>
>>> On 13/01/16 09:27, Avik Niyogi wrote:
>>>> Hi Sergey,
>>>> If fFileList refers to a soft linked empty folder, we will will not
>>>> need to apply orientation to it?s sub-components.
>>> I didn't understand what "soft linked empty folder" means here =((
>>>
>>> Just to clarify. In the fix you have this code:
>>>  95             if (fFileList != null) {
>>>  96                 fFileList.setComponentOrientation(o);
>>> ...
>>>  98             }
>>>
>>> Which means that fFileList can be null, but it is a final field in the
>>> AquaFileSystemModel and it is initialized in the
>>> AquaFileChooserUI.createList() to a non null value:
>>>
>>>        fFileList = new JTableExtension();
>>> .....
>>>        model = new AquaFileSystemModel(fc, fFileList, fColumnNames);
>>>
>>> Or am I missing something?
>>>
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>
>>>>> On 12-Jan-2016, at 7:19 pm, Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>
>>>>> Hi, Avik.
>>>>> Is it possible that fFileList can be null? I see that in other places
>>>>> we do not check it to null?
>>>>>
>>>>> On 04/01/16 11:52, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review the webrev.01 :
>>>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/
>>>>>> incorporated with the inputs received.
>>>>>>
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>
>>>>>>> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niyogi at oracle.com
>>>>>>> <mailto:avik.niyogi at oracle.com>
>>>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>>
>>>>>>> Hi Alexandr,
>>>>>>>
>>>>>>> Automated test may fail based on folder contents on individual 
>>>>>>> systems
>>>>>>> irrespective of the fix directly not depending on the same.
>>>>>>> Also, to confirm this fix, it will need visual confirmation and 
>>>>>>> hence,
>>>>>>> no automated test was provided.
>>>>>>>
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>>> On 23-Dec-2015, at 7:32 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.
>>>>>>>>
>>>>>>>> Is it possible to write an automated test for the fix?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>>>
>>>>>>>>> *Bug:*
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8016665
>>>>>>>>>
>>>>>>>>> *Webrev:*
>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/
>>>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>>>>>>>>
>>>>>>>>> *Issue:*
>>>>>>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>>>>>>> in testsuite fails.
>>>>>>>>>
>>>>>>>>> *Cause:*
>>>>>>>>> Due to not honouring of RIGHT_TO_LEFT parameter for 
>>>>>>>>> setOrientation
>>>>>>>>> method applied for a JFileChooser for the AquaLookAndFeel only,
>>>>>>>>> the fileChooser does not get displayed in RIGHT_TO_LEFT 
>>>>>>>>> orientation.
>>>>>>>>> This issue was verified to exist only in AquaLookAndFeel for
>>>>>>>>> JFileChooser only due to wrong implementation in
>>>>>>>>> AquaFileSystemModel.
>>>>>>>>> Also, as provided in comments: "The Aqua LAF must support the RTL
>>>>>>>>> orientation of JFileChooser."
>>>>>>>>>
>>>>>>>>> *Fix:*
>>>>>>>>> Added implementation for the check of RIGHT_TO_LEFT
>>>>>>>>> ComponentOrientation and verified with test suite.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With Regards,
>>>>>>>>> Avik Niyogi
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>



From alexandr.scherbatiy at oracle.com  Thu Jan 14 09:48:32 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 14 Jan 2016 12:48:32 +0300
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <A14D4B21-B5D3-4A08-BDB8-0956008BF208@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>
Message-ID: <56976EF0.5080204@oracle.com>

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/>

    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>> 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/>
>>>
>>
>>  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>> 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/>
>>>>>
>>>>> 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>> 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/>
>>>>>>> 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>> 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/>
>>>>>>>>>
>>>>>>>>> *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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From avik.niyogi at oracle.com  Thu Jan 14 10:11:33 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 14 Jan 2016 15:41:33 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <56976EF0.5080204@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>
Message-ID: <2A741D47-D5A4-41F6-B57B-EE98B84685F5@oracle.com>

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/>

With Regards,
Avik Niyogi
> On 14-Jan-2016, at 3:18 pm, Alexander Scherbatiy <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/>
> 
>   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>> 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/>
>>>> 
>>> 
>>> 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>> 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/>
>>>>>> 
>>>>>> 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>> 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/>
>>>>>>>> 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>> 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/>
>>>>>>>>>> 
>>>>>>>>>> *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
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

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

From prasanta.sadhukhan at oracle.com  Thu Jan 14 11:33:00 2016
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Thu, 14 Jan 2016 17:03:00 +0530
Subject: <Swing Dev> JDK9 Review Request for JDK-7104635 HTMLEditorKit
 fails to write down some html files
In-Reply-To: <c0ae2d3b-14cb-48e6-934b-9d517c0d3155@default>
References: <c0ae2d3b-14cb-48e6-934b-9d517c0d3155@default>
Message-ID: <5697876C.8080109@oracle.com>

Fix looks good to me.

Regards
Prasanta
On 11/26/2015 2:06 PM, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
> Bug: https://bugs.openjdk.java.net/browse/JDK-7104635
> Webrev: http://cr.openjdk.java.net/~rchamyal/7104635/webrev.00/ 
> <http://cr.openjdk.java.net/%7Erchamyal/7104635/webrev.00/>
>
> Issue: If the minimized HTML has spaces the writing is failing with 
> index out of bounds exception.
>
> Cause: The AbstractWriter::indent method is passing negative length of 
> indentChars to writer.
> Fix: Added checks for negative value while decrementing the 
> AbstractWriter::indentlevel.
> Regards,
> Rajeev Chamyal
>

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

From alexandr.scherbatiy at oracle.com  Thu Jan 14 11:55:34 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 14 Jan 2016 14:55:34 +0300
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <2A741D47-D5A4-41F6-B57B-EE98B84685F5@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>
Message-ID: <56978CB5.1080209@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 1/14/2016 1:11 PM, 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>> 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>> 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>> 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>> 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>> 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/>
>>>>>>>>>>>
>>>>>>>>>>> *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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Thu Jan 14 12:02:26 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 14 Jan 2016 15:02:26 +0300
Subject: <Swing Dev> RfR JDK-8145735,
 Tests api/javax_swing/JTabbedPane/AccessibleJTabbedPane/* are
 failing
In-Reply-To: <5696BC4A.9060802@oracle.com>
References: <569422EA.7030501@oracle.com> <56954DFD.4090200@oracle.com>
	<56957A4E.3060006@oracle.com> <56964E45.7090002@oracle.com>
	<5696BC4A.9060802@oracle.com>
Message-ID: <56978E52.1010504@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 1/14/2016 12:06 AM, Pete Brunet wrote:
> How does this look?
> http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.01/
>
> Pete
>
> On 1/13/16 7:16 AM, Alexander Scherbatiy wrote:
>> On 1/13/2016 1:12 AM, Pete Brunet wrote:
>>> Hi Alexandr,
>>>
>>> On 1/12/16 1:03 PM, Alexander Scherbatiy wrote:
>>>> It seems that there still is the case when tab titles are empty
>>>> string, tab components are null, components are not null and the
>>>> correct index should be returned for the given page.
>>> In the code of the current webrev (webrev.00) if the tab component is
>>> null then getTitle() is the fallback and it uses
>>> parent.indexOfComponent().  I tested using add("", myPanel) and that
>>> worked OK.
>>>> May be it is better to replace searching the page index by tab
>>>> component to by component?
>>>> We already do this in the getTitle() method.
>>> In any event, are you suggesting just always using
>>> parent.indexOfComponent(), i.e. always using getTitle()?  The regression
>>> test runs OK with that change.  Is there a case where indexOfComponent
>>> would not work but indexOfTabComponent would?
>>    There is a possible case that  a component is null, title is empty
>> but a tabComponent is not null.
>>    May be it is better to have a method like getPageIndex() which
>> search the page index by component if it is not null, then by
>> tabComponent and by title at the last.
>>
>>    Thanks,
>>    Alexandr.
>>
>>> Pete
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>> On 12/01/16 01:47, Pete Brunet wrote:
>>>>> Please review this patch:
>>>>>
>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.00/
>>>>>
>>>>> The issue being resolved is that the JTabbedPane code can't solely
>>>>> rely
>>>>> on tabComponent when fetching the index in the parent component.
>>>>> tabComponent is optionally used and its presence indicates that the
>>>>> associated Component will render the tab title; otherwise the
>>>>> JTabbedPane tab will.  In those cases where tabComponent is used,
>>>>> if it
>>>>> is null then the tab's title must be used when determining the
>>>>> index in
>>>>> parent, i.e. parent.indexofTab(getTitle()) vs
>>>>> parent.indexOfTabComponent(tabComponent).
>>>>>
>>>>> The regression test was improved to catch the cases where the fix to
>>>>> JTabbedPane was not applied.  The regression test was also changed so
>>>>> the exception message is more cleanly displayed when the test fails.



From Sergey.Bylokhov at oracle.com  Thu Jan 14 17:27:00 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Jan 2016 20:27:00 +0300
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <2A741D47-D5A4-41F6-B57B-EE98B84685F5@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>
Message-ID: <5697DA64.40501@oracle.com>

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/
>
> 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>> 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/>
>>
>>   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>> 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/>
>>>>>
>>>>
>>>> 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>> 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/>
>>>>>>>
>>>>>>> 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>> 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/>
>>>>>>>>> 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>> 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/>
>>>>>>>>>>>
>>>>>>>>>>> *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.


From vivi.an at oracle.com  Thu Jan 14 18:19:58 2016
From: vivi.an at oracle.com (Vivi An)
Date: Thu, 14 Jan 2016 10:19:58 -0800
Subject: <Swing Dev> RfR JDK-8145735,
 Tests api/javax_swing/JTabbedPane/AccessibleJTabbedPane/* are
 failing
In-Reply-To: <56978E52.1010504@oracle.com>
References: <569422EA.7030501@oracle.com>
	<56954DFD.4090200@oracle.com>	<56957A4E.3060006@oracle.com>
	<56964E45.7090002@oracle.com>	<5696BC4A.9060802@oracle.com>
	<56978E52.1010504@oracle.com>
Message-ID: <5697E6CE.7020300@oracle.com>

+1,

Thanks

Vivi

On 1/14/2016 4:02 AM, Alexander Scherbatiy wrote:
>
>   The fix looks good to me.
>
>   Thanks,
>   Alexandr.
>
> On 1/14/2016 12:06 AM, Pete Brunet wrote:
>> How does this look?
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.01/
>>
>> Pete
>>
>> On 1/13/16 7:16 AM, Alexander Scherbatiy wrote:
>>> On 1/13/2016 1:12 AM, Pete Brunet wrote:
>>>> Hi Alexandr,
>>>>
>>>> On 1/12/16 1:03 PM, Alexander Scherbatiy wrote:
>>>>> It seems that there still is the case when tab titles are empty
>>>>> string, tab components are null, components are not null and the
>>>>> correct index should be returned for the given page.
>>>> In the code of the current webrev (webrev.00) if the tab component is
>>>> null then getTitle() is the fallback and it uses
>>>> parent.indexOfComponent().  I tested using add("", myPanel) and that
>>>> worked OK.
>>>>> May be it is better to replace searching the page index by tab
>>>>> component to by component?
>>>>> We already do this in the getTitle() method.
>>>> In any event, are you suggesting just always using
>>>> parent.indexOfComponent(), i.e. always using getTitle()? The 
>>>> regression
>>>> test runs OK with that change.  Is there a case where indexOfComponent
>>>> would not work but indexOfTabComponent would?
>>>    There is a possible case that  a component is null, title is empty
>>> but a tabComponent is not null.
>>>    May be it is better to have a method like getPageIndex() which
>>> search the page index by component if it is not null, then by
>>> tabComponent and by title at the last.
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>>> Pete
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>> On 12/01/16 01:47, Pete Brunet wrote:
>>>>>> Please review this patch:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.00/
>>>>>>
>>>>>> The issue being resolved is that the JTabbedPane code can't solely
>>>>>> rely
>>>>>> on tabComponent when fetching the index in the parent component.
>>>>>> tabComponent is optionally used and its presence indicates that the
>>>>>> associated Component will render the tab title; otherwise the
>>>>>> JTabbedPane tab will.  In those cases where tabComponent is used,
>>>>>> if it
>>>>>> is null then the tab's title must be used when determining the
>>>>>> index in
>>>>>> parent, i.e. parent.indexofTab(getTitle()) vs
>>>>>> parent.indexOfTabComponent(tabComponent).
>>>>>>
>>>>>> The regression test was improved to catch the cases where the fix to
>>>>>> JTabbedPane was not applied.  The regression test was also 
>>>>>> changed so
>>>>>> the exception message is more cleanly displayed when the test fails.
>



From semyon.sadetsky at oracle.com  Fri Jan 15 10:16:58 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 15 Jan 2016 13:16:58 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56966730.7000701@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>
Message-ID: <5698C71A.80703@oracle.com>

Hi,

getClippedString() : It is worth to explain that 3dots are added at end 
or returned.

getStringWidth(): It is worth to add a note that the returning value is 
not the exact visual string width because rendering hints are not taken 
into account.

What was the reason for renaming clipStringIfNecessary() and stringWidth()?

stringWidth() is a standard method name to get the advance in all other 
JDK interfaces.
clipStringIfNecessary method name better reflects the method operation 
than the proposed one.
This is an utility static API and we don't need to follow JavaBeans 
naming conventions here.

--Semyon


On 1/13/2016 6:03 PM, Alexander Scherbatiy wrote:
>
>   Hello,
>
>   Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.05/
>
>   - the methods description are updated to mention a component numeric 
> shaper and non-print graphics context
>   - @since tag value is updated to 9
>
>  Thanks,
>  Alexandr.
>
> On 1/12/2016 10:42 PM, Philip Race wrote:
>> @since needs to be just "9" as of the updated verona versioning scheme.
>>
>> -phil.
>>
>> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>>> Hi Alexander,
>>>
>>> I see that you've added the next clarifications to the methods specs:
>>>
>>> > draws string/returns width ... using text properties and 
>>> anti-aliasing hints from the provided component
>>>
>>> It still seems too brief and even incorrect for getStringWidth().
>>>
>>> For drawString():
>>>
>>> For non-printing case I would write:
>>>
>>> Sets the anti-aliasing rendering hints to the Graphics object if 
>>> those are specified in the component properties. Then the string is 
>>> drawn using the provided Graphics object with the numeric shaper 
>>> taken into account if it is defined for the component.
>>>
>>> Please consider the printing case...
>>>
>>> For getStringWidth():
>>>
>>> Did not get which anti-aliasing hints it takes into account while 
>>> there is no Graphics in the params list...
>>> On the contrary, it does not take into account the rendering context.
>>> My suggestion:
>>>
>>> Returns string pixel width by the provided font metrics and 
>>> according to the numeric shaper if it is defined for the component.
>>>
>>> --Semyon
>>>
>>> For
>>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>>
>>>>  Hello,
>>>>
>>>>  Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>>
>>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>>> Hi Alexandr,
>>>>>
>>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>>
>>>>> * The {@code underlinedIndex} parameter points to a char value 
>>>>> (Unicode code unit) in the
>>>>> * given string.
>>>>>
>>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>>
>>>>>
>>>>> And I suggest using "fits" instead of "can fit" in @return for 
>>>>> getClippedString() and rephrasing the conditions where empty 
>>>>> string is returned:
>>>>>
>>>>> * @return the clipped string that fits in the provided space, an 
>>>>> empty
>>>>> *         string if the given string argument is {@code null} or 
>>>>> empty.
>>>>
>>>>    The fix is updated according to the provided comments.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>>
>>>>>> - methods description is updated to mention used text properties 
>>>>>> and anti-aliasing hints from the provided component
>>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>>> - @since tag is added for the drawString() method
>>>>>> - the description that some parameters may/must not be null is added
>>>>>> - the test is updated to call the methods on EDT
>>>>>> - the test is updated to check passed null arguments
>>>>>>
>>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>>> Hi Alexandr,
>>>>>>>
>>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>>
>>>>>>>
>>>>>>> Could you please also clarify whether underlinedIndex in 
>>>>>>> drawStringUnderlineCharAt refers to the char index in the string?
>>>>>>>
>>>>>>> The statement
>>>>>>> * The underlined index refers to char values (Unicode code units).
>>>>>>> makes it unclear: underlinedIndex is an *index* or a *char* 
>>>>>>> (Unicode code point).
>>>>>>
>>>>>>  I updated it to "The underlined index points to a char value 
>>>>>> (Unicode code unit) in the given string."
>>>>>>  The 'refers' word was used for a value at the given index.
>>>>>>  However, I am not sure that the new variant is better.
>>>>>>>
>>>>>>>
>>>>>>> * Nothing is drawn for null string. No character is underlined 
>>>>>>> for the
>>>>>>> * index {@code < 0}, {@code >=} than the string width or if the 
>>>>>>> char value
>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>
>>>>>>> I think it will be better to spell comparison operators, I mean 
>>>>>>> to use  "greater than" rather than ">=". And "length" must be 
>>>>>>> used instead of "width".
>>>>>>>
>>>>>>> I propose the following text:
>>>>>>>
>>>>>>> No character is underlined if the index is negative or greater 
>>>>>>> than the string length or if the char value specified at the 
>>>>>>> given index is in the low-surrogate range.
>>>>>>>
>>>>>>> For the first part of condition, you can add clarification in 
>>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>>  Updated.
>>>>>>>
>>>>>>>
>>>>>>> For consistency, please remove the full stop in @return tag in 
>>>>>>> description of getClippedString.
>>>>>>
>>>>>> Updated.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>>
>>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>>
>>>>>>>> The javadoc references for the #drawStringUnderlineCharAt and 
>>>>>>>> #getClippedString methods are moved after parameters description.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>>
>>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with 
>>>>>>>>> chars that have
>>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>>>> The whole glyph is underlined.
>>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>>>
>>>>>>>>> The char value specified the the underlined index should point 
>>>>>>>>> to the high-surrogate range of a supplementary character.
>>>>>>>>> I updated the javadoc for the 
>>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>>> -----------------------------
>>>>>>>>> /**
>>>>>>>>> * Draws the given string at the specified location underlining
>>>>>>>>> * the specified character.
>>>>>>>>> * <p>
>>>>>>>>> * The underlined index refers to char values (Unicode code 
>>>>>>>>> units).
>>>>>>>>> * If the char value specified at the given underlined index is in
>>>>>>>>> * the high-surrogate range and the char value at the following 
>>>>>>>>> index is in
>>>>>>>>> * the low-surrogate range then the supplementary character 
>>>>>>>>> corresponding
>>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>>> * <p>
>>>>>>>>> * Nothing is drawn for null string. No character is underlined 
>>>>>>>>> for the
>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if 
>>>>>>>>> the char value
>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>> -----------------------------
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>>> I don't remember or know how Swing resolves this but the 
>>>>>>>>>>> measurement ones
>>>>>>>>>>> are not reliable since they do not take a Graphics context, 
>>>>>>>>>>> so you cannot
>>>>>>>>>>> measure the string properly. You need a FontRenderContext to 
>>>>>>>>>>> measure.
>>>>>>>>>>
>>>>>>>>>> The provided methods use 
>>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method which 
>>>>>>>>>> returns the FontRenderContext associated with the component.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So as it stands these APIs do not appear suitable to be made 
>>>>>>>>>>> public as they
>>>>>>>>>>> are not reliable.
>>>>>>>>>>>
>>>>>>>>>>> Whilst I could look at the code, if I instead just look at 
>>>>>>>>>>> the API, I am scratching my
>>>>>>>>>>> head over :-
>>>>>>>>>>>
>>>>>>>>>>> public static void drawString(JComponent c, Graphics g, 
>>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>>
>>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>>> So I am supposing that there is optional information that 
>>>>>>>>>>> may be pulled from the
>>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>>
>>>>>>>>>> The optional information provided by the component is:
>>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>>> - antialiasing hints
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if 
>>>>>>>>>>> the index is code point
>>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1 
>>>>>>>>>>> code point:glyph mapping.
>>>>>>>>>> I will update this.
>>>>>>>>>>>
>>>>>>>>>>> Are we sure that (any of) these really ought/need to be 
>>>>>>>>>>> public - particularly given the
>>>>>>>>>>> resolution of https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>>
>>>>>>>>>> These methods are used by JDK L&Fs to draw text. The initial 
>>>>>>>>>> request was to provide public methods that can be used by a 
>>>>>>>>>> custom L&F to draw strings consistently with other L&Fs.
>>>>>>>>>>
>>>>>>>>>> They are also designed to properly render text for printing. 
>>>>>>>>>> To do that they use call to internal ProxyPrintGraphics class 
>>>>>>>>>> to obtain the print graphics context.
>>>>>>>>>>
>>>>>>>>>> Even if printing staff will be public, these methods are just 
>>>>>>>>>> utility methods (in the same way as other text methods in the 
>>>>>>>>>> javax.swing.text.Utilities class) that help easily to draw 
>>>>>>>>>> and print text in the same way as JDK L&Fs do that.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -phil.
>>>>>>>>>>>
>>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>>
>>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt, 
>>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>



From alexandr.scherbatiy at oracle.com  Fri Jan 15 16:31:21 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 15 Jan 2016 19:31:21 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5698C71A.80703@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>
Message-ID: <56991ED9.5030302@oracle.com>


  Hello,

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

   - the description of the getClippedString method is updated to 
mention that ellipsis is added at the end of the clipped string

On 1/15/2016 1:16 PM, Semyon Sadetsky wrote:
> Hi,
>
> getClippedString() : It is worth to explain that 3dots are added at 
> end or returned.
>
> getStringWidth(): It is worth to add a note that the returning value 
> is not the exact visual string width because rendering hints are not 
> taken into account.
     I thought that rendering hints can affect a string quaility and 
drawing performance. Do they really change the visual string width?
>
> What was the reason for renaming clipStringIfNecessary() and 
> stringWidth()?
>
> stringWidth() is a standard method name to get the advance in all 
> other JDK interfaces.
     The 'get' prefix is used here not because it is JavaBeans 
requirements but because of the method name conventions.
     For example, the same Utilities class contains getTabbedTextWidth() 
method which also has the 'get' prefix.

> clipStringIfNecessary method name better reflects the method operation 
> than the proposed one.
     The 'necessary' word is vague in this case. Is there any need to 
clip a string if it is not necessary?
     The method description gives the explanation in which case the 
string will be clipped.

  Thanks,
  Alexandr.

> This is an utility static API and we don't need to follow JavaBeans 
> naming conventions here.
>
> --Semyon
>
>
> On 1/13/2016 6:03 PM, Alexander Scherbatiy wrote:
>>
>>   Hello,
>>
>>   Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.05/
>>
>>   - the methods description are updated to mention a component 
>> numeric shaper and non-print graphics context
>>   - @since tag value is updated to 9
>>
>>  Thanks,
>>  Alexandr.
>>
>> On 1/12/2016 10:42 PM, Philip Race wrote:
>>> @since needs to be just "9" as of the updated verona versioning scheme.
>>>
>>> -phil.
>>>
>>> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>>>> Hi Alexander,
>>>>
>>>> I see that you've added the next clarifications to the methods specs:
>>>>
>>>> > draws string/returns width ... using text properties and 
>>>> anti-aliasing hints from the provided component
>>>>
>>>> It still seems too brief and even incorrect for getStringWidth().
>>>>
>>>> For drawString():
>>>>
>>>> For non-printing case I would write:
>>>>
>>>> Sets the anti-aliasing rendering hints to the Graphics object if 
>>>> those are specified in the component properties. Then the string is 
>>>> drawn using the provided Graphics object with the numeric shaper 
>>>> taken into account if it is defined for the component.
>>>>
>>>> Please consider the printing case...
>>>>
>>>> For getStringWidth():
>>>>
>>>> Did not get which anti-aliasing hints it takes into account while 
>>>> there is no Graphics in the params list...
>>>> On the contrary, it does not take into account the rendering context.
>>>> My suggestion:
>>>>
>>>> Returns string pixel width by the provided font metrics and 
>>>> according to the numeric shaper if it is defined for the component.
>>>>
>>>> --Semyon
>>>>
>>>> For
>>>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>>  Hello,
>>>>>
>>>>>  Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>>>
>>>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>>>> Hi Alexandr,
>>>>>>
>>>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>>>
>>>>>> * The {@code underlinedIndex} parameter points to a char value 
>>>>>> (Unicode code unit) in the
>>>>>> * given string.
>>>>>>
>>>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>>>
>>>>>>
>>>>>> And I suggest using "fits" instead of "can fit" in @return for 
>>>>>> getClippedString() and rephrasing the conditions where empty 
>>>>>> string is returned:
>>>>>>
>>>>>> * @return the clipped string that fits in the provided space, an 
>>>>>> empty
>>>>>> *         string if the given string argument is {@code null} or 
>>>>>> empty.
>>>>>
>>>>>    The fix is updated according to the provided comments.
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alexey
>>>>>>
>>>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>>>
>>>>>>> - methods description is updated to mention used text properties 
>>>>>>> and anti-aliasing hints from the provided component
>>>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>>>> - @since tag is added for the drawString() method
>>>>>>> - the description that some parameters may/must not be null is 
>>>>>>> added
>>>>>>> - the test is updated to call the methods on EDT
>>>>>>> - the test is updated to check passed null arguments
>>>>>>>
>>>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>
>>>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>>>
>>>>>>>>
>>>>>>>> Could you please also clarify whether underlinedIndex in 
>>>>>>>> drawStringUnderlineCharAt refers to the char index in the string?
>>>>>>>>
>>>>>>>> The statement
>>>>>>>> * The underlined index refers to char values (Unicode code units).
>>>>>>>> makes it unclear: underlinedIndex is an *index* or a *char* 
>>>>>>>> (Unicode code point).
>>>>>>>
>>>>>>>  I updated it to "The underlined index points to a char value 
>>>>>>> (Unicode code unit) in the given string."
>>>>>>>  The 'refers' word was used for a value at the given index.
>>>>>>>  However, I am not sure that the new variant is better.
>>>>>>>>
>>>>>>>>
>>>>>>>> * Nothing is drawn for null string. No character is underlined 
>>>>>>>> for the
>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if the 
>>>>>>>> char value
>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>
>>>>>>>> I think it will be better to spell comparison operators, I mean 
>>>>>>>> to use  "greater than" rather than ">=". And "length" must be 
>>>>>>>> used instead of "width".
>>>>>>>>
>>>>>>>> I propose the following text:
>>>>>>>>
>>>>>>>> No character is underlined if the index is negative or greater 
>>>>>>>> than the string length or if the char value specified at the 
>>>>>>>> given index is in the low-surrogate range.
>>>>>>>>
>>>>>>>> For the first part of condition, you can add clarification in 
>>>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>>>  Updated.
>>>>>>>>
>>>>>>>>
>>>>>>>> For consistency, please remove the full stop in @return tag in 
>>>>>>>> description of getClippedString.
>>>>>>>
>>>>>>> Updated.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey
>>>>>>>>
>>>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>>>
>>>>>>>>> The javadoc references for the #drawStringUnderlineCharAt and 
>>>>>>>>> #getClippedString methods are moved after parameters description.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>>>
>>>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with 
>>>>>>>>>> chars that have
>>>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>>>>> The whole glyph is underlined.
>>>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>>>>
>>>>>>>>>> The char value specified the the underlined index should 
>>>>>>>>>> point to the high-surrogate range of a supplementary character.
>>>>>>>>>> I updated the javadoc for the 
>>>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>>>> -----------------------------
>>>>>>>>>> /**
>>>>>>>>>> * Draws the given string at the specified location underlining
>>>>>>>>>> * the specified character.
>>>>>>>>>> * <p>
>>>>>>>>>> * The underlined index refers to char values (Unicode code 
>>>>>>>>>> units).
>>>>>>>>>> * If the char value specified at the given underlined index 
>>>>>>>>>> is in
>>>>>>>>>> * the high-surrogate range and the char value at the 
>>>>>>>>>> following index is in
>>>>>>>>>> * the low-surrogate range then the supplementary character 
>>>>>>>>>> corresponding
>>>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>>>> * <p>
>>>>>>>>>> * Nothing is drawn for null string. No character is 
>>>>>>>>>> underlined for the
>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if 
>>>>>>>>>> the char value
>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>> -----------------------------
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>>>> I don't remember or know how Swing resolves this but the 
>>>>>>>>>>>> measurement ones
>>>>>>>>>>>> are not reliable since they do not take a Graphics context, 
>>>>>>>>>>>> so you cannot
>>>>>>>>>>>> measure the string properly. You need a FontRenderContext 
>>>>>>>>>>>> to measure.
>>>>>>>>>>>
>>>>>>>>>>> The provided methods use 
>>>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method 
>>>>>>>>>>> which returns the FontRenderContext associated with the 
>>>>>>>>>>> component.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So as it stands these APIs do not appear suitable to be 
>>>>>>>>>>>> made public as they
>>>>>>>>>>>> are not reliable.
>>>>>>>>>>>>
>>>>>>>>>>>> Whilst I could look at the code, if I instead just look at 
>>>>>>>>>>>> the API, I am scratching my
>>>>>>>>>>>> head over :-
>>>>>>>>>>>>
>>>>>>>>>>>> public static void drawString(JComponent c, Graphics g, 
>>>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>>>
>>>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>>>> So I am supposing that there is optional information that 
>>>>>>>>>>>> may be pulled from the
>>>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>>>
>>>>>>>>>>> The optional information provided by the component is:
>>>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>>>> - antialiasing hints
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if 
>>>>>>>>>>>> the index is code point
>>>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1 
>>>>>>>>>>>> code point:glyph mapping.
>>>>>>>>>>> I will update this.
>>>>>>>>>>>>
>>>>>>>>>>>> Are we sure that (any of) these really ought/need to be 
>>>>>>>>>>>> public - particularly given the
>>>>>>>>>>>> resolution of https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>>>
>>>>>>>>>>> These methods are used by JDK L&Fs to draw text. The initial 
>>>>>>>>>>> request was to provide public methods that can be used by a 
>>>>>>>>>>> custom L&F to draw strings consistently with other L&Fs.
>>>>>>>>>>>
>>>>>>>>>>> They are also designed to properly render text for printing. 
>>>>>>>>>>> To do that they use call to internal ProxyPrintGraphics 
>>>>>>>>>>> class to obtain the print graphics context.
>>>>>>>>>>>
>>>>>>>>>>> Even if printing staff will be public, these methods are 
>>>>>>>>>>> just utility methods (in the same way as other text methods 
>>>>>>>>>>> in the javax.swing.text.Utilities class) that help easily to 
>>>>>>>>>>> draw and print text in the same way as JDK L&Fs do that.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -phil.
>>>>>>>>>>>>
>>>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>>>
>>>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt, 
>>>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>



From semyon.sadetsky at oracle.com  Fri Jan 15 16:58:36 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 15 Jan 2016 19:58:36 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56991ED9.5030302@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>
Message-ID: <5699253C.3030800@oracle.com>



On 1/15/2016 7:31 PM, Alexander Scherbatiy wrote:
>
>  Hello,
>
>  Could you review the updated fix:
>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.06
>
>   - the description of the getClippedString method is updated to 
> mention that ellipsis is added at the end of the clipped string
>
> On 1/15/2016 1:16 PM, Semyon Sadetsky wrote:
>> Hi,
>>
>> getClippedString() : It is worth to explain that 3dots are added at 
>> end or returned.
>>
>> getStringWidth(): It is worth to add a note that the returning value 
>> is not the exact visual string width because rendering hints are not 
>> taken into account.
>     I thought that rendering hints can affect a string quaility and 
> drawing performance. Do they really change the visual string width?
Please look how the font anti-aliasing works: 
https://upload.wikimedia.org/wikipedia/commons/3/34/A_aliased_and_simple.jpg
For example if user cut this width from a drawing artifacts may be remained.
>>
>> What was the reason for renaming clipStringIfNecessary() and 
>> stringWidth()?
>>
>> stringWidth() is a standard method name to get the advance in all 
>> other JDK interfaces.
>     The 'get' prefix is used here not because it is JavaBeans 
> requirements but because of the method name conventions.
>     For example, the same Utilities class contains 
> getTabbedTextWidth() method which also has the 'get' prefix.
>
>> clipStringIfNecessary method name better reflects the method 
>> operation than the proposed one.
>     The 'necessary' word is vague in this case. Is there any need to 
> clip a string if it is not necessary?
>     The method description gives the explanation in which case the 
> string will be clipped.
>
>  Thanks,
>  Alexandr.
>
>> This is an utility static API and we don't need to follow JavaBeans 
>> naming conventions here.
>>
>> --Semyon
>>
>>
>> On 1/13/2016 6:03 PM, Alexander Scherbatiy wrote:
>>>
>>>   Hello,
>>>
>>>   Could you review the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.05/
>>>
>>>   - the methods description are updated to mention a component 
>>> numeric shaper and non-print graphics context
>>>   - @since tag value is updated to 9
>>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>> On 1/12/2016 10:42 PM, Philip Race wrote:
>>>> @since needs to be just "9" as of the updated verona versioning 
>>>> scheme.
>>>>
>>>> -phil.
>>>>
>>>> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> I see that you've added the next clarifications to the methods specs:
>>>>>
>>>>> > draws string/returns width ... using text properties and 
>>>>> anti-aliasing hints from the provided component
>>>>>
>>>>> It still seems too brief and even incorrect for getStringWidth().
>>>>>
>>>>> For drawString():
>>>>>
>>>>> For non-printing case I would write:
>>>>>
>>>>> Sets the anti-aliasing rendering hints to the Graphics object if 
>>>>> those are specified in the component properties. Then the string 
>>>>> is drawn using the provided Graphics object with the numeric 
>>>>> shaper taken into account if it is defined for the component.
>>>>>
>>>>> Please consider the printing case...
>>>>>
>>>>> For getStringWidth():
>>>>>
>>>>> Did not get which anti-aliasing hints it takes into account while 
>>>>> there is no Graphics in the params list...
>>>>> On the contrary, it does not take into account the rendering context.
>>>>> My suggestion:
>>>>>
>>>>> Returns string pixel width by the provided font metrics and 
>>>>> according to the numeric shaper if it is defined for the component.
>>>>>
>>>>> --Semyon
>>>>>
>>>>> For
>>>>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>  Hello,
>>>>>>
>>>>>>  Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>>>>
>>>>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>>>>> Hi Alexandr,
>>>>>>>
>>>>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>>>>
>>>>>>> * The {@code underlinedIndex} parameter points to a char value 
>>>>>>> (Unicode code unit) in the
>>>>>>> * given string.
>>>>>>>
>>>>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>>>>
>>>>>>>
>>>>>>> And I suggest using "fits" instead of "can fit" in @return for 
>>>>>>> getClippedString() and rephrasing the conditions where empty 
>>>>>>> string is returned:
>>>>>>>
>>>>>>> * @return the clipped string that fits in the provided space, an 
>>>>>>> empty
>>>>>>> *         string if the given string argument is {@code null} or 
>>>>>>> empty.
>>>>>>
>>>>>>    The fix is updated according to the provided comments.
>>>>>>
>>>>>>    Thanks,
>>>>>>    Alexandr.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>>
>>>>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>>>>
>>>>>>>> - methods description is updated to mention used text 
>>>>>>>> properties and anti-aliasing hints from the provided component
>>>>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>>>>> - @since tag is added for the drawString() method
>>>>>>>> - the description that some parameters may/must not be null is 
>>>>>>>> added
>>>>>>>> - the test is updated to call the methods on EDT
>>>>>>>> - the test is updated to check passed null arguments
>>>>>>>>
>>>>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>>>>> Hi Alexandr,
>>>>>>>>>
>>>>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Could you please also clarify whether underlinedIndex in 
>>>>>>>>> drawStringUnderlineCharAt refers to the char index in the string?
>>>>>>>>>
>>>>>>>>> The statement
>>>>>>>>> * The underlined index refers to char values (Unicode code 
>>>>>>>>> units).
>>>>>>>>> makes it unclear: underlinedIndex is an *index* or a *char* 
>>>>>>>>> (Unicode code point).
>>>>>>>>
>>>>>>>>  I updated it to "The underlined index points to a char value 
>>>>>>>> (Unicode code unit) in the given string."
>>>>>>>>  The 'refers' word was used for a value at the given index.
>>>>>>>>  However, I am not sure that the new variant is better.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> * Nothing is drawn for null string. No character is underlined 
>>>>>>>>> for the
>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if 
>>>>>>>>> the char value
>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>
>>>>>>>>> I think it will be better to spell comparison operators, I 
>>>>>>>>> mean to use  "greater than" rather than ">=". And "length" 
>>>>>>>>> must be used instead of "width".
>>>>>>>>>
>>>>>>>>> I propose the following text:
>>>>>>>>>
>>>>>>>>> No character is underlined if the index is negative or greater 
>>>>>>>>> than the string length or if the char value specified at the 
>>>>>>>>> given index is in the low-surrogate range.
>>>>>>>>>
>>>>>>>>> For the first part of condition, you can add clarification in 
>>>>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>>>>  Updated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For consistency, please remove the full stop in @return tag in 
>>>>>>>>> description of getClippedString.
>>>>>>>>
>>>>>>>> Updated.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alexey
>>>>>>>>>
>>>>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>>>>
>>>>>>>>>> The javadoc references for the #drawStringUnderlineCharAt and 
>>>>>>>>>> #getClippedString methods are moved after parameters 
>>>>>>>>>> description.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with 
>>>>>>>>>>> chars that have
>>>>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>>>>>> The whole glyph is underlined.
>>>>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>>>>>
>>>>>>>>>>> The char value specified the the underlined index should 
>>>>>>>>>>> point to the high-surrogate range of a supplementary character.
>>>>>>>>>>> I updated the javadoc for the 
>>>>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>>>>> -----------------------------
>>>>>>>>>>> /**
>>>>>>>>>>> * Draws the given string at the specified location underlining
>>>>>>>>>>> * the specified character.
>>>>>>>>>>> * <p>
>>>>>>>>>>> * The underlined index refers to char values (Unicode code 
>>>>>>>>>>> units).
>>>>>>>>>>> * If the char value specified at the given underlined index 
>>>>>>>>>>> is in
>>>>>>>>>>> * the high-surrogate range and the char value at the 
>>>>>>>>>>> following index is in
>>>>>>>>>>> * the low-surrogate range then the supplementary character 
>>>>>>>>>>> corresponding
>>>>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>>>>> * <p>
>>>>>>>>>>> * Nothing is drawn for null string. No character is 
>>>>>>>>>>> underlined for the
>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if 
>>>>>>>>>>> the char value
>>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>> -----------------------------
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>>>>> I don't remember or know how Swing resolves this but the 
>>>>>>>>>>>>> measurement ones
>>>>>>>>>>>>> are not reliable since they do not take a Graphics 
>>>>>>>>>>>>> context, so you cannot
>>>>>>>>>>>>> measure the string properly. You need a FontRenderContext 
>>>>>>>>>>>>> to measure.
>>>>>>>>>>>>
>>>>>>>>>>>> The provided methods use 
>>>>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method 
>>>>>>>>>>>> which returns the FontRenderContext associated with the 
>>>>>>>>>>>> component.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So as it stands these APIs do not appear suitable to be 
>>>>>>>>>>>>> made public as they
>>>>>>>>>>>>> are not reliable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Whilst I could look at the code, if I instead just look at 
>>>>>>>>>>>>> the API, I am scratching my
>>>>>>>>>>>>> head over :-
>>>>>>>>>>>>>
>>>>>>>>>>>>> public static void drawString(JComponent c, Graphics g, 
>>>>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>>>>> So I am supposing that there is optional information that 
>>>>>>>>>>>>> may be pulled from the
>>>>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>>>>
>>>>>>>>>>>> The optional information provided by the component is:
>>>>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>>>>> - antialiasing hints
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if 
>>>>>>>>>>>>> the index is code point
>>>>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1 
>>>>>>>>>>>>> code point:glyph mapping.
>>>>>>>>>>>> I will update this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are we sure that (any of) these really ought/need to be 
>>>>>>>>>>>>> public - particularly given the
>>>>>>>>>>>>> resolution of 
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>>>>
>>>>>>>>>>>> These methods are used by JDK L&Fs to draw text. The 
>>>>>>>>>>>> initial request was to provide public methods that can be 
>>>>>>>>>>>> used by a custom L&F to draw strings consistently with 
>>>>>>>>>>>> other L&Fs.
>>>>>>>>>>>>
>>>>>>>>>>>> They are also designed to properly render text for 
>>>>>>>>>>>> printing. To do that they use call to internal 
>>>>>>>>>>>> ProxyPrintGraphics class to obtain the print graphics context.
>>>>>>>>>>>>
>>>>>>>>>>>> Even if printing staff will be public, these methods are 
>>>>>>>>>>>> just utility methods (in the same way as other text methods 
>>>>>>>>>>>> in the javax.swing.text.Utilities class) that help easily 
>>>>>>>>>>>> to draw and print text in the same way as JDK L&Fs do that.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt, 
>>>>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Fri Jan 15 21:25:10 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 16 Jan 2016 00:25:10 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56991ED9.5030302@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>
Message-ID: <569963B6.2050604@oracle.com>

On 15/01/16 19:31, Alexander Scherbatiy wrote:
>    - the description of the getClippedString method is updated to
> mention that ellipsis is added at the end of the clipped string

It seems that we go far far away from the description of mission of this 
method to the description of its implementation. The goal of the method 
is possibility for clients to use the same draw functions which are used 
by our L&F so the custom components will look the same as standard 
components. Description that something is added to the end of the 
clipped string, the exact list of client properties seems unnecessary?
Moreover it seems that if the requested space is really small we can 
return ellipses which will occupy more space than requested.(i guess 
this is a separate bug)

>
> On 1/15/2016 1:16 PM, Semyon Sadetsky wrote:
>> Hi,
>>
>> getClippedString() : It is worth to explain that 3dots are added at
>> end or returned.
>>
>> getStringWidth(): It is worth to add a note that the returning value
>> is not the exact visual string width because rendering hints are not
>> taken into account.
>      I thought that rendering hints can affect a string quaility and
> drawing performance. Do they really change the visual string width?
>>
>> What was the reason for renaming clipStringIfNecessary() and
>> stringWidth()?
>>
>> stringWidth() is a standard method name to get the advance in all
>> other JDK interfaces.
>      The 'get' prefix is used here not because it is JavaBeans
> requirements but because of the method name conventions.
>      For example, the same Utilities class contains getTabbedTextWidth()
> method which also has the 'get' prefix.
>
>> clipStringIfNecessary method name better reflects the method operation
>> than the proposed one.
>      The 'necessary' word is vague in this case. Is there any need to
> clip a string if it is not necessary?
>      The method description gives the explanation in which case the
> string will be clipped.
>
>   Thanks,
>   Alexandr.
>
>> This is an utility static API and we don't need to follow JavaBeans
>> naming conventions here.
>>
>> --Semyon
>>
>>
>> On 1/13/2016 6:03 PM, Alexander Scherbatiy wrote:
>>>
>>>   Hello,
>>>
>>>   Could you review the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.05/
>>>
>>>   - the methods description are updated to mention a component
>>> numeric shaper and non-print graphics context
>>>   - @since tag value is updated to 9
>>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>> On 1/12/2016 10:42 PM, Philip Race wrote:
>>>> @since needs to be just "9" as of the updated verona versioning scheme.
>>>>
>>>> -phil.
>>>>
>>>> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> I see that you've added the next clarifications to the methods specs:
>>>>>
>>>>> > draws string/returns width ... using text properties and
>>>>> anti-aliasing hints from the provided component
>>>>>
>>>>> It still seems too brief and even incorrect for getStringWidth().
>>>>>
>>>>> For drawString():
>>>>>
>>>>> For non-printing case I would write:
>>>>>
>>>>> Sets the anti-aliasing rendering hints to the Graphics object if
>>>>> those are specified in the component properties. Then the string is
>>>>> drawn using the provided Graphics object with the numeric shaper
>>>>> taken into account if it is defined for the component.
>>>>>
>>>>> Please consider the printing case...
>>>>>
>>>>> For getStringWidth():
>>>>>
>>>>> Did not get which anti-aliasing hints it takes into account while
>>>>> there is no Graphics in the params list...
>>>>> On the contrary, it does not take into account the rendering context.
>>>>> My suggestion:
>>>>>
>>>>> Returns string pixel width by the provided font metrics and
>>>>> according to the numeric shaper if it is defined for the component.
>>>>>
>>>>> --Semyon
>>>>>
>>>>> For
>>>>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>  Hello,
>>>>>>
>>>>>>  Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>>>>
>>>>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>>>>> Hi Alexandr,
>>>>>>>
>>>>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>>>>
>>>>>>> * The {@code underlinedIndex} parameter points to a char value
>>>>>>> (Unicode code unit) in the
>>>>>>> * given string.
>>>>>>>
>>>>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>>>>
>>>>>>>
>>>>>>> And I suggest using "fits" instead of "can fit" in @return for
>>>>>>> getClippedString() and rephrasing the conditions where empty
>>>>>>> string is returned:
>>>>>>>
>>>>>>> * @return the clipped string that fits in the provided space, an
>>>>>>> empty
>>>>>>> *         string if the given string argument is {@code null} or
>>>>>>> empty.
>>>>>>
>>>>>>    The fix is updated according to the provided comments.
>>>>>>
>>>>>>    Thanks,
>>>>>>    Alexandr.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>>
>>>>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>>>>
>>>>>>>> - methods description is updated to mention used text properties
>>>>>>>> and anti-aliasing hints from the provided component
>>>>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>>>>> - @since tag is added for the drawString() method
>>>>>>>> - the description that some parameters may/must not be null is
>>>>>>>> added
>>>>>>>> - the test is updated to call the methods on EDT
>>>>>>>> - the test is updated to check passed null arguments
>>>>>>>>
>>>>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>>>>> Hi Alexandr,
>>>>>>>>>
>>>>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Could you please also clarify whether underlinedIndex in
>>>>>>>>> drawStringUnderlineCharAt refers to the char index in the string?
>>>>>>>>>
>>>>>>>>> The statement
>>>>>>>>> * The underlined index refers to char values (Unicode code units).
>>>>>>>>> makes it unclear: underlinedIndex is an *index* or a *char*
>>>>>>>>> (Unicode code point).
>>>>>>>>
>>>>>>>>  I updated it to "The underlined index points to a char value
>>>>>>>> (Unicode code unit) in the given string."
>>>>>>>>  The 'refers' word was used for a value at the given index.
>>>>>>>>  However, I am not sure that the new variant is better.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> * Nothing is drawn for null string. No character is underlined
>>>>>>>>> for the
>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if the
>>>>>>>>> char value
>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>
>>>>>>>>> I think it will be better to spell comparison operators, I mean
>>>>>>>>> to use  "greater than" rather than ">=". And "length" must be
>>>>>>>>> used instead of "width".
>>>>>>>>>
>>>>>>>>> I propose the following text:
>>>>>>>>>
>>>>>>>>> No character is underlined if the index is negative or greater
>>>>>>>>> than the string length or if the char value specified at the
>>>>>>>>> given index is in the low-surrogate range.
>>>>>>>>>
>>>>>>>>> For the first part of condition, you can add clarification in
>>>>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>>>>  Updated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For consistency, please remove the full stop in @return tag in
>>>>>>>>> description of getClippedString.
>>>>>>>>
>>>>>>>> Updated.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alexey
>>>>>>>>>
>>>>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>>>>
>>>>>>>>>> The javadoc references for the #drawStringUnderlineCharAt and
>>>>>>>>>> #getClippedString methods are moved after parameters description.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with
>>>>>>>>>>> chars that have
>>>>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>>>>>> The whole glyph is underlined.
>>>>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>>>>>
>>>>>>>>>>> The char value specified the the underlined index should
>>>>>>>>>>> point to the high-surrogate range of a supplementary character.
>>>>>>>>>>> I updated the javadoc for the
>>>>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>>>>> -----------------------------
>>>>>>>>>>> /**
>>>>>>>>>>> * Draws the given string at the specified location underlining
>>>>>>>>>>> * the specified character.
>>>>>>>>>>> * <p>
>>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>>> units).
>>>>>>>>>>> * If the char value specified at the given underlined index
>>>>>>>>>>> is in
>>>>>>>>>>> * the high-surrogate range and the char value at the
>>>>>>>>>>> following index is in
>>>>>>>>>>> * the low-surrogate range then the supplementary character
>>>>>>>>>>> corresponding
>>>>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>>>>> * <p>
>>>>>>>>>>> * Nothing is drawn for null string. No character is
>>>>>>>>>>> underlined for the
>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>>> the char value
>>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>> -----------------------------
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>>>>> I don't remember or know how Swing resolves this but the
>>>>>>>>>>>>> measurement ones
>>>>>>>>>>>>> are not reliable since they do not take a Graphics context,
>>>>>>>>>>>>> so you cannot
>>>>>>>>>>>>> measure the string properly. You need a FontRenderContext
>>>>>>>>>>>>> to measure.
>>>>>>>>>>>>
>>>>>>>>>>>> The provided methods use
>>>>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method
>>>>>>>>>>>> which returns the FontRenderContext associated with the
>>>>>>>>>>>> component.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So as it stands these APIs do not appear suitable to be
>>>>>>>>>>>>> made public as they
>>>>>>>>>>>>> are not reliable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Whilst I could look at the code, if I instead just look at
>>>>>>>>>>>>> the API, I am scratching my
>>>>>>>>>>>>> head over :-
>>>>>>>>>>>>>
>>>>>>>>>>>>> public static void drawString(JComponent c, Graphics g,
>>>>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>>>>> So I am supposing that there is optional information that
>>>>>>>>>>>>> may be pulled from the
>>>>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>>>>
>>>>>>>>>>>> The optional information provided by the component is:
>>>>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>>>>> - antialiasing hints
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if
>>>>>>>>>>>>> the index is code point
>>>>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1
>>>>>>>>>>>>> code point:glyph mapping.
>>>>>>>>>>>> I will update this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are we sure that (any of) these really ought/need to be
>>>>>>>>>>>>> public - particularly given the
>>>>>>>>>>>>> resolution of https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>>>>
>>>>>>>>>>>> These methods are used by JDK L&Fs to draw text. The initial
>>>>>>>>>>>> request was to provide public methods that can be used by a
>>>>>>>>>>>> custom L&F to draw strings consistently with other L&Fs.
>>>>>>>>>>>>
>>>>>>>>>>>> They are also designed to properly render text for printing.
>>>>>>>>>>>> To do that they use call to internal ProxyPrintGraphics
>>>>>>>>>>>> class to obtain the print graphics context.
>>>>>>>>>>>>
>>>>>>>>>>>> Even if printing staff will be public, these methods are
>>>>>>>>>>>> just utility methods (in the same way as other text methods
>>>>>>>>>>>> in the javax.swing.text.Utilities class) that help easily to
>>>>>>>>>>>> draw and print text in the same way as JDK L&Fs do that.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt,
>>>>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Fri Jan 15 21:37:09 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 16 Jan 2016 00:37:09 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5699253C.3030800@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>
	<5699253C.3030800@oracle.com>
Message-ID: <56996685.1070006@oracle.com>

On 15/01/16 19:58, Semyon Sadetsky wrote:
>>> getStringWidth(): It is worth to add a note that the returning value
>>> is not the exact visual string width because rendering hints are not
>>> taken into account.

It depends, the current description is correct. Default font metrics of 
the component should take into account KEY_TEXT_ANTIALIASING property.
The width of the string will be calculated by the passed font metrics. 
If the font metrics differs from the metrics of the graphics object then 
results will be different, if the metrics will be the same then results 
will be the same.

If these methods will produce inconsistent result when we will get a 
bugs when the size of the component(which depends from the font) will 
differ from their appearance on the screen.


>>     I thought that rendering hints can affect a string quaility and
>> drawing performance. Do they really change the visual string width?
> Please look how the font anti-aliasing works:
> https://upload.wikimedia.org/wikipedia/commons/3/34/A_aliased_and_simple.jpg
>
> For example if user cut this width from a drawing artifacts may be
> remained.
>>>
>>> What was the reason for renaming clipStringIfNecessary() and
>>> stringWidth()?
>>>
>>> stringWidth() is a standard method name to get the advance in all
>>> other JDK interfaces.
>>     The 'get' prefix is used here not because it is JavaBeans
>> requirements but because of the method name conventions.
>>     For example, the same Utilities class contains
>> getTabbedTextWidth() method which also has the 'get' prefix.
>>
>>> clipStringIfNecessary method name better reflects the method
>>> operation than the proposed one.
>>     The 'necessary' word is vague in this case. Is there any need to
>> clip a string if it is not necessary?
>>     The method description gives the explanation in which case the
>> string will be clipped.
>>
>>  Thanks,
>>  Alexandr.
>>
>>> This is an utility static API and we don't need to follow JavaBeans
>>> naming conventions here.
>>>
>>> --Semyon
>>>
>>>
>>> On 1/13/2016 6:03 PM, Alexander Scherbatiy wrote:
>>>>
>>>>   Hello,
>>>>
>>>>   Could you review the updated fix:
>>>>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.05/
>>>>
>>>>   - the methods description are updated to mention a component
>>>> numeric shaper and non-print graphics context
>>>>   - @since tag value is updated to 9
>>>>
>>>>  Thanks,
>>>>  Alexandr.
>>>>
>>>> On 1/12/2016 10:42 PM, Philip Race wrote:
>>>>> @since needs to be just "9" as of the updated verona versioning
>>>>> scheme.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> I see that you've added the next clarifications to the methods specs:
>>>>>>
>>>>>> > draws string/returns width ... using text properties and
>>>>>> anti-aliasing hints from the provided component
>>>>>>
>>>>>> It still seems too brief and even incorrect for getStringWidth().
>>>>>>
>>>>>> For drawString():
>>>>>>
>>>>>> For non-printing case I would write:
>>>>>>
>>>>>> Sets the anti-aliasing rendering hints to the Graphics object if
>>>>>> those are specified in the component properties. Then the string
>>>>>> is drawn using the provided Graphics object with the numeric
>>>>>> shaper taken into account if it is defined for the component.
>>>>>>
>>>>>> Please consider the printing case...
>>>>>>
>>>>>> For getStringWidth():
>>>>>>
>>>>>> Did not get which anti-aliasing hints it takes into account while
>>>>>> there is no Graphics in the params list...
>>>>>> On the contrary, it does not take into account the rendering context.
>>>>>> My suggestion:
>>>>>>
>>>>>> Returns string pixel width by the provided font metrics and
>>>>>> according to the numeric shaper if it is defined for the component.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> For
>>>>>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>  Hello,
>>>>>>>
>>>>>>>  Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>>>>>
>>>>>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>
>>>>>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>>>>>
>>>>>>>> * The {@code underlinedIndex} parameter points to a char value
>>>>>>>> (Unicode code unit) in the
>>>>>>>> * given string.
>>>>>>>>
>>>>>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>>>>>
>>>>>>>>
>>>>>>>> And I suggest using "fits" instead of "can fit" in @return for
>>>>>>>> getClippedString() and rephrasing the conditions where empty
>>>>>>>> string is returned:
>>>>>>>>
>>>>>>>> * @return the clipped string that fits in the provided space, an
>>>>>>>> empty
>>>>>>>> *         string if the given string argument is {@code null} or
>>>>>>>> empty.
>>>>>>>
>>>>>>>    The fix is updated according to the provided comments.
>>>>>>>
>>>>>>>    Thanks,
>>>>>>>    Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey
>>>>>>>>
>>>>>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>>>>>
>>>>>>>>> - methods description is updated to mention used text
>>>>>>>>> properties and anti-aliasing hints from the provided component
>>>>>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>>>>>> - @since tag is added for the drawString() method
>>>>>>>>> - the description that some parameters may/must not be null is
>>>>>>>>> added
>>>>>>>>> - the test is updated to call the methods on EDT
>>>>>>>>> - the test is updated to check passed null arguments
>>>>>>>>>
>>>>>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>
>>>>>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Could you please also clarify whether underlinedIndex in
>>>>>>>>>> drawStringUnderlineCharAt refers to the char index in the string?
>>>>>>>>>>
>>>>>>>>>> The statement
>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>> units).
>>>>>>>>>> makes it unclear: underlinedIndex is an *index* or a *char*
>>>>>>>>>> (Unicode code point).
>>>>>>>>>
>>>>>>>>>  I updated it to "The underlined index points to a char value
>>>>>>>>> (Unicode code unit) in the given string."
>>>>>>>>>  The 'refers' word was used for a value at the given index.
>>>>>>>>>  However, I am not sure that the new variant is better.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> * Nothing is drawn for null string. No character is underlined
>>>>>>>>>> for the
>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>> the char value
>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>
>>>>>>>>>> I think it will be better to spell comparison operators, I
>>>>>>>>>> mean to use  "greater than" rather than ">=". And "length"
>>>>>>>>>> must be used instead of "width".
>>>>>>>>>>
>>>>>>>>>> I propose the following text:
>>>>>>>>>>
>>>>>>>>>> No character is underlined if the index is negative or greater
>>>>>>>>>> than the string length or if the char value specified at the
>>>>>>>>>> given index is in the low-surrogate range.
>>>>>>>>>>
>>>>>>>>>> For the first part of condition, you can add clarification in
>>>>>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>>>>>  Updated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> For consistency, please remove the full stop in @return tag in
>>>>>>>>>> description of getClippedString.
>>>>>>>>>
>>>>>>>>> Updated.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alexey
>>>>>>>>>>
>>>>>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>>>>>
>>>>>>>>>>> The javadoc references for the #drawStringUnderlineCharAt and
>>>>>>>>>>> #getClippedString methods are moved after parameters
>>>>>>>>>>> description.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with
>>>>>>>>>>>> chars that have
>>>>>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>>>>>>> The whole glyph is underlined.
>>>>>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>>>>>>
>>>>>>>>>>>> The char value specified the the underlined index should
>>>>>>>>>>>> point to the high-surrogate range of a supplementary character.
>>>>>>>>>>>> I updated the javadoc for the
>>>>>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>> /**
>>>>>>>>>>>> * Draws the given string at the specified location underlining
>>>>>>>>>>>> * the specified character.
>>>>>>>>>>>> * <p>
>>>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>>>> units).
>>>>>>>>>>>> * If the char value specified at the given underlined index
>>>>>>>>>>>> is in
>>>>>>>>>>>> * the high-surrogate range and the char value at the
>>>>>>>>>>>> following index is in
>>>>>>>>>>>> * the low-surrogate range then the supplementary character
>>>>>>>>>>>> corresponding
>>>>>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>>>>>> * <p>
>>>>>>>>>>>> * Nothing is drawn for null string. No character is
>>>>>>>>>>>> underlined for the
>>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>>>> the char value
>>>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>>>>>> I don't remember or know how Swing resolves this but the
>>>>>>>>>>>>>> measurement ones
>>>>>>>>>>>>>> are not reliable since they do not take a Graphics
>>>>>>>>>>>>>> context, so you cannot
>>>>>>>>>>>>>> measure the string properly. You need a FontRenderContext
>>>>>>>>>>>>>> to measure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The provided methods use
>>>>>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method
>>>>>>>>>>>>> which returns the FontRenderContext associated with the
>>>>>>>>>>>>> component.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So as it stands these APIs do not appear suitable to be
>>>>>>>>>>>>>> made public as they
>>>>>>>>>>>>>> are not reliable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Whilst I could look at the code, if I instead just look at
>>>>>>>>>>>>>> the API, I am scratching my
>>>>>>>>>>>>>> head over :-
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> public static void drawString(JComponent c, Graphics g,
>>>>>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>>>>>> So I am supposing that there is optional information that
>>>>>>>>>>>>>> may be pulled from the
>>>>>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The optional information provided by the component is:
>>>>>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>>>>>> - antialiasing hints
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if
>>>>>>>>>>>>>> the index is code point
>>>>>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1
>>>>>>>>>>>>>> code point:glyph mapping.
>>>>>>>>>>>>> I will update this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are we sure that (any of) these really ought/need to be
>>>>>>>>>>>>>> public - particularly given the
>>>>>>>>>>>>>> resolution of
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>>>>>
>>>>>>>>>>>>> These methods are used by JDK L&Fs to draw text. The
>>>>>>>>>>>>> initial request was to provide public methods that can be
>>>>>>>>>>>>> used by a custom L&F to draw strings consistently with
>>>>>>>>>>>>> other L&Fs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> They are also designed to properly render text for
>>>>>>>>>>>>> printing. To do that they use call to internal
>>>>>>>>>>>>> ProxyPrintGraphics class to obtain the print graphics context.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Even if printing staff will be public, these methods are
>>>>>>>>>>>>> just utility methods (in the same way as other text methods
>>>>>>>>>>>>> in the javax.swing.text.Utilities class) that help easily
>>>>>>>>>>>>> to draw and print text in the same way as JDK L&Fs do that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt,
>>>>>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.


From javalists at cbfiddle.com  Sun Jan 17 04:19:46 2016
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sat, 16 Jan 2016 20:19:46 -0800
Subject: <Swing Dev> internal API usage: PopupFactory.setPopupType()
Message-ID: <C4079AA5-CDF2-423D-92AC-9E0C69D14CFD@cbfiddle.com>

I have submitted an RFE to make the functionality of PopupFactory.setPopupType() publicly available.

JI-9028692

Regards,

  Alan

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

From avik.niyogi at oracle.com  Mon Jan 18 06:04:19 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 18 Jan 2016 11:34:19 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <5697DA64.40501@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>
Message-ID: <9FC2C3E2-1118-4F40-9A31-C1B01C0FF94D@oracle.com>

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/>

With Regards,
Avik Niyogi

> On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov <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/>
>> 
>> 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/~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/~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>>
>>>>>>> <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 <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/~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/>
>>>>>>>>>> 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/>
>>>>>>>>>>>> 
>>>>>>>>>>>> *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/20160118/33721126/attachment.html>

From semyon.sadetsky at oracle.com  Mon Jan 18 07:09:41 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 18 Jan 2016 10:09:41 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56996685.1070006@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>
	<5699253C.3030800@oracle.com> <56996685.1070006@oracle.com>
Message-ID: <569C8FB5.8050207@oracle.com>



On 1/16/2016 12:37 AM, Sergey Bylokhov wrote:
> On 15/01/16 19:58, Semyon Sadetsky wrote:
>>>> getStringWidth(): It is worth to add a note that the returning value
>>>> is not the exact visual string width because rendering hints are not
>>>> taken into account.
>
> It depends, the current description is correct. Default font metrics 
> of the component should take into account KEY_TEXT_ANTIALIASING property.
> The width of the string will be calculated by the passed font metrics. 
> If the font metrics differs from the metrics of the graphics object 
> then results will be different, if the metrics will be the same then 
> results will be the same.
>
> If these methods will produce inconsistent result when we will get a 
> bugs when the size of the component(which depends from the font) will 
> differ from their appearance on the screen.
Then, this: 
https://docs.oracle.com/javase/tutorial/2d/text/measuringtext.html is 
incorrect?
>
>
>>>     I thought that rendering hints can affect a string quaility and
>>> drawing performance. Do they really change the visual string width?
>> Please look how the font anti-aliasing works:
>> https://upload.wikimedia.org/wikipedia/commons/3/34/A_aliased_and_simple.jpg 
>>
>>
>> For example if user cut this width from a drawing artifacts may be
>> remained.
>>>>
>>>> What was the reason for renaming clipStringIfNecessary() and
>>>> stringWidth()?
>>>>
>>>> stringWidth() is a standard method name to get the advance in all
>>>> other JDK interfaces.
>>>     The 'get' prefix is used here not because it is JavaBeans
>>> requirements but because of the method name conventions.
>>>     For example, the same Utilities class contains
>>> getTabbedTextWidth() method which also has the 'get' prefix.
>>>
>>>> clipStringIfNecessary method name better reflects the method
>>>> operation than the proposed one.
>>>     The 'necessary' word is vague in this case. Is there any need to
>>> clip a string if it is not necessary?
>>>     The method description gives the explanation in which case the
>>> string will be clipped.
>>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>>> This is an utility static API and we don't need to follow JavaBeans
>>>> naming conventions here.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 1/13/2016 6:03 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>>   Hello,
>>>>>
>>>>>   Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.05/
>>>>>
>>>>>   - the methods description are updated to mention a component
>>>>> numeric shaper and non-print graphics context
>>>>>   - @since tag value is updated to 9
>>>>>
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>>
>>>>> On 1/12/2016 10:42 PM, Philip Race wrote:
>>>>>> @since needs to be just "9" as of the updated verona versioning
>>>>>> scheme.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>>>>>>> Hi Alexander,
>>>>>>>
>>>>>>> I see that you've added the next clarifications to the methods 
>>>>>>> specs:
>>>>>>>
>>>>>>> > draws string/returns width ... using text properties and
>>>>>>> anti-aliasing hints from the provided component
>>>>>>>
>>>>>>> It still seems too brief and even incorrect for getStringWidth().
>>>>>>>
>>>>>>> For drawString():
>>>>>>>
>>>>>>> For non-printing case I would write:
>>>>>>>
>>>>>>> Sets the anti-aliasing rendering hints to the Graphics object if
>>>>>>> those are specified in the component properties. Then the string
>>>>>>> is drawn using the provided Graphics object with the numeric
>>>>>>> shaper taken into account if it is defined for the component.
>>>>>>>
>>>>>>> Please consider the printing case...
>>>>>>>
>>>>>>> For getStringWidth():
>>>>>>>
>>>>>>> Did not get which anti-aliasing hints it takes into account while
>>>>>>> there is no Graphics in the params list...
>>>>>>> On the contrary, it does not take into account the rendering 
>>>>>>> context.
>>>>>>> My suggestion:
>>>>>>>
>>>>>>> Returns string pixel width by the provided font metrics and
>>>>>>> according to the numeric shaper if it is defined for the component.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>> For
>>>>>>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>>  Hello,
>>>>>>>>
>>>>>>>>  Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>>>>>>
>>>>>>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>>>>>>> Hi Alexandr,
>>>>>>>>>
>>>>>>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>>>>>>
>>>>>>>>> * The {@code underlinedIndex} parameter points to a char value
>>>>>>>>> (Unicode code unit) in the
>>>>>>>>> * given string.
>>>>>>>>>
>>>>>>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And I suggest using "fits" instead of "can fit" in @return for
>>>>>>>>> getClippedString() and rephrasing the conditions where empty
>>>>>>>>> string is returned:
>>>>>>>>>
>>>>>>>>> * @return the clipped string that fits in the provided space, an
>>>>>>>>> empty
>>>>>>>>> *         string if the given string argument is {@code null} or
>>>>>>>>> empty.
>>>>>>>>
>>>>>>>>    The fix is updated according to the provided comments.
>>>>>>>>
>>>>>>>>    Thanks,
>>>>>>>>    Alexandr.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alexey
>>>>>>>>>
>>>>>>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>>>>>>
>>>>>>>>>> - methods description is updated to mention used text
>>>>>>>>>> properties and anti-aliasing hints from the provided component
>>>>>>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>>>>>>> - @since tag is added for the drawString() method
>>>>>>>>>> - the description that some parameters may/must not be null is
>>>>>>>>>> added
>>>>>>>>>> - the test is updated to call the methods on EDT
>>>>>>>>>> - the test is updated to check passed null arguments
>>>>>>>>>>
>>>>>>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>
>>>>>>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Could you please also clarify whether underlinedIndex in
>>>>>>>>>>> drawStringUnderlineCharAt refers to the char index in the 
>>>>>>>>>>> string?
>>>>>>>>>>>
>>>>>>>>>>> The statement
>>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>>> units).
>>>>>>>>>>> makes it unclear: underlinedIndex is an *index* or a *char*
>>>>>>>>>>> (Unicode code point).
>>>>>>>>>>
>>>>>>>>>>  I updated it to "The underlined index points to a char value
>>>>>>>>>> (Unicode code unit) in the given string."
>>>>>>>>>>  The 'refers' word was used for a value at the given index.
>>>>>>>>>>  However, I am not sure that the new variant is better.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> * Nothing is drawn for null string. No character is underlined
>>>>>>>>>>> for the
>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>>> the char value
>>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>>
>>>>>>>>>>> I think it will be better to spell comparison operators, I
>>>>>>>>>>> mean to use  "greater than" rather than ">=". And "length"
>>>>>>>>>>> must be used instead of "width".
>>>>>>>>>>>
>>>>>>>>>>> I propose the following text:
>>>>>>>>>>>
>>>>>>>>>>> No character is underlined if the index is negative or greater
>>>>>>>>>>> than the string length or if the char value specified at the
>>>>>>>>>>> given index is in the low-surrogate range.
>>>>>>>>>>>
>>>>>>>>>>> For the first part of condition, you can add clarification in
>>>>>>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>>>>>>  Updated.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For consistency, please remove the full stop in @return tag in
>>>>>>>>>>> description of getClippedString.
>>>>>>>>>>
>>>>>>>>>> Updated.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alexey
>>>>>>>>>>>
>>>>>>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>>>>>>
>>>>>>>>>>>> The javadoc references for the #drawStringUnderlineCharAt and
>>>>>>>>>>>> #getClippedString methods are moved after parameters
>>>>>>>>>>>> description.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with
>>>>>>>>>>>>> chars that have
>>>>>>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>>>>>>>> The whole glyph is underlined.
>>>>>>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The char value specified the the underlined index should
>>>>>>>>>>>>> point to the high-surrogate range of a supplementary 
>>>>>>>>>>>>> character.
>>>>>>>>>>>>> I updated the javadoc for the
>>>>>>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>>> /**
>>>>>>>>>>>>> * Draws the given string at the specified location 
>>>>>>>>>>>>> underlining
>>>>>>>>>>>>> * the specified character.
>>>>>>>>>>>>> * <p>
>>>>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>>>>> units).
>>>>>>>>>>>>> * If the char value specified at the given underlined index
>>>>>>>>>>>>> is in
>>>>>>>>>>>>> * the high-surrogate range and the char value at the
>>>>>>>>>>>>> following index is in
>>>>>>>>>>>>> * the low-surrogate range then the supplementary character
>>>>>>>>>>>>> corresponding
>>>>>>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>>>>>>> * <p>
>>>>>>>>>>>>> * Nothing is drawn for null string. No character is
>>>>>>>>>>>>> underlined for the
>>>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>>>>> the char value
>>>>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>>>>>>> I don't remember or know how Swing resolves this but the
>>>>>>>>>>>>>>> measurement ones
>>>>>>>>>>>>>>> are not reliable since they do not take a Graphics
>>>>>>>>>>>>>>> context, so you cannot
>>>>>>>>>>>>>>> measure the string properly. You need a FontRenderContext
>>>>>>>>>>>>>>> to measure.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The provided methods use
>>>>>>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method
>>>>>>>>>>>>>> which returns the FontRenderContext associated with the
>>>>>>>>>>>>>> component.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So as it stands these APIs do not appear suitable to be
>>>>>>>>>>>>>>> made public as they
>>>>>>>>>>>>>>> are not reliable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Whilst I could look at the code, if I instead just look at
>>>>>>>>>>>>>>> the API, I am scratching my
>>>>>>>>>>>>>>> head over :-
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> public static void drawString(JComponent c, Graphics g,
>>>>>>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>>>>>>> So I am supposing that there is optional information that
>>>>>>>>>>>>>>> may be pulled from the
>>>>>>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The optional information provided by the component is:
>>>>>>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>>>>>>> - antialiasing hints
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if
>>>>>>>>>>>>>>> the index is code point
>>>>>>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1
>>>>>>>>>>>>>>> code point:glyph mapping.
>>>>>>>>>>>>>> I will update this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Are we sure that (any of) these really ought/need to be
>>>>>>>>>>>>>>> public - particularly given the
>>>>>>>>>>>>>>> resolution of
>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> These methods are used by JDK L&Fs to draw text. The
>>>>>>>>>>>>>> initial request was to provide public methods that can be
>>>>>>>>>>>>>> used by a custom L&F to draw strings consistently with
>>>>>>>>>>>>>> other L&Fs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> They are also designed to properly render text for
>>>>>>>>>>>>>> printing. To do that they use call to internal
>>>>>>>>>>>>>> ProxyPrintGraphics class to obtain the print graphics 
>>>>>>>>>>>>>> context.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Even if printing staff will be public, these methods are
>>>>>>>>>>>>>> just utility methods (in the same way as other text methods
>>>>>>>>>>>>>> in the javax.swing.text.Utilities class) that help easily
>>>>>>>>>>>>>> to draw and print text in the same way as JDK L&Fs do that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt,
>>>>>>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
>



From semyon.sadetsky at oracle.com  Mon Jan 18 07:15:50 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 18 Jan 2016 10:15:50 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <569963B6.2050604@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>
Message-ID: <569C9126.1090207@oracle.com>



On 1/16/2016 12:25 AM, Sergey Bylokhov wrote:
> On 15/01/16 19:31, Alexander Scherbatiy wrote:
>>    - the description of the getClippedString method is updated to
>> mention that ellipsis is added at the end of the clipped string
>
> It seems that we go far far away from the description of mission of 
> this method to the description of its implementation. The goal of the 
> method is possibility for clients to use the same draw functions which 
> are used by our L&F so the custom components will look the same as 
> standard components. Description that something is added to the end of 
> the clipped string, the exact list of client properties seems 
> unnecessary?
"goal of the method is possibility for clients to use the same draw 
functions which are used by our L&F"...
then this sentence should be added to those methods docs instead.
But their should not be described as simply "draw string" or "clip string".
> Moreover it seems that if the requested space is really small we can 
> return ellipses which will occupy more space than requested.(i guess 
> this is a separate bug)
>
>>
>> On 1/15/2016 1:16 PM, Semyon Sadetsky wrote:
>>> Hi,
>>>
>>> getClippedString() : It is worth to explain that 3dots are added at
>>> end or returned.
>>>
>>> getStringWidth(): It is worth to add a note that the returning value
>>> is not the exact visual string width because rendering hints are not
>>> taken into account.
>>      I thought that rendering hints can affect a string quaility and
>> drawing performance. Do they really change the visual string width?
>>>
>>> What was the reason for renaming clipStringIfNecessary() and
>>> stringWidth()?
>>>
>>> stringWidth() is a standard method name to get the advance in all
>>> other JDK interfaces.
>>      The 'get' prefix is used here not because it is JavaBeans
>> requirements but because of the method name conventions.
>>      For example, the same Utilities class contains getTabbedTextWidth()
>> method which also has the 'get' prefix.
>>
>>> clipStringIfNecessary method name better reflects the method operation
>>> than the proposed one.
>>      The 'necessary' word is vague in this case. Is there any need to
>> clip a string if it is not necessary?
>>      The method description gives the explanation in which case the
>> string will be clipped.
>>
>>   Thanks,
>>   Alexandr.
>>
>>> This is an utility static API and we don't need to follow JavaBeans
>>> naming conventions here.
>>>
>>> --Semyon
>>>
>>>
>>> On 1/13/2016 6:03 PM, Alexander Scherbatiy wrote:
>>>>
>>>>   Hello,
>>>>
>>>>   Could you review the updated fix:
>>>>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.05/
>>>>
>>>>   - the methods description are updated to mention a component
>>>> numeric shaper and non-print graphics context
>>>>   - @since tag value is updated to 9
>>>>
>>>>  Thanks,
>>>>  Alexandr.
>>>>
>>>> On 1/12/2016 10:42 PM, Philip Race wrote:
>>>>> @since needs to be just "9" as of the updated verona versioning 
>>>>> scheme.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> I see that you've added the next clarifications to the methods 
>>>>>> specs:
>>>>>>
>>>>>> > draws string/returns width ... using text properties and
>>>>>> anti-aliasing hints from the provided component
>>>>>>
>>>>>> It still seems too brief and even incorrect for getStringWidth().
>>>>>>
>>>>>> For drawString():
>>>>>>
>>>>>> For non-printing case I would write:
>>>>>>
>>>>>> Sets the anti-aliasing rendering hints to the Graphics object if
>>>>>> those are specified in the component properties. Then the string is
>>>>>> drawn using the provided Graphics object with the numeric shaper
>>>>>> taken into account if it is defined for the component.
>>>>>>
>>>>>> Please consider the printing case...
>>>>>>
>>>>>> For getStringWidth():
>>>>>>
>>>>>> Did not get which anti-aliasing hints it takes into account while
>>>>>> there is no Graphics in the params list...
>>>>>> On the contrary, it does not take into account the rendering 
>>>>>> context.
>>>>>> My suggestion:
>>>>>>
>>>>>> Returns string pixel width by the provided font metrics and
>>>>>> according to the numeric shaper if it is defined for the component.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> For
>>>>>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>  Hello,
>>>>>>>
>>>>>>>  Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>>>>>
>>>>>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>
>>>>>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>>>>>
>>>>>>>> * The {@code underlinedIndex} parameter points to a char value
>>>>>>>> (Unicode code unit) in the
>>>>>>>> * given string.
>>>>>>>>
>>>>>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>>>>>
>>>>>>>>
>>>>>>>> And I suggest using "fits" instead of "can fit" in @return for
>>>>>>>> getClippedString() and rephrasing the conditions where empty
>>>>>>>> string is returned:
>>>>>>>>
>>>>>>>> * @return the clipped string that fits in the provided space, an
>>>>>>>> empty
>>>>>>>> *         string if the given string argument is {@code null} or
>>>>>>>> empty.
>>>>>>>
>>>>>>>    The fix is updated according to the provided comments.
>>>>>>>
>>>>>>>    Thanks,
>>>>>>>    Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey
>>>>>>>>
>>>>>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>>>>>
>>>>>>>>> - methods description is updated to mention used text properties
>>>>>>>>> and anti-aliasing hints from the provided component
>>>>>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>>>>>> - @since tag is added for the drawString() method
>>>>>>>>> - the description that some parameters may/must not be null is
>>>>>>>>> added
>>>>>>>>> - the test is updated to call the methods on EDT
>>>>>>>>> - the test is updated to check passed null arguments
>>>>>>>>>
>>>>>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>
>>>>>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Could you please also clarify whether underlinedIndex in
>>>>>>>>>> drawStringUnderlineCharAt refers to the char index in the 
>>>>>>>>>> string?
>>>>>>>>>>
>>>>>>>>>> The statement
>>>>>>>>>> * The underlined index refers to char values (Unicode code 
>>>>>>>>>> units).
>>>>>>>>>> makes it unclear: underlinedIndex is an *index* or a *char*
>>>>>>>>>> (Unicode code point).
>>>>>>>>>
>>>>>>>>>  I updated it to "The underlined index points to a char value
>>>>>>>>> (Unicode code unit) in the given string."
>>>>>>>>>  The 'refers' word was used for a value at the given index.
>>>>>>>>>  However, I am not sure that the new variant is better.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> * Nothing is drawn for null string. No character is underlined
>>>>>>>>>> for the
>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if the
>>>>>>>>>> char value
>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>
>>>>>>>>>> I think it will be better to spell comparison operators, I mean
>>>>>>>>>> to use  "greater than" rather than ">=". And "length" must be
>>>>>>>>>> used instead of "width".
>>>>>>>>>>
>>>>>>>>>> I propose the following text:
>>>>>>>>>>
>>>>>>>>>> No character is underlined if the index is negative or greater
>>>>>>>>>> than the string length or if the char value specified at the
>>>>>>>>>> given index is in the low-surrogate range.
>>>>>>>>>>
>>>>>>>>>> For the first part of condition, you can add clarification in
>>>>>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>>>>>  Updated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> For consistency, please remove the full stop in @return tag in
>>>>>>>>>> description of getClippedString.
>>>>>>>>>
>>>>>>>>> Updated.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alexey
>>>>>>>>>>
>>>>>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>>>>>
>>>>>>>>>>> The javadoc references for the #drawStringUnderlineCharAt and
>>>>>>>>>>> #getClippedString methods are moved after parameters 
>>>>>>>>>>> description.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with
>>>>>>>>>>>> chars that have
>>>>>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>>>>>>> The whole glyph is underlined.
>>>>>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>>>>>>
>>>>>>>>>>>> The char value specified the the underlined index should
>>>>>>>>>>>> point to the high-surrogate range of a supplementary 
>>>>>>>>>>>> character.
>>>>>>>>>>>> I updated the javadoc for the
>>>>>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>> /**
>>>>>>>>>>>> * Draws the given string at the specified location underlining
>>>>>>>>>>>> * the specified character.
>>>>>>>>>>>> * <p>
>>>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>>>> units).
>>>>>>>>>>>> * If the char value specified at the given underlined index
>>>>>>>>>>>> is in
>>>>>>>>>>>> * the high-surrogate range and the char value at the
>>>>>>>>>>>> following index is in
>>>>>>>>>>>> * the low-surrogate range then the supplementary character
>>>>>>>>>>>> corresponding
>>>>>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>>>>>> * <p>
>>>>>>>>>>>> * Nothing is drawn for null string. No character is
>>>>>>>>>>>> underlined for the
>>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>>>> the char value
>>>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>>>>>> I don't remember or know how Swing resolves this but the
>>>>>>>>>>>>>> measurement ones
>>>>>>>>>>>>>> are not reliable since they do not take a Graphics context,
>>>>>>>>>>>>>> so you cannot
>>>>>>>>>>>>>> measure the string properly. You need a FontRenderContext
>>>>>>>>>>>>>> to measure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The provided methods use
>>>>>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method
>>>>>>>>>>>>> which returns the FontRenderContext associated with the
>>>>>>>>>>>>> component.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So as it stands these APIs do not appear suitable to be
>>>>>>>>>>>>>> made public as they
>>>>>>>>>>>>>> are not reliable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Whilst I could look at the code, if I instead just look at
>>>>>>>>>>>>>> the API, I am scratching my
>>>>>>>>>>>>>> head over :-
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> public static void drawString(JComponent c, Graphics g,
>>>>>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>>>>>> So I am supposing that there is optional information that
>>>>>>>>>>>>>> may be pulled from the
>>>>>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The optional information provided by the component is:
>>>>>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>>>>>> - antialiasing hints
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if
>>>>>>>>>>>>>> the index is code point
>>>>>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1
>>>>>>>>>>>>>> code point:glyph mapping.
>>>>>>>>>>>>> I will update this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are we sure that (any of) these really ought/need to be
>>>>>>>>>>>>>> public - particularly given the
>>>>>>>>>>>>>> resolution of 
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>>>>>
>>>>>>>>>>>>> These methods are used by JDK L&Fs to draw text. The initial
>>>>>>>>>>>>> request was to provide public methods that can be used by a
>>>>>>>>>>>>> custom L&F to draw strings consistently with other L&Fs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> They are also designed to properly render text for printing.
>>>>>>>>>>>>> To do that they use call to internal ProxyPrintGraphics
>>>>>>>>>>>>> class to obtain the print graphics context.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Even if printing staff will be public, these methods are
>>>>>>>>>>>>> just utility methods (in the same way as other text methods
>>>>>>>>>>>>> in the javax.swing.text.Utilities class) that help easily to
>>>>>>>>>>>>> draw and print text in the same way as JDK L&Fs do that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt,
>>>>>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>
>



From avik.niyogi at oracle.com  Mon Jan 18 09:31:38 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 18 Jan 2016 15:01:38 +0530
Subject: <Swing Dev> Review Request of 8146321: [macosx] JInternalFrame
	frame icon in wrong position on Mac L&F if icon is not ImageIcon
In-Reply-To: <BEB3BF05-B31A-4595-BCBB-E9DC915AED19@oracle.com>
References: <431B2640-2D19-4EFC-824E-52AE3D25D2D8@oracle.com>
	<56973AEA.1040308@oracle.com>
	<BEB3BF05-B31A-4595-BCBB-E9DC915AED19@oracle.com>
Message-ID: <13420C14-4119-4EF4-A037-1F4C2BF87E3C@oracle.com>

Hi Sergey,

Please review the webrev taking inputs as per the discussion before:
http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/>

With Regards,
Avik Niyogi

> On 14-Jan-2016, at 12:55 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi Sergey,
> I have verified it with the test case as well. If a test case overrides these methods to imply a change with icons larger than 16x16 it will show that for ImageIcon and Icon as before. The resize of ImageIcon is only in case it has an image file that it will try to fit. I had a similar query myself and have found out that getImage() exists for ImageIcon class only and not Icon class.
> Example:
> private static void createImageIconUI(final String lookAndFeelString)
>             throws Exception {
>         SwingUtilities.invokeAndWait(new Runnable() {
>             @Override
>             public void run() {
>                 desktopPane = new JDesktopPane();
>                 internalFrame = new JInternalFrame();
>                 frame = new JFrame();
>                 internalFrame.setTitle(lookAndFeelString);
>                 titleImageIcon = new ImageIcon() {
>                     @Override
>                     public int getIconWidth() {
>                         return 16;
>                     }
> 
>                     @Override
>                     public int getIconHeight() {
>                         return 16;
>                     }
> 
>                     @Override
>                     public void paintIcon(
>                             Component c, Graphics g, int x, int y) {
>                         g.setColor(java.awt.Color.black);
>                         g.fillRect(x, y, 50, 50);
>                     }
>                 };
>                 internalFrame.setFrameIcon(titleImageIcon);
>                 internalFrame.setSize(500, 200);
>                 internalFrame.setVisible(true);
>                 desktopPane.add(internalFrame);
> 
>                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>                 frame.getContentPane().setLayout(new BorderLayout());
>                 frame.getContentPane().add(desktopPane, "Center");
>                 frame.setSize(500, 500);
>                 frame.setLocationRelativeTo(null);
>                 frame.setVisible(true);
>                 frame.toFront();
>             }
>         });
>     }
> In this case the ImageIcon will NOT be resized to 16 x 16 even before my fix was implemented. That resize as shown in code is only for Image files to fit in default ImageIcon size as returned from the getIconHeight() and getIconWidth() methods. If user changes the ImageIcon size as in the example, that is upto to user to choose to do so and no control exists to prevent that. So, with or without my fix, this behaviour will be same for ImageIcon and Icon custom instances.
> Hope this clarifies the query. 
> 
> With Regards,
> Avik Niyogi
> 
>> On 14-Jan-2016, at 11:36 am, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>> 
>> Hi, Avik.
>> In the fix you update getIconWidth() and getIconHeight, so now we take the Icon into account. but it seems if the Icon is bigger that the maximum size it will not be resided to 16x16, right?
>> 
>> On 14/01/16 07:49, Avik Niyogi wrote:
>>> Hi All,
>>> 
>>> Kindly review the bug fix for JDK 9.
>>> 
>>> *Bug:*
>>> https://bugs.openjdk.java.net/browse/JDK-8146321 <https://bugs.openjdk.java.net/browse/JDK-8146321>
>>> 
>>> *Webrev:*
>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/
>>> 
>>> *Issue:*
>>> Under the Mac Look&Feel, if an icon type other than an ImageIcon is used
>>> in JInternalFrame.setFrameIcon(),
>>> the icon will show up in the wrong position.
>>> 
>>> *Cause:*
>>> the "instanceof Icon" was not checked for. Also, customs ImageIcon with
>>> color fill (and no image URL) which would
>>> have resulted in null value for resized ImageIcon image was not well
>>> handled.
>>> 
>>> *Fix:*
>>> All places in Aqua LAF where "instanceof Icon? (and not just ImageIcon
>>> class) is required,
>>> inputs were added after significant analyses.
>>> Check for null for getImage was done to remove a Null Pointer Exception.
>>> 
>>> With Regards,
>>> Avik Niyogi
>> 
>> 
>> -- 
>> Best regards, Sergey.
> 

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

From prem.balakrishnan at oracle.com  Mon Jan 18 10:46:02 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Mon, 18 Jan 2016 02:46:02 -0800 (PST)
Subject: <Swing Dev> Review Request for Bug 8146320 JTextField ignores
 setPreferredSize when having columns
Message-ID: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>

Hi,

Please review fix for JDK9,

 

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

Webrev: http://cr.openjdk.java.net/~rchamyal/prem/8146320/webrev.00/

 

Issue:

JTextField ignores setPreferredSize when having columns

 

Cause:

JTextField setPreferredSize is not actually ignored , when column value is set>0.

While retrieving the values set using getPreferredSize(), wrong values were returned.

 

Fix:

Check added, if Column>0 and if Preferred size is not set after setting columns, while retrieving values.

 

Regards,
Prem

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

From Sergey.Bylokhov at oracle.com  Mon Jan 18 14:37:25 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Jan 2016 17:37:25 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <569C8FB5.8050207@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>
	<5699253C.3030800@oracle.com> <56996685.1070006@oracle.com>
	<569C8FB5.8050207@oracle.com>
Message-ID: <569CF8A5.2060807@oracle.com>

On 18/01/16 10:09, Semyon Sadetsky wrote:
>
>
> On 1/16/2016 12:37 AM, Sergey Bylokhov wrote:
>> On 15/01/16 19:58, Semyon Sadetsky wrote:
>>>>> getStringWidth(): It is worth to add a note that the returning value
>>>>> is not the exact visual string width because rendering hints are not
>>>>> taken into account.
>>
>> It depends, the current description is correct. Default font metrics
>> of the component should take into account KEY_TEXT_ANTIALIASING property.
>> The width of the string will be calculated by the passed font metrics.
>> If the font metrics differs from the metrics of the graphics object
>> then results will be different, if the metrics will be the same then
>> results will be the same.
>>
>> If these methods will produce inconsistent result when we will get a
>> bugs when the size of the component(which depends from the font) will
>> differ from their appearance on the screen.
> Then, this:
> https://docs.oracle.com/javase/tutorial/2d/text/measuringtext.html is
> incorrect?

No, information in this link is correct. Note that example uses 
FontMetrics from the graphics object, this is possible when we draw the 
text, but in case of Swing the layout of the components occurs before we 
try to draw a component.

>>
>>
>>>>     I thought that rendering hints can affect a string quaility and
>>>> drawing performance. Do they really change the visual string width?
>>> Please look how the font anti-aliasing works:
>>> https://upload.wikimedia.org/wikipedia/commons/3/34/A_aliased_and_simple.jpg
>>>
>>>
>>> For example if user cut this width from a drawing artifacts may be
>>> remained.
>>>>>
>>>>> What was the reason for renaming clipStringIfNecessary() and
>>>>> stringWidth()?
>>>>>
>>>>> stringWidth() is a standard method name to get the advance in all
>>>>> other JDK interfaces.
>>>>     The 'get' prefix is used here not because it is JavaBeans
>>>> requirements but because of the method name conventions.
>>>>     For example, the same Utilities class contains
>>>> getTabbedTextWidth() method which also has the 'get' prefix.
>>>>
>>>>> clipStringIfNecessary method name better reflects the method
>>>>> operation than the proposed one.
>>>>     The 'necessary' word is vague in this case. Is there any need to
>>>> clip a string if it is not necessary?
>>>>     The method description gives the explanation in which case the
>>>> string will be clipped.
>>>>
>>>>  Thanks,
>>>>  Alexandr.
>>>>
>>>>> This is an utility static API and we don't need to follow JavaBeans
>>>>> naming conventions here.
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 1/13/2016 6:03 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>   Hello,
>>>>>>
>>>>>>   Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.05/
>>>>>>
>>>>>>   - the methods description are updated to mention a component
>>>>>> numeric shaper and non-print graphics context
>>>>>>   - @since tag value is updated to 9
>>>>>>
>>>>>>  Thanks,
>>>>>>  Alexandr.
>>>>>>
>>>>>> On 1/12/2016 10:42 PM, Philip Race wrote:
>>>>>>> @since needs to be just "9" as of the updated verona versioning
>>>>>>> scheme.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>>>>>>>> Hi Alexander,
>>>>>>>>
>>>>>>>> I see that you've added the next clarifications to the methods
>>>>>>>> specs:
>>>>>>>>
>>>>>>>> > draws string/returns width ... using text properties and
>>>>>>>> anti-aliasing hints from the provided component
>>>>>>>>
>>>>>>>> It still seems too brief and even incorrect for getStringWidth().
>>>>>>>>
>>>>>>>> For drawString():
>>>>>>>>
>>>>>>>> For non-printing case I would write:
>>>>>>>>
>>>>>>>> Sets the anti-aliasing rendering hints to the Graphics object if
>>>>>>>> those are specified in the component properties. Then the string
>>>>>>>> is drawn using the provided Graphics object with the numeric
>>>>>>>> shaper taken into account if it is defined for the component.
>>>>>>>>
>>>>>>>> Please consider the printing case...
>>>>>>>>
>>>>>>>> For getStringWidth():
>>>>>>>>
>>>>>>>> Did not get which anti-aliasing hints it takes into account while
>>>>>>>> there is no Graphics in the params list...
>>>>>>>> On the contrary, it does not take into account the rendering
>>>>>>>> context.
>>>>>>>> My suggestion:
>>>>>>>>
>>>>>>>> Returns string pixel width by the provided font metrics and
>>>>>>>> according to the numeric shaper if it is defined for the component.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> For
>>>>>>>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>>  Hello,
>>>>>>>>>
>>>>>>>>>  Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>>>>>>>
>>>>>>>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>
>>>>>>>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>>>>>>>
>>>>>>>>>> * The {@code underlinedIndex} parameter points to a char value
>>>>>>>>>> (Unicode code unit) in the
>>>>>>>>>> * given string.
>>>>>>>>>>
>>>>>>>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And I suggest using "fits" instead of "can fit" in @return for
>>>>>>>>>> getClippedString() and rephrasing the conditions where empty
>>>>>>>>>> string is returned:
>>>>>>>>>>
>>>>>>>>>> * @return the clipped string that fits in the provided space, an
>>>>>>>>>> empty
>>>>>>>>>> *         string if the given string argument is {@code null} or
>>>>>>>>>> empty.
>>>>>>>>>
>>>>>>>>>    The fix is updated according to the provided comments.
>>>>>>>>>
>>>>>>>>>    Thanks,
>>>>>>>>>    Alexandr.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alexey
>>>>>>>>>>
>>>>>>>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>>>>>>>
>>>>>>>>>>> - methods description is updated to mention used text
>>>>>>>>>>> properties and anti-aliasing hints from the provided component
>>>>>>>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>>>>>>>> - @since tag is added for the drawString() method
>>>>>>>>>>> - the description that some parameters may/must not be null is
>>>>>>>>>>> added
>>>>>>>>>>> - the test is updated to call the methods on EDT
>>>>>>>>>>> - the test is updated to check passed null arguments
>>>>>>>>>>>
>>>>>>>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>
>>>>>>>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Could you please also clarify whether underlinedIndex in
>>>>>>>>>>>> drawStringUnderlineCharAt refers to the char index in the
>>>>>>>>>>>> string?
>>>>>>>>>>>>
>>>>>>>>>>>> The statement
>>>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>>>> units).
>>>>>>>>>>>> makes it unclear: underlinedIndex is an *index* or a *char*
>>>>>>>>>>>> (Unicode code point).
>>>>>>>>>>>
>>>>>>>>>>>  I updated it to "The underlined index points to a char value
>>>>>>>>>>> (Unicode code unit) in the given string."
>>>>>>>>>>>  The 'refers' word was used for a value at the given index.
>>>>>>>>>>>  However, I am not sure that the new variant is better.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> * Nothing is drawn for null string. No character is underlined
>>>>>>>>>>>> for the
>>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>>>> the char value
>>>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>>>
>>>>>>>>>>>> I think it will be better to spell comparison operators, I
>>>>>>>>>>>> mean to use  "greater than" rather than ">=". And "length"
>>>>>>>>>>>> must be used instead of "width".
>>>>>>>>>>>>
>>>>>>>>>>>> I propose the following text:
>>>>>>>>>>>>
>>>>>>>>>>>> No character is underlined if the index is negative or greater
>>>>>>>>>>>> than the string length or if the char value specified at the
>>>>>>>>>>>> given index is in the low-surrogate range.
>>>>>>>>>>>>
>>>>>>>>>>>> For the first part of condition, you can add clarification in
>>>>>>>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>>>>>>>  Updated.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> For consistency, please remove the full stop in @return tag in
>>>>>>>>>>>> description of getClippedString.
>>>>>>>>>>>
>>>>>>>>>>> Updated.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Alexey
>>>>>>>>>>>>
>>>>>>>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>>>>>>>
>>>>>>>>>>>>> The javadoc references for the #drawStringUnderlineCharAt and
>>>>>>>>>>>>> #getClippedString methods are moved after parameters
>>>>>>>>>>>>> description.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with
>>>>>>>>>>>>>> chars that have
>>>>>>>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>>>>>>>>> The whole glyph is underlined.
>>>>>>>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The char value specified the the underlined index should
>>>>>>>>>>>>>> point to the high-surrogate range of a supplementary
>>>>>>>>>>>>>> character.
>>>>>>>>>>>>>> I updated the javadoc for the
>>>>>>>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>> * Draws the given string at the specified location
>>>>>>>>>>>>>> underlining
>>>>>>>>>>>>>> * the specified character.
>>>>>>>>>>>>>> * <p>
>>>>>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>>>>>> units).
>>>>>>>>>>>>>> * If the char value specified at the given underlined index
>>>>>>>>>>>>>> is in
>>>>>>>>>>>>>> * the high-surrogate range and the char value at the
>>>>>>>>>>>>>> following index is in
>>>>>>>>>>>>>> * the low-surrogate range then the supplementary character
>>>>>>>>>>>>>> corresponding
>>>>>>>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>>>>>>>> * <p>
>>>>>>>>>>>>>> * Nothing is drawn for null string. No character is
>>>>>>>>>>>>>> underlined for the
>>>>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>>>>>> the char value
>>>>>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>>>>>>>> I don't remember or know how Swing resolves this but the
>>>>>>>>>>>>>>>> measurement ones
>>>>>>>>>>>>>>>> are not reliable since they do not take a Graphics
>>>>>>>>>>>>>>>> context, so you cannot
>>>>>>>>>>>>>>>> measure the string properly. You need a FontRenderContext
>>>>>>>>>>>>>>>> to measure.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The provided methods use
>>>>>>>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method
>>>>>>>>>>>>>>> which returns the FontRenderContext associated with the
>>>>>>>>>>>>>>> component.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So as it stands these APIs do not appear suitable to be
>>>>>>>>>>>>>>>> made public as they
>>>>>>>>>>>>>>>> are not reliable.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Whilst I could look at the code, if I instead just look at
>>>>>>>>>>>>>>>> the API, I am scratching my
>>>>>>>>>>>>>>>> head over :-
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> public static void drawString(JComponent c, Graphics g,
>>>>>>>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>>>>>>>> So I am supposing that there is optional information that
>>>>>>>>>>>>>>>> may be pulled from the
>>>>>>>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The optional information provided by the component is:
>>>>>>>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>>>>>>>> - antialiasing hints
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if
>>>>>>>>>>>>>>>> the index is code point
>>>>>>>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1
>>>>>>>>>>>>>>>> code point:glyph mapping.
>>>>>>>>>>>>>>> I will update this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Are we sure that (any of) these really ought/need to be
>>>>>>>>>>>>>>>> public - particularly given the
>>>>>>>>>>>>>>>> resolution of
>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> These methods are used by JDK L&Fs to draw text. The
>>>>>>>>>>>>>>> initial request was to provide public methods that can be
>>>>>>>>>>>>>>> used by a custom L&F to draw strings consistently with
>>>>>>>>>>>>>>> other L&Fs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> They are also designed to properly render text for
>>>>>>>>>>>>>>> printing. To do that they use call to internal
>>>>>>>>>>>>>>> ProxyPrintGraphics class to obtain the print graphics
>>>>>>>>>>>>>>> context.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Even if printing staff will be public, these methods are
>>>>>>>>>>>>>>> just utility methods (in the same way as other text methods
>>>>>>>>>>>>>>> in the javax.swing.text.Utilities class) that help easily
>>>>>>>>>>>>>>> to draw and print text in the same way as JDK L&Fs do that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt,
>>>>>>>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Jan 18 20:18:35 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Jan 2016 23:18:35 +0300
Subject: <Swing Dev> internal API usage: PopupFactory.setPopupType()
In-Reply-To: <C4079AA5-CDF2-423D-92AC-9E0C69D14CFD@cbfiddle.com>
References: <C4079AA5-CDF2-423D-92AC-9E0C69D14CFD@cbfiddle.com>
Message-ID: <569D489B.5010608@oracle.com>

Hi, Alan.
Did you try to use JPopupMenu.setLightWeightPopupEnabled() for this usecase?

On 17/01/16 07:19, Alan Snyder wrote:
> I have submitted an RFE to make the functionality
> of PopupFactory.setPopupType() publicly available.
>
> JI-9028692
>
> Regards,
>
>    Alan
>


-- 
Best regards, Sergey.


From javalists at cbfiddle.com  Mon Jan 18 20:57:54 2016
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 18 Jan 2016 12:57:54 -0800
Subject: <Swing Dev> internal API usage: PopupFactory.setPopupType()
In-Reply-To: <569D489B.5010608@oracle.com>
References: <C4079AA5-CDF2-423D-92AC-9E0C69D14CFD@cbfiddle.com>
	<569D489B.5010608@oracle.com>
Message-ID: <6C055940-0220-4965-AEAE-B704B1245021@cbfiddle.com>

I want a solution that forces popups to be heavyweight and does not allow the application any choice in the matter.

My UI could set this flag on each popup, but the application could reset the flag.

  Alan


> On Jan 18, 2016, at 12:18 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Alan.
> Did you try to use JPopupMenu.setLightWeightPopupEnabled() for this usecase?
> 
> On 17/01/16 07:19, Alan Snyder wrote:
>> I have submitted an RFE to make the functionality
>> of PopupFactory.setPopupType() publicly available.
>> 
>> JI-9028692
>> 
>> Regards,
>> 
>>   Alan
>> 
> 
> 
> -- 
> Best regards, Sergey.



From semyon.sadetsky at oracle.com  Tue Jan 19 06:30:12 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Jan 2016 09:30:12 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <569CF8A5.2060807@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>
	<5699253C.3030800@oracle.com> <56996685.1070006@oracle.com>
	<569C8FB5.8050207@oracle.com> <569CF8A5.2060807@oracle.com>
Message-ID: <569DD7F4.2020201@oracle.com>



On 1/18/2016 5:37 PM, Sergey Bylokhov wrote:
> On 18/01/16 10:09, Semyon Sadetsky wrote:
>>
>>
>> On 1/16/2016 12:37 AM, Sergey Bylokhov wrote:
>>> On 15/01/16 19:58, Semyon Sadetsky wrote:
>>>>>> getStringWidth(): It is worth to add a note that the returning value
>>>>>> is not the exact visual string width because rendering hints are not
>>>>>> taken into account.
>>>
>>> It depends, the current description is correct. Default font metrics
>>> of the component should take into account KEY_TEXT_ANTIALIASING 
>>> property.
>>> The width of the string will be calculated by the passed font metrics.
>>> If the font metrics differs from the metrics of the graphics object
>>> then results will be different, if the metrics will be the same then
>>> results will be the same.
>>>
>>> If these methods will produce inconsistent result when we will get a
>>> bugs when the size of the component(which depends from the font) will
>>> differ from their appearance on the screen.
>> Then, this:
>> https://docs.oracle.com/javase/tutorial/2d/text/measuringtext.html is
>> incorrect?
>
> No, information in this link is correct. Note that example uses 
> FontMetrics from the graphics object, this is possible when we draw 
> the text, but in case of Swing the layout of the components occurs 
> before we try to draw a component.
>
Then the stringWidth() is not precise. We should note that in the javadoc.
>>>
>>>
>>>>>     I thought that rendering hints can affect a string quaility and
>>>>> drawing performance. Do they really change the visual string width?
>>>> Please look how the font anti-aliasing works:
>>>> https://upload.wikimedia.org/wikipedia/commons/3/34/A_aliased_and_simple.jpg 
>>>>
>>>>
>>>>
>>>> For example if user cut this width from a drawing artifacts may be
>>>> remained.
>>>>>>
>>>>>> What was the reason for renaming clipStringIfNecessary() and
>>>>>> stringWidth()?
>>>>>>
>>>>>> stringWidth() is a standard method name to get the advance in all
>>>>>> other JDK interfaces.
>>>>>     The 'get' prefix is used here not because it is JavaBeans
>>>>> requirements but because of the method name conventions.
>>>>>     For example, the same Utilities class contains
>>>>> getTabbedTextWidth() method which also has the 'get' prefix.
>>>>>
>>>>>> clipStringIfNecessary method name better reflects the method
>>>>>> operation than the proposed one.
>>>>>     The 'necessary' word is vague in this case. Is there any need to
>>>>> clip a string if it is not necessary?
>>>>>     The method description gives the explanation in which case the
>>>>> string will be clipped.
>>>>>
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>>
>>>>>> This is an utility static API and we don't need to follow JavaBeans
>>>>>> naming conventions here.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 1/13/2016 6:03 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>   Hello,
>>>>>>>
>>>>>>>   Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.05/
>>>>>>>
>>>>>>>   - the methods description are updated to mention a component
>>>>>>> numeric shaper and non-print graphics context
>>>>>>>   - @since tag value is updated to 9
>>>>>>>
>>>>>>>  Thanks,
>>>>>>>  Alexandr.
>>>>>>>
>>>>>>> On 1/12/2016 10:42 PM, Philip Race wrote:
>>>>>>>> @since needs to be just "9" as of the updated verona versioning
>>>>>>>> scheme.
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>>>>>>>>> Hi Alexander,
>>>>>>>>>
>>>>>>>>> I see that you've added the next clarifications to the methods
>>>>>>>>> specs:
>>>>>>>>>
>>>>>>>>> > draws string/returns width ... using text properties and
>>>>>>>>> anti-aliasing hints from the provided component
>>>>>>>>>
>>>>>>>>> It still seems too brief and even incorrect for getStringWidth().
>>>>>>>>>
>>>>>>>>> For drawString():
>>>>>>>>>
>>>>>>>>> For non-printing case I would write:
>>>>>>>>>
>>>>>>>>> Sets the anti-aliasing rendering hints to the Graphics object if
>>>>>>>>> those are specified in the component properties. Then the string
>>>>>>>>> is drawn using the provided Graphics object with the numeric
>>>>>>>>> shaper taken into account if it is defined for the component.
>>>>>>>>>
>>>>>>>>> Please consider the printing case...
>>>>>>>>>
>>>>>>>>> For getStringWidth():
>>>>>>>>>
>>>>>>>>> Did not get which anti-aliasing hints it takes into account while
>>>>>>>>> there is no Graphics in the params list...
>>>>>>>>> On the contrary, it does not take into account the rendering
>>>>>>>>> context.
>>>>>>>>> My suggestion:
>>>>>>>>>
>>>>>>>>> Returns string pixel width by the provided font metrics and
>>>>>>>>> according to the numeric shaper if it is defined for the 
>>>>>>>>> component.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>> For
>>>>>>>>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>>  Hello,
>>>>>>>>>>
>>>>>>>>>>  Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>>>>>>>>
>>>>>>>>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>
>>>>>>>>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>>>>>>>>
>>>>>>>>>>> * The {@code underlinedIndex} parameter points to a char value
>>>>>>>>>>> (Unicode code unit) in the
>>>>>>>>>>> * given string.
>>>>>>>>>>>
>>>>>>>>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And I suggest using "fits" instead of "can fit" in @return for
>>>>>>>>>>> getClippedString() and rephrasing the conditions where empty
>>>>>>>>>>> string is returned:
>>>>>>>>>>>
>>>>>>>>>>> * @return the clipped string that fits in the provided 
>>>>>>>>>>> space, an
>>>>>>>>>>> empty
>>>>>>>>>>> *         string if the given string argument is {@code 
>>>>>>>>>>> null} or
>>>>>>>>>>> empty.
>>>>>>>>>>
>>>>>>>>>>    The fix is updated according to the provided comments.
>>>>>>>>>>
>>>>>>>>>>    Thanks,
>>>>>>>>>>    Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alexey
>>>>>>>>>>>
>>>>>>>>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>>>>>>>>
>>>>>>>>>>>> - methods description is updated to mention used text
>>>>>>>>>>>> properties and anti-aliasing hints from the provided component
>>>>>>>>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>>>>>>>>> - @since tag is added for the drawString() method
>>>>>>>>>>>> - the description that some parameters may/must not be null is
>>>>>>>>>>>> added
>>>>>>>>>>>> - the test is updated to call the methods on EDT
>>>>>>>>>>>> - the test is updated to check passed null arguments
>>>>>>>>>>>>
>>>>>>>>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you please also clarify whether underlinedIndex in
>>>>>>>>>>>>> drawStringUnderlineCharAt refers to the char index in the
>>>>>>>>>>>>> string?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The statement
>>>>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>>>>> units).
>>>>>>>>>>>>> makes it unclear: underlinedIndex is an *index* or a *char*
>>>>>>>>>>>>> (Unicode code point).
>>>>>>>>>>>>
>>>>>>>>>>>>  I updated it to "The underlined index points to a char value
>>>>>>>>>>>> (Unicode code unit) in the given string."
>>>>>>>>>>>>  The 'refers' word was used for a value at the given index.
>>>>>>>>>>>>  However, I am not sure that the new variant is better.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Nothing is drawn for null string. No character is 
>>>>>>>>>>>>> underlined
>>>>>>>>>>>>> for the
>>>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>>>>> the char value
>>>>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it will be better to spell comparison operators, I
>>>>>>>>>>>>> mean to use  "greater than" rather than ">=". And "length"
>>>>>>>>>>>>> must be used instead of "width".
>>>>>>>>>>>>>
>>>>>>>>>>>>> I propose the following text:
>>>>>>>>>>>>>
>>>>>>>>>>>>> No character is underlined if the index is negative or 
>>>>>>>>>>>>> greater
>>>>>>>>>>>>> than the string length or if the char value specified at the
>>>>>>>>>>>>> given index is in the low-surrogate range.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For the first part of condition, you can add clarification in
>>>>>>>>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>>>>>>>>  Updated.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> For consistency, please remove the full stop in @return 
>>>>>>>>>>>>> tag in
>>>>>>>>>>>>> description of getClippedString.
>>>>>>>>>>>>
>>>>>>>>>>>> Updated.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Alexey
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The javadoc references for the #drawStringUnderlineCharAt 
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> #getClippedString methods are moved after parameters
>>>>>>>>>>>>>> description.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) 
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> chars that have
>>>>>>>>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature 
>>>>>>>>>>>>>>> (U+FB01)
>>>>>>>>>>>>>>> The whole glyph is underlined.
>>>>>>>>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char 
>>>>>>>>>>>>>>> U+10400)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The char value specified the the underlined index should
>>>>>>>>>>>>>>> point to the high-surrogate range of a supplementary
>>>>>>>>>>>>>>> character.
>>>>>>>>>>>>>>> I updated the javadoc for the
>>>>>>>>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>>> * Draws the given string at the specified location
>>>>>>>>>>>>>>> underlining
>>>>>>>>>>>>>>> * the specified character.
>>>>>>>>>>>>>>> * <p>
>>>>>>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>>>>>>> units).
>>>>>>>>>>>>>>> * If the char value specified at the given underlined index
>>>>>>>>>>>>>>> is in
>>>>>>>>>>>>>>> * the high-surrogate range and the char value at the
>>>>>>>>>>>>>>> following index is in
>>>>>>>>>>>>>>> * the low-surrogate range then the supplementary character
>>>>>>>>>>>>>>> corresponding
>>>>>>>>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>>>>>>>>> * <p>
>>>>>>>>>>>>>>> * Nothing is drawn for null string. No character is
>>>>>>>>>>>>>>> underlined for the
>>>>>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>>>>>>> the char value
>>>>>>>>>>>>>>> * specified at the given index is in the low-surrogate 
>>>>>>>>>>>>>>> range.
>>>>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>>>>>>>>> I don't remember or know how Swing resolves this but the
>>>>>>>>>>>>>>>>> measurement ones
>>>>>>>>>>>>>>>>> are not reliable since they do not take a Graphics
>>>>>>>>>>>>>>>>> context, so you cannot
>>>>>>>>>>>>>>>>> measure the string properly. You need a FontRenderContext
>>>>>>>>>>>>>>>>> to measure.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The provided methods use
>>>>>>>>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method
>>>>>>>>>>>>>>>> which returns the FontRenderContext associated with the
>>>>>>>>>>>>>>>> component.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So as it stands these APIs do not appear suitable to be
>>>>>>>>>>>>>>>>> made public as they
>>>>>>>>>>>>>>>>> are not reliable.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Whilst I could look at the code, if I instead just 
>>>>>>>>>>>>>>>>> look at
>>>>>>>>>>>>>>>>> the API, I am scratching my
>>>>>>>>>>>>>>>>> head over :-
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> public static void drawString(JComponent c, Graphics g,
>>>>>>>>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>>>>>>>>> So I am supposing that there is optional information that
>>>>>>>>>>>>>>>>> may be pulled from the
>>>>>>>>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The optional information provided by the component is:
>>>>>>>>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>>>>>>>>> - antialiasing hints
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to 
>>>>>>>>>>>>>>>>> explain if
>>>>>>>>>>>>>>>>> the index is code point
>>>>>>>>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1
>>>>>>>>>>>>>>>>> code point:glyph mapping.
>>>>>>>>>>>>>>>> I will update this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Are we sure that (any of) these really ought/need to be
>>>>>>>>>>>>>>>>> public - particularly given the
>>>>>>>>>>>>>>>>> resolution of
>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> These methods are used by JDK L&Fs to draw text. The
>>>>>>>>>>>>>>>> initial request was to provide public methods that can be
>>>>>>>>>>>>>>>> used by a custom L&F to draw strings consistently with
>>>>>>>>>>>>>>>> other L&Fs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> They are also designed to properly render text for
>>>>>>>>>>>>>>>> printing. To do that they use call to internal
>>>>>>>>>>>>>>>> ProxyPrintGraphics class to obtain the print graphics
>>>>>>>>>>>>>>>> context.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Even if printing staff will be public, these methods are
>>>>>>>>>>>>>>>> just utility methods (in the same way as other text 
>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>> in the javax.swing.text.Utilities class) that help easily
>>>>>>>>>>>>>>>> to draw and print text in the same way as JDK L&Fs do 
>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt,
>>>>>>>>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From semyon.sadetsky at oracle.com  Tue Jan 19 10:05:14 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Jan 2016 13:05:14 +0300
Subject: <Swing Dev> [9] Review Request for 8081722: Provide public API
 for file hierarchy provided by sun.awt.shell.ShellFolder
In-Reply-To: <5660213A.8060401@oracle.com>
References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com>
	<5637C2DD.6060801@oracle.com> <56543585.60401@oracle.com>
	<5660213A.8060401@oracle.com>
Message-ID: <569E0A5A.4090205@oracle.com>

On 12/3/2015 2:02 PM, Alexander Scherbatiy wrote:
>
> It is better to have concrete methods like Image 
> getFileChooserIcon(String iconName) rather to have one unified method 
> for all cases.
Please see the updated webrev: 
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.03/
get(String) is replaced with getChooserComboBoxFiles(). Other get() keys 
are not in use by NetBeans.
>
> Thanks,
> Alexandr.
>
> On 24/11/15 14:01, Semyon Sadetsky wrote:
>>
>>
>> On 11/2/2015 11:09 PM, Sergey Bylokhov wrote:
>>> On 29.10.15 21:30, Phil Race wrote:
>>>> We should specify what happens if you pass in to get(String)
>>>> a) null
>>>> b) an unrecognised name.
>>>>
>>>> Would it make sense to define string constants on FileSystemView
>>>> as otherwise people have to spell these exactly right without compiler
>>>> help ?
>>>>
>>>> Also I expect (hope!) that we do not assert any privileges here so 
>>>> there
>>>> will be a SecurityException if the caller does not have the necessary
>>>> permissions.
>>>> That should be documented.
>>>>
>>>> I find it odd that isLink(File) catches FNFE and just returns "false"
>>>> like this
>>>> was a normal file. Why is that ? In fact I find it particularly odd 
>>>> since
>>>> getLinkLocation() *does* throw FNFE if it does not exist.
>>>
>>>     I guess the new code should follow the rules which are used by 
>>> other methods in the same class, most of them catch FNFE and return 
>>> some default value. Also most of them returns default value if the 
>>> passed File is null. Anyway I think that NPE is better than IAE. At 
>>> least we should discuss this.
>> Could you explain why NPE is better? I supposed in case of an 
>> incorrect method usage IAE is more precise than generic NPE.
>> The FNFE is used in some methods of the class. I think that is 
>> justified if the linked file is not found. In other cases it is caught.
>>>
>>> I am not sure why this methods are static unlike old/others methods().
>> I agree, we should be following the class "style", so I have removed 
>> static modifiers.
>> The updated webrev: 
>> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.02/
>>>
>>> public static Object get(String key) {}
>>>     Probably this method too flexible? What kind of use case for 
>>> this method inside the users application? How the user will know 
>>> which parameters to use in a cross-platform manner?
>>>
>>> For example "fileChooserDefaultFolder" property already covered by 
>>> FileSystemView.getDefaultDirectory(), the "roots" is covered by 
>>> getRoots().
>> I don't think that we should elaborate a new Shell API in this fix, 
>> because we initially aimed to make the minimal change we can to 
>> support NetBeans ShellFolder extension.  We did a poll on the public 
>> alias which showed nobody else need this API to be opened.
>>>
>>>
>>>>
>>>> Also the docs casually say
>>>> "a shell interpreted link" and "platform shell" without explaining
>>>> what they mean by a shell. Should this term be used at all or
>>>> should the docs describe this in some other words ?
>>>>
>>>> getLinkLocation says
>>>>
>>>> "Returns a file linked to the specified file if the specified file"
>>>>
>>>> What that reads like to me is that you get back a link if
>>>> you pass in a regular file, whereas (I believe) you mean
>>>> the opposite.
>>>>
>>>> I think you mean :
>>>> "Returns the regular file referenced by the specified link file"
>>>>
>>>> I also note that one of the uses we located was of
>>>> ShellFolder.getShellFolder(File)
>>>> That internal API returns a ShellFolder but it we expose that it would
>>>> have to
>>>> be the java.io.File superclass I expect.
>>>>
>>>> -phil.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 10/26/2015 06:51 AM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8081722
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.00
>>>>>
>>>>> As the solution it is suggested to have 3 new static methods in the
>>>>> javax.swing.filechooser.FileSystemView class. Those methods proxy
>>>>> sun.awt.shell.ShellFolder calls and it is enough to cover NetBeans
>>>>> request. getShellFolder() method is not added because it returns the
>>>>> ShellFolder instance which is not for public use under the proposed
>>>>> approach.
>>>>> The CCC request will be rework when the fix is approved.
>>>>>
>>>>> --Semyon
>>>>
>>>
>>>
>>
>



From avik.niyogi at oracle.com  Tue Jan 19 11:27:19 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 19 Jan 2016 16:57:19 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <9FC2C3E2-1118-4F40-9A31-C1B01C0FF94D@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>
Message-ID: <4A7B5E21-686C-45B4-8821-4F0D2CEA2E42@oracle.com>

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> 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/>
> 
> 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>> 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/>
>>> 
>>> 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/~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/~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>>
>>>>>>>> <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 <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/~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>>
>>>>>>>>>> <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/~aniyogi/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/>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> *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/20160119/277ce906/attachment.html>

From andrej.golovnin at gmail.com  Tue Jan 19 11:28:11 2016
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Tue, 19 Jan 2016 12:28:11 +0100
Subject: <Swing Dev> [9] Review Request for 8081722: Provide public API
 for file hierarchy provided by sun.awt.shell.ShellFolder
In-Reply-To: <569E0A5A.4090205@oracle.com>
References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com>
	<5637C2DD.6060801@oracle.com> <56543585.60401@oracle.com>
	<5660213A.8060401@oracle.com> <569E0A5A.4090205@oracle.com>
Message-ID: <CAM6ZMz86iS1Pd3hFvvVoVCKJ7x8Yu6WqATNcSOVy0uCPEiD9BA@mail.gmail.com>

Hi Semyon,

> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.03/
> get(String) is replaced with getChooserComboBoxFiles(). Other get() keys are
> not in use by NetBeans.

Please move the new methods after the constructor of the FileSystemView class.

The description of the return value should not start with capital
letter (affected lines 112, 126, 151), e.g.:

112      * @return An array of {@code File} objects.

should be written as:

112      * @return an array of {@code File} objects.


In the line 151 the javadoc tag @code is not used for null.

Best regards,
Andrej Golovnin


From rajeev.chamyal at oracle.com  Tue Jan 19 11:48:20 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 19 Jan 2016 03:48:20 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8139213 : Mac OS X Aqua Look
 and Feel: JOptionPane can truncate the first button.
In-Reply-To: <567b8957-bded-44ad-83de-65e16a529910@default>
References: <567b8957-bded-44ad-83de-65e16a529910@default>
Message-ID: <5361f711-9cec-4744-a22e-d789cc6f5936@default>

Hello All,

Gentle reminder for review.

Regards,
Rajeev Chamyal

-----Original Message-----
From: Rajeev Chamyal 
Sent: 13 January 2016 16:37
To: Sergey Bylokhov; Alexander Scherbatiy; Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Review request for JDK-8139213 : Mac OS X Aqua Look and Feel: JOptionPane can truncate the first button.

Hello All,

Please review the following fix for Jdk9:

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

Issue : In Mac OS X Aqua LAF JOptionPane truncates the first button if multiple buttons are added to it.

Cause: AquaButtonAreaLayout class is not overriding base class method minimumLayoutSize as a result it is not taking to account the default button width for Aqua LAF.
Hence it is calculating incorrect dimensions for JOptionPane which results in truncation of button.

Fix: Overriding minimumLayoutSize in AquaButtonAreaLayout to consider default button width and height while calculating minimum size for JOptionPane.

Regards,
Rajeev Chamyal


From semyon.sadetsky at oracle.com  Tue Jan 19 12:15:18 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Jan 2016 15:15:18 +0300
Subject: <Swing Dev> [9] Review Request for 8081722: Provide public API
 for file hierarchy provided by sun.awt.shell.ShellFolder
In-Reply-To: <CAM6ZMz86iS1Pd3hFvvVoVCKJ7x8Yu6WqATNcSOVy0uCPEiD9BA@mail.gmail.com>
References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com>
	<5637C2DD.6060801@oracle.com> <56543585.60401@oracle.com>
	<5660213A.8060401@oracle.com> <569E0A5A.4090205@oracle.com>
	<CAM6ZMz86iS1Pd3hFvvVoVCKJ7x8Yu6WqATNcSOVy0uCPEiD9BA@mail.gmail.com>
Message-ID: <569E28D6.8000604@oracle.com>

Hi Andrej,

The webrev is updated: 
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.04/

--Semyon

On 1/19/2016 2:28 PM, Andrej Golovnin wrote:
> Hi Semyon,
>
>> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.03/
>> get(String) is replaced with getChooserComboBoxFiles(). Other get() keys are
>> not in use by NetBeans.
> Please move the new methods after the constructor of the FileSystemView class.
>
> The description of the return value should not start with capital
> letter (affected lines 112, 126, 151), e.g.:
>
> 112      * @return An array of {@code File} objects.
>
> should be written as:
>
> 112      * @return an array of {@code File} objects.
>
>
> In the line 151 the javadoc tag @code is not used for null.
>
> Best regards,
> Andrej Golovnin



From alexandr.scherbatiy at oracle.com  Tue Jan 19 15:09:06 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 Jan 2016 19:09:06 +0400
Subject: <Swing Dev> Review Request for Bug 8146320 JTextField ignores
 setPreferredSize when having columns
In-Reply-To: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>
References: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>
Message-ID: <569E5192.40400@oracle.com>

On 18/01/16 14:46, Prem Balakrishnan wrote:
>
> Hi,
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-8146320
>
> *Webrev:*http://cr.openjdk.java.net/~rchamyal/prem/8146320/webrev.00/ 
> <http://cr.openjdk.java.net/%7Erchamyal/prem/8146320/webrev.00/>
>
> *Issue:*
>
> JTextField ignores setPreferredSize when having columns
>
> *Cause:*
>
> JTextField setPreferredSize is not actually ignored , when column 
> value is set>0.
>
> While retrieving the values set using getPreferredSize(), wrong values 
> were returned.
>
> *Fix:*
>
> Check added, if Column>0 and if Preferred size is not set after 
> setting columns, while retrieving values.
>
   The javadoc for the JTextField.getPreferredSize() method should be 
updated according to the fix:
     /**
      * Returns the preferred size <code>Dimensions</code> needed for this
      * <code>TextField</code>.  If a non-zero number of columns has been
      * set, the width is set to the columns multiplied by
      * the column width.
      ...
      */

   Thanks,
   Alexandr.
>
> Regards,
> Prem
>

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

From alexandr.scherbatiy at oracle.com  Tue Jan 19 15:29:49 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 Jan 2016 19:29:49 +0400
Subject: <Swing Dev> Review request for JDK-8139213 : Mac OS X Aqua Look
 and Feel: JOptionPane can truncate the first button.
In-Reply-To: <5361f711-9cec-4744-a22e-d789cc6f5936@default>
References: <567b8957-bded-44ad-83de-65e16a529910@default>
	<5361f711-9cec-4744-a22e-d789cc6f5936@default>
Message-ID: <569E566D.9040500@oracle.com>

On 19/01/16 15:48, Rajeev Chamyal wrote:
> Hello All,
>
> Gentle reminder for review.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Rajeev Chamyal
> Sent: 13 January 2016 16:37
> To: Sergey Bylokhov; Alexander Scherbatiy; Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Review request for JDK-8139213 : Mac OS X Aqua Look and Feel: JOptionPane can truncate the first button.
>
> Hello All,
>
> Please review the following fix for Jdk9:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8139213
> Webrev : http://cr.openjdk.java.net/~rchamyal/8139213/webrev.00/
>
> Issue : In Mac OS X Aqua LAF JOptionPane truncates the first button if multiple buttons are added to it.
>
> Cause: AquaButtonAreaLayout class is not overriding base class method minimumLayoutSize as a result it is not taking to account the default button width for Aqua LAF.
> Hence it is calculating incorrect dimensions for JOptionPane which results in truncation of button.
>
> Fix: Overriding minimumLayoutSize in AquaButtonAreaLayout to consider default button width and height while calculating minimum size for JOptionPane.

   Is it possible to call  the minimumLayoutSize(Container) from the 
super class and adjust the returned size to take the default button size 
into account?

   Thanks,
   Alexandr.
>
> Regards,
> Rajeev Chamyal

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

From alexandr.scherbatiy at oracle.com  Tue Jan 19 15:31:40 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 Jan 2016 19:31:40 +0400
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <4A7B5E21-686C-45B4-8821-4F0D2CEA2E42@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>
Message-ID: <569E56DC.10908@oracle.com>


  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>> 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>> 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>> 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>> 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>> 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>> 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>> 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/>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *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/20160119/eba60bf6/attachment.html>

From alexandr.scherbatiy at oracle.com  Tue Jan 19 16:03:26 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 Jan 2016 20:03:26 +0400
Subject: <Swing Dev> Review request for JDK-8146276 : Right aligned
 ToolBar component does not appear
In-Reply-To: <37426965-3e73-4526-9ead-1acf10616ce5@default>
References: <37426965-3e73-4526-9ead-1acf10616ce5@default>
Message-ID: <569E5E4E.7020400@oracle.com>

On 12/01/16 08:21, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8146276
> Webrev: http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/
>
> Issue : Right aligned ToolBar component does not appear
> Cause: While calculating the minimum layout size for the components SynthToolBar is not checking if preferred size is set for the components.
>
> Fix: Updated the minimumLayoutSize method of SynthToolBarUI.java to check preferred size of components as well.

Could you give more details why it is not enough to properly layout 
buttons when the minimum layout size is only calculated on the minimum 
size and the preferred layout size is based on the buttons preferred size?

  Thanks,
  Alexandr.
>
> Regards,
> Rajeev Chamyal



From alexandr.scherbatiy at oracle.com  Tue Jan 19 16:21:26 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 Jan 2016 20:21:26 +0400
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: <569E6286.5030503@oracle.com>


The fix looks good to me.

  Thanks,
  Alexandr.

On 11/01/16 13:57, 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 rajeev.chamyal at oracle.com  Wed Jan 20 05:11:35 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 19 Jan 2016 21:11:35 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8139213 : Mac OS X Aqua Look
 and Feel: JOptionPane can truncate the first button.
In-Reply-To: <569E566D.9040500@oracle.com>
References: <567b8957-bded-44ad-83de-65e16a529910@default>
	<5361f711-9cec-4744-a22e-d789cc6f5936@default>
	<569E566D.9040500@oracle.com>
Message-ID: <97028995-8e4c-42d2-abd7-0a7cb0317fc8@default>

Hello Alexandr,

 

Thanks for the review. 

Yes, we can call minimumLayoutSize(Container) of parent class but in this case also again we need to check if any of the child components are setting preferred size and compare it with the default values.

And after this we need to find a delta that needs to be added to the minimum size obtained from the parent class. 

The current webrev code I feel is much cleaner than getting the size from parent class.

 

Regards,

Rajeev Chamyal

 

From: Alexander Scherbatiy 
Sent: 19 January 2016 21:00
To: Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: Review request for JDK-8139213 : Mac OS X Aqua Look and Feel: JOptionPane can truncate the first button.

 

On 19/01/16 15:48, Rajeev Chamyal wrote:



Hello All,
 
Gentle reminder for review.
 
Regards,
Rajeev Chamyal
 
-----Original Message-----
From: Rajeev Chamyal 
Sent: 13 January 2016 16:37
To: Sergey Bylokhov; Alexander Scherbatiy; Prasanta Sadhukhan; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Review request for JDK-8139213 : Mac OS X Aqua Look and Feel: JOptionPane can truncate the first button.
 
Hello All,
 
Please review the following fix for Jdk9:
 
Bug : https://bugs.openjdk.java.net/browse/JDK-8139213
Webrev : http://cr.openjdk.java.net/~rchamyal/8139213/webrev.00/
 
Issue : In Mac OS X Aqua LAF JOptionPane truncates the first button if multiple buttons are added to it.
 
Cause: AquaButtonAreaLayout class is not overriding base class method minimumLayoutSize as a result it is not taking to account the default button width for Aqua LAF.
Hence it is calculating incorrect dimensions for JOptionPane which results in truncation of button.
 
Fix: Overriding minimumLayoutSize in AquaButtonAreaLayout to consider default button width and height while calculating minimum size for JOptionPane.


  Is it possible to call  the minimumLayoutSize(Container) from the super class and adjust the returned size to take the default button size into account?

  Thanks,
  Alexandr.



 
 
Regards,
Rajeev Chamyal

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

From avik.niyogi at oracle.com  Wed Jan 20 04:59:26 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 20 Jan 2016 10:29:26 +0530
Subject: <Swing Dev> Review Request of 8146321: [macosx] JInternalFrame
	frame icon in wrong position on Mac L&F if icon is not ImageIcon
In-Reply-To: <13420C14-4119-4EF4-A037-1F4C2BF87E3C@oracle.com>
References: <431B2640-2D19-4EFC-824E-52AE3D25D2D8@oracle.com>
	<56973AEA.1040308@oracle.com>
	<BEB3BF05-B31A-4595-BCBB-E9DC915AED19@oracle.com>
	<13420C14-4119-4EF4-A037-1F4C2BF87E3C@oracle.com>
Message-ID: <328DE551-87E2-4D51-89DC-AA7BAE40B610@oracle.com>

Hi All,
A gentle reminder, please review my code changes as in the webrev below in the mail trail.
With Regards,
Avik Niyogi
> On 18-Jan-2016, at 3:01 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi Sergey,
> 
> Please review the webrev taking inputs as per the discussion before:
> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/>
> 
> With Regards,
> Avik Niyogi
> 
>> On 14-Jan-2016, at 12:55 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>> 
>> Hi Sergey,
>> I have verified it with the test case as well. If a test case overrides these methods to imply a change with icons larger than 16x16 it will show that for ImageIcon and Icon as before. The resize of ImageIcon is only in case it has an image file that it will try to fit. I had a similar query myself and have found out that getImage() exists for ImageIcon class only and not Icon class.
>> Example:
>> private static void createImageIconUI(final String lookAndFeelString)
>>             throws Exception {
>>         SwingUtilities.invokeAndWait(new Runnable() {
>>             @Override
>>             public void run() {
>>                 desktopPane = new JDesktopPane();
>>                 internalFrame = new JInternalFrame();
>>                 frame = new JFrame();
>>                 internalFrame.setTitle(lookAndFeelString);
>>                 titleImageIcon = new ImageIcon() {
>>                     @Override
>>                     public int getIconWidth() {
>>                         return 16;
>>                     }
>> 
>>                     @Override
>>                     public int getIconHeight() {
>>                         return 16;
>>                     }
>> 
>>                     @Override
>>                     public void paintIcon(
>>                             Component c, Graphics g, int x, int y) {
>>                         g.setColor(java.awt.Color.black);
>>                         g.fillRect(x, y, 50, 50);
>>                     }
>>                 };
>>                 internalFrame.setFrameIcon(titleImageIcon);
>>                 internalFrame.setSize(500, 200);
>>                 internalFrame.setVisible(true);
>>                 desktopPane.add(internalFrame);
>> 
>>                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>                 frame.getContentPane().setLayout(new BorderLayout());
>>                 frame.getContentPane().add(desktopPane, "Center");
>>                 frame.setSize(500, 500);
>>                 frame.setLocationRelativeTo(null);
>>                 frame.setVisible(true);
>>                 frame.toFront();
>>             }
>>         });
>>     }
>> In this case the ImageIcon will NOT be resized to 16 x 16 even before my fix was implemented. That resize as shown in code is only for Image files to fit in default ImageIcon size as returned from the getIconHeight() and getIconWidth() methods. If user changes the ImageIcon size as in the example, that is upto to user to choose to do so and no control exists to prevent that. So, with or without my fix, this behaviour will be same for ImageIcon and Icon custom instances.
>> Hope this clarifies the query. 
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 14-Jan-2016, at 11:36 am, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>> 
>>> Hi, Avik.
>>> In the fix you update getIconWidth() and getIconHeight, so now we take the Icon into account. but it seems if the Icon is bigger that the maximum size it will not be resided to 16x16, right?
>>> 
>>> On 14/01/16 07:49, Avik Niyogi wrote:
>>>> Hi All,
>>>> 
>>>> Kindly review the bug fix for JDK 9.
>>>> 
>>>> *Bug:*
>>>> https://bugs.openjdk.java.net/browse/JDK-8146321 <https://bugs.openjdk.java.net/browse/JDK-8146321>
>>>> 
>>>> *Webrev:*
>>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/>
>>>> 
>>>> *Issue:*
>>>> Under the Mac Look&Feel, if an icon type other than an ImageIcon is used
>>>> in JInternalFrame.setFrameIcon(),
>>>> the icon will show up in the wrong position.
>>>> 
>>>> *Cause:*
>>>> the "instanceof Icon" was not checked for. Also, customs ImageIcon with
>>>> color fill (and no image URL) which would
>>>> have resulted in null value for resized ImageIcon image was not well
>>>> handled.
>>>> 
>>>> *Fix:*
>>>> All places in Aqua LAF where "instanceof Icon? (and not just ImageIcon
>>>> class) is required,
>>>> inputs were added after significant analyses.
>>>> Check for null for getImage was done to remove a Null Pointer Exception.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
>> 
> 

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

From rajeev.chamyal at oracle.com  Wed Jan 20 05:10:34 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 19 Jan 2016 21:10:34 -0800 (PST)
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <5FBB51B9-1C62-47D0-AAC7-35849350EA21@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>
Message-ID: <52e60872-c7cb-4b04-b257-24d6b975ba22@default>

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/

Thank you in advance.

 

With Regards,

Avik Niyogi

 

On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"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 <HYPERLINK "mailto:avik.niyogi at oracle.com"avik.niyogi at oracle.com> wrote:

 

Hi All, Please find the changes as provided with incorporation of inputs: 

HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/"http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/

 

With Regards,

Avik Niyogi

 

On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov <HYPERLINK "mailto:Sergey.Bylokhov at oracle.com"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:
HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.05/"http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/

With Regards,
Avik Niyogi



On 14-Jan-2016, at 3:18 pm, Alexander Scherbatiy
<HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"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:
HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/"http://cr.openjdk.java.net/~aniyogi/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
<HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"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:
HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/"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/>


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
<HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"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.
HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/"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/>

With Regards,
Avik Niyogi




On 11-Jan-2016, at 3:55 pm, Semyon Sadetsky
<HYPERLINK "mailto:semyon.sadetsky at oracle.com"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:
HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/"http://cr.openjdk.java.net/~aniyogi/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
<HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"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/
HYPERLINK "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/20160119/d724591b/attachment.html>

From rajeev.chamyal at oracle.com  Wed Jan 20 06:52:12 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 19 Jan 2016 22:52:12 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8146276 : Right aligned
 ToolBar component does not appear
In-Reply-To: <569E5E4E.7020400@oracle.com>
References: <37426965-3e73-4526-9ead-1acf10616ce5@default>
	<569E5E4E.7020400@oracle.com>
Message-ID: <2ea3eb72-e562-4f93-aaa1-7e620095b196@default>

Hello Alexandr,

Thanks for the review.
This issue is seen only if we have glue added to any SynthToolBar. 
While doing layoutContainer we need to distribute the empty space among glue and currently its  done by finding minimum width of parent using minimumLayoutSize which doesn't consider preferred size of child comps.
The preferred layout size is not getting called in this case. I have replaced the minimumLayoutSize with preferredLayoutSize and updated the webrev.
http://cr.openjdk.java.net/~rchamyal/8146276/webrev.01/

Regards,
Rajeev Chamyal

-----Original Message-----
From: Alexander Scherbatiy 
Sent: 19 January 2016 21:33
To: Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: Review request for JDK-8146276 : Right aligned ToolBar component does not appear

On 12/01/16 08:21, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8146276
> Webrev: http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/
>
> Issue : Right aligned ToolBar component does not appear
> Cause: While calculating the minimum layout size for the components SynthToolBar is not checking if preferred size is set for the components.
>
> Fix: Updated the minimumLayoutSize method of SynthToolBarUI.java to check preferred size of components as well.

Could you give more details why it is not enough to properly layout buttons when the minimum layout size is only calculated on the minimum size and the preferred layout size is based on the buttons preferred size?

  Thanks,
  Alexandr.
>
> Regards,
> Rajeev Chamyal



From avik.niyogi at oracle.com  Wed Jan 20 06:52:43 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 20 Jan 2016 12:22:43 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <52e60872-c7cb-4b04-b257-24d6b975ba22@default>
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>
Message-ID: <33152751-3DA9-40FB-9900-FA204D16DAF6@oracle.com>

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/>

With Regards,
Avik Niyogi
> On 20-Jan-2016, at 10:40 am, Rajeev Chamyal <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/>
> 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>> 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>> 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>> 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/ <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/>>
> <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 <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/ <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/ <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 <https://bugs.openjdk.java.net/browse/JDK-8015748>
> 
> *Webrev:*
> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.00/ <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/>
> 
> *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 <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/20160120/31713fb3/attachment.html>

From rajeev.chamyal at oracle.com  Wed Jan 20 09:47:22 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 20 Jan 2016 01:47:22 -0800 (PST)
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <33152751-3DA9-40FB-9900-FA204D16DAF6@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>
Message-ID: <a0f24f2d-5634-4365-95fb-bf07d440fb75@default>

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
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/

 

With Regards,

Avik Niyogi

On 20-Jan-2016, at 10:40 am, Rajeev Chamyal <HYPERLINK "mailto:rajeev.chamyal at oracle.com"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/

Thank you in advance.

 

With Regards,

Avik Niyogi

 

On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy <HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"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 <HYPERLINK "mailto:avik.niyogi at oracle.com"avik.niyogi at oracle.com> wrote:

 

Hi All, Please find the changes as provided with incorporation of inputs: 

HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/"http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/

 

With Regards,

Avik Niyogi

 

On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov <HYPERLINK "mailto:Sergey.Bylokhov at oracle.com"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:
HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.05/"http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/

With Regards,
Avik Niyogi




On 14-Jan-2016, at 3:18 pm, Alexander Scherbatiy
<HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"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:
HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/"http://cr.openjdk.java.net/~aniyogi/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
<HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"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:
HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/"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/>


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
<HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"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.
HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/"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/>

With Regards,
Avik Niyogi





On 11-Jan-2016, at 3:55 pm, Semyon Sadetsky
<HYPERLINK "mailto:semyon.sadetsky at oracle.com"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:
HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.01/"http://cr.openjdk.java.net/~aniyogi/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
<HYPERLINK "mailto:alexandr.scherbatiy at oracle.com"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/
HYPERLINK "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/20160120/80166696/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed Jan 20 11:00:45 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 20 Jan 2016 14:00:45 +0300
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <a0f24f2d-5634-4365-95fb-bf07d440fb75@default>
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>
Message-ID: <569F68DD.3010705@oracle.com>


   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
> *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>> 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>> 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>> 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>> 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>>
>                             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>>
>                                     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>>
>                                             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>>
>                                                     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>>
>                                                             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.
>



From alexandr.scherbatiy at oracle.com  Wed Jan 20 11:03:26 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 20 Jan 2016 14:03:26 +0300
Subject: <Swing Dev> [9] Review Request for 8081722: Provide public API
 for file hierarchy provided by sun.awt.shell.ShellFolder
In-Reply-To: <569E28D6.8000604@oracle.com>
References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com>
	<5637C2DD.6060801@oracle.com> <56543585.60401@oracle.com>
	<5660213A.8060401@oracle.com> <569E0A5A.4090205@oracle.com>
	<CAM6ZMz86iS1Pd3hFvvVoVCKJ7x8Yu6WqATNcSOVy0uCPEiD9BA@mail.gmail.com>
	<569E28D6.8000604@oracle.com>
Message-ID: <569F697E.8060101@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 1/19/2016 3:15 PM, Semyon Sadetsky wrote:
> Hi Andrej,
>
> The webrev is updated: 
> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.04/
>
> --Semyon
>
> On 1/19/2016 2:28 PM, Andrej Golovnin wrote:
>> Hi Semyon,
>>
>>> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.03/
>>> get(String) is replaced with getChooserComboBoxFiles(). Other get() 
>>> keys are
>>> not in use by NetBeans.
>> Please move the new methods after the constructor of the 
>> FileSystemView class.
>>
>> The description of the return value should not start with capital
>> letter (affected lines 112, 126, 151), e.g.:
>>
>> 112      * @return An array of {@code File} objects.
>>
>> should be written as:
>>
>> 112      * @return an array of {@code File} objects.
>>
>>
>> In the line 151 the javadoc tag @code is not used for null.
>>
>> Best regards,
>> Andrej Golovnin
>



From andrej.golovnin at gmail.com  Wed Jan 20 11:10:57 2016
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Wed, 20 Jan 2016 12:10:57 +0100
Subject: <Swing Dev> [9] Review Request for 8081722: Provide public API
 for file hierarchy provided by sun.awt.shell.ShellFolder
In-Reply-To: <569E28D6.8000604@oracle.com>
References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com>
	<5637C2DD.6060801@oracle.com> <56543585.60401@oracle.com>
	<5660213A.8060401@oracle.com> <569E0A5A.4090205@oracle.com>
	<CAM6ZMz86iS1Pd3hFvvVoVCKJ7x8Yu6WqATNcSOVy0uCPEiD9BA@mail.gmail.com>
	<569E28D6.8000604@oracle.com>
Message-ID: <CAM6ZMz_8t1yffrV-AhWvE_H9McVCeZGargp38HPtc5Z2L6+xiA@mail.gmail.com>

Hi Semyon,

> The webrev is updated:
> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.04/

Thanks! Looks good for me (I'm not a reviewer).

Best regards,
Andrej Golovnin


From alexandr.scherbatiy at oracle.com  Wed Jan 20 11:12:22 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 20 Jan 2016 14:12:22 +0300
Subject: <Swing Dev> Review Request of 8146321: [macosx] JInternalFrame
 frame icon in wrong position on Mac L&F if icon is not ImageIcon
In-Reply-To: <328DE551-87E2-4D51-89DC-AA7BAE40B610@oracle.com>
References: <431B2640-2D19-4EFC-824E-52AE3D25D2D8@oracle.com>
	<56973AEA.1040308@oracle.com>
	<BEB3BF05-B31A-4595-BCBB-E9DC915AED19@oracle.com>
	<13420C14-4119-4EF4-A037-1F4C2BF87E3C@oracle.com>
	<328DE551-87E2-4D51-89DC-AA7BAE40B610@oracle.com>
Message-ID: <569F6B96.8070309@oracle.com>

On 1/20/2016 7:59 AM, Avik Niyogi wrote:
> Hi All,
> A gentle reminder, please review my code changes as in the webrev 
> below in the mail trail.
> With Regards,
> Avik Niyogi
>> On 18-Jan-2016, at 3:01 pm, Avik Niyogi <avik.niyogi at oracle.com 
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi Sergey,
>>
>> Please review the webrev taking inputs as per the discussion before:
>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.01/>

     The idea was to scale the graphics that the drawn icon fits to the 
target sizes.
     Something like:
        --------
        g2d.scale(targetIconWidth/icon.getWidth(), 
targetIconHeight/icon.getHeight());
        icon.paintIcon(frame, g2d, x, y);
       ---------

    This should work not only for ImageIcon but for any type of icons.

    Thanks,
    Alexandr.
>>
>> With Regards,
>> Avik Niyogi
>>
>>> On 14-Jan-2016, at 12:55 pm, Avik Niyogi <avik.niyogi at oracle.com 
>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>
>>> Hi Sergey,
>>> I have verified it with the test case as well. If a test case 
>>> overrides these methods to imply a change with icons larger than 
>>> 16x16 it will show that for ImageIcon and Icon as before. The resize 
>>> of ImageIcon is only in case it has an image file that it will try 
>>> to fit. I had a similar query myself and have found out that 
>>> *getImage()* exists for ImageIcon class only and not Icon class.
>>> Example:
>>> private static void createImageIconUI(final String lookAndFeelString)
>>>             throws Exception {
>>> SwingUtilities.invokeAndWait(new Runnable() {
>>>             @Override
>>>             public void run() {
>>>                 desktopPane = new JDesktopPane();
>>>                 internalFrame = new JInternalFrame();
>>>                 frame = new JFrame();
>>> internalFrame.setTitle(lookAndFeelString);
>>>                 titleImageIcon = new ImageIcon() {
>>>                     @Override
>>>                     public int getIconWidth() {
>>>                         return 16;
>>>                     }
>>>
>>>                     @Override
>>>                     public int getIconHeight() {
>>>                         return 16;
>>>                     }
>>>
>>>                     @Override
>>>                     public void paintIcon(
>>> Component c, Graphics g, int x, int y) {
>>> g.setColor(java.awt.Color.black);
>>> *g.fillRect(x, y, 50, 50);*
>>>                     }
>>>                 };
>>> internalFrame.setFrameIcon(titleImageIcon);
>>> internalFrame.setSize(500, 200);
>>> internalFrame.setVisible(true);
>>> desktopPane.add(internalFrame);
>>>
>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>> frame.getContentPane().setLayout(new BorderLayout());
>>> frame.getContentPane().add(desktopPane, "Center");
>>> frame.setSize(500, 500);
>>> frame.setLocationRelativeTo(null);
>>> frame.setVisible(true);
>>> frame.toFront();
>>>             }
>>>         });
>>>     }
>>> In this case the ImageIcon will NOT be resized to 16 x 16 even 
>>> before my fix was implemented. That resize as shown in code is *only 
>>> for Image files to fit in default ImageIcon* size as returned from 
>>> the getIconHeight() and getIconWidth() methods. If user changes the 
>>> ImageIcon size as in the example, that is upto to user to choose to 
>>> do so and no control exists to prevent that. *So, with or without my 
>>> fix, this behaviour will be same for ImageIcon and Icon custom 
>>> instances.*
>>> Hope this clarifies the query.
>>>
>>> With Regards,
>>> Avik Niyogi
>>>
>>>> On 14-Jan-2016, at 11:36 am, Sergey Bylokhov 
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>
>>>> Hi, Avik.
>>>> In the fix you update getIconWidth() and getIconHeight, so now we 
>>>> take the Icon into account. but it seems if the Icon is bigger that 
>>>> the maximum size it will not be resided to 16x16, right?
>>>>
>>>> On 14/01/16 07:49, Avik Niyogi wrote:
>>>>> Hi All,
>>>>>
>>>>> Kindly review the bug fix for JDK 9.
>>>>>
>>>>> *Bug:*
>>>>> https://bugs.openjdk.java.net/browse/JDK-8146321
>>>>>
>>>>> *Webrev:*
>>>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.00/>
>>>>>
>>>>> *Issue:*
>>>>> Under the Mac Look&Feel, if an icon type other than an ImageIcon 
>>>>> is used
>>>>> in JInternalFrame.setFrameIcon(),
>>>>> the icon will show up in the wrong position.
>>>>>
>>>>> *Cause:*
>>>>> the "instanceof Icon" was not checked for. Also, customs ImageIcon 
>>>>> with
>>>>> color fill (and no image URL) which would
>>>>> have resulted in null value for resized ImageIcon image was not well
>>>>> handled.
>>>>>
>>>>> *Fix:*
>>>>> All places in Aqua LAF where "instanceof Icon? (and not just ImageIcon
>>>>> class) is required,
>>>>> inputs were added after significant analyses.
>>>>> Check for null for getImage was done to remove a Null Pointer 
>>>>> Exception.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Wed Jan 20 11:33:49 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 20 Jan 2016 14:33:49 +0300
Subject: <Swing Dev> Review request for JDK-8139213 : Mac OS X Aqua Look
 and Feel: JOptionPane can truncate the first button.
In-Reply-To: <97028995-8e4c-42d2-abd7-0a7cb0317fc8@default>
References: <567b8957-bded-44ad-83de-65e16a529910@default>
	<5361f711-9cec-4744-a22e-d789cc6f5936@default>
	<569E566D.9040500@oracle.com>
	<97028995-8e4c-42d2-abd7-0a7cb0317fc8@default>
Message-ID: <569F709D.7000204@oracle.com>

On 1/20/2016 8:11 AM, Rajeev Chamyal wrote:
>
> Hello Alexandr,
>
> Thanks for the review.
>
> Yes, we can call minimumLayoutSize(Container) of parent class but in 
> this case also again we need to check if any of the child components 
> are setting preferred size and compare it with the default values.
>
> And after this we need to find a delta that needs to be added to the 
> minimum size obtained from the parent class.
>
> The current webrev code I feel is much cleaner than getting the size 
> from parent class.
>

     The parent class also includes preffered sizes. It looks like it is 
possible to do something like:
     ---------------
     int kButtonLayoutSizeWidth = extraWidth
             + (kOKCancelButtonWidth * numChildren)
             + (numChildren - 1) * padding;
     int kButtonLayoutSizeHeight = extraHeight + kButtonHeight;

     Dimension size = super.minimumLayoutSize(c);
     size.width = Math.max(size.width, kButtonLayoutSizeWidth);
     size.height = Math.max(size.height, kButtonLayoutSizeHeight);
    ---------------

  Thanks,
  Alexandr.

> Regards,
>
> Rajeev Chamyal
>
> *From:*Alexander Scherbatiy
> *Sent:* 19 January 2016 21:00
> *To:* Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan; 
> swing-dev at openjdk.java.net
> *Subject:* Re: Review request for JDK-8139213 : Mac OS X Aqua Look and 
> Feel: JOptionPane can truncate the first button.
>
> On 19/01/16 15:48, Rajeev Chamyal wrote:
>
>     Hello All,
>
>       
>
>     Gentle reminder for review.
>
>       
>
>     Regards,
>
>     Rajeev Chamyal
>
>       
>
>     -----Original Message-----
>
>     From: Rajeev Chamyal
>
>     Sent: 13 January 2016 16:37
>
>     To: Sergey Bylokhov; Alexander Scherbatiy; Prasanta Sadhukhan;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>     Subject: Review request for JDK-8139213 : Mac OS X Aqua Look and Feel: JOptionPane can truncate the first button.
>
>       
>
>     Hello All,
>
>       
>
>     Please review the following fix for Jdk9:
>
>       
>
>     Bug :https://bugs.openjdk.java.net/browse/JDK-8139213
>
>     Webrev :http://cr.openjdk.java.net/~rchamyal/8139213/webrev.00/  <http://cr.openjdk.java.net/%7Erchamyal/8139213/webrev.00/>
>
>       
>
>     Issue : In Mac OS X Aqua LAF JOptionPane truncates the first button if multiple buttons are added to it.
>
>       
>
>     Cause: AquaButtonAreaLayout class is not overriding base class method minimumLayoutSize as a result it is not taking to account the default button width for Aqua LAF.
>
>     Hence it is calculating incorrect dimensions for JOptionPane which results in truncation of button.
>
>       
>
>     Fix: Overriding minimumLayoutSize in AquaButtonAreaLayout to consider default button width and height while calculating minimum size for JOptionPane.
>
>
>   Is it possible to call  the minimumLayoutSize(Container) from the 
> super class and adjust the returned size to take the default button 
> size into account?
>
>   Thanks,
>   Alexandr.
>
>       
>
>       
>
>     Regards,
>
>     Rajeev Chamyal
>



From alexandr.scherbatiy at oracle.com  Wed Jan 20 11:36:44 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 20 Jan 2016 14:36:44 +0300
Subject: <Swing Dev> Review request for JDK-8146276 : Right aligned
 ToolBar component does not appear
In-Reply-To: <2ea3eb72-e562-4f93-aaa1-7e620095b196@default>
References: <37426965-3e73-4526-9ead-1acf10616ce5@default>
	<569E5E4E.7020400@oracle.com>
	<2ea3eb72-e562-4f93-aaa1-7e620095b196@default>
Message-ID: <569F714C.1010302@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 1/20/2016 9:52 AM, Rajeev Chamyal wrote:
> Hello Alexandr,
>
> Thanks for the review.
> This issue is seen only if we have glue added to any SynthToolBar.
> While doing layoutContainer we need to distribute the empty space among glue and currently its  done by finding minimum width of parent using minimumLayoutSize which doesn't consider preferred size of child comps.
> The preferred layout size is not getting called in this case. I have replaced the minimumLayoutSize with preferredLayoutSize and updated the webrev.
> http://cr.openjdk.java.net/~rchamyal/8146276/webrev.01/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexander Scherbatiy
> Sent: 19 January 2016 21:33
> To: Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8146276 : Right aligned ToolBar component does not appear
>
> On 12/01/16 08:21, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8146276
>> Webrev: http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/
>>
>> Issue : Right aligned ToolBar component does not appear
>> Cause: While calculating the minimum layout size for the components SynthToolBar is not checking if preferred size is set for the components.
>>
>> Fix: Updated the minimumLayoutSize method of SynthToolBarUI.java to check preferred size of components as well.
> Could you give more details why it is not enough to properly layout buttons when the minimum layout size is only calculated on the minimum size and the preferred layout size is based on the buttons preferred size?
>
>    Thanks,
>    Alexandr.
>> Regards,
>> Rajeev Chamyal



From Sergey.Bylokhov at oracle.com  Wed Jan 20 12:32:55 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Jan 2016 15:32:55 +0300
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <569F68DD.3010705@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>
Message-ID: <569F7E77.2050807@oracle.com>

Hi, Avik.
The test still pass before the fix, but it should fail.

On 20/01/16 14:00, Alexander Scherbatiy 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
>> *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>> 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>> 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>> 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>> 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>>
>>                             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>>
>>                                     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>>
>>                                             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>>
>>                                                     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>>
>>                                                             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 rajeev.chamyal at oracle.com  Wed Jan 20 12:45:25 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 20 Jan 2016 04:45:25 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8139213 : Mac OS X Aqua Look
 and Feel: JOptionPane can truncate the first button.
In-Reply-To: <569F709D.7000204@oracle.com>
References: <567b8957-bded-44ad-83de-65e16a529910@default>
	<5361f711-9cec-4744-a22e-d789cc6f5936@default>
	<569E566D.9040500@oracle.com>
	<97028995-8e4c-42d2-abd7-0a7cb0317fc8@default>
	<569F709D.7000204@oracle.com>
Message-ID: <813582c6-ed28-4fd3-a85b-14e2f29be7d7@default>

Hello Alexandr,

Thanks for the review.
I have updated the webrev as suggested.
http://cr.openjdk.java.net/~rchamyal/8139213/webrev.01/

Regards,
Rajeev Chamyal

-----Original Message-----
From: Alexander Scherbatiy 
Sent: 20 January 2016 17:04
To: Rajeev Chamyal
Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: Review request for JDK-8139213 : Mac OS X Aqua Look and Feel: JOptionPane can truncate the first button.

On 1/20/2016 8:11 AM, Rajeev Chamyal wrote:
>
> Hello Alexandr,
>
> Thanks for the review.
>
> Yes, we can call minimumLayoutSize(Container) of parent class but in 
> this case also again we need to check if any of the child components 
> are setting preferred size and compare it with the default values.
>
> And after this we need to find a delta that needs to be added to the 
> minimum size obtained from the parent class.
>
> The current webrev code I feel is much cleaner than getting the size 
> from parent class.
>

     The parent class also includes preffered sizes. It looks like it is possible to do something like:
     ---------------
     int kButtonLayoutSizeWidth = extraWidth
             + (kOKCancelButtonWidth * numChildren)
             + (numChildren - 1) * padding;
     int kButtonLayoutSizeHeight = extraHeight + kButtonHeight;

     Dimension size = super.minimumLayoutSize(c);
     size.width = Math.max(size.width, kButtonLayoutSizeWidth);
     size.height = Math.max(size.height, kButtonLayoutSizeHeight);
    ---------------

  Thanks,
  Alexandr.

> Regards,
>
> Rajeev Chamyal
>
> *From:*Alexander Scherbatiy
> *Sent:* 19 January 2016 21:00
> *To:* Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan; 
> swing-dev at openjdk.java.net
> *Subject:* Re: Review request for JDK-8139213 : Mac OS X Aqua Look and
> Feel: JOptionPane can truncate the first button.
>
> On 19/01/16 15:48, Rajeev Chamyal wrote:
>
>     Hello All,
>
>       
>
>     Gentle reminder for review.
>
>       
>
>     Regards,
>
>     Rajeev Chamyal
>
>       
>
>     -----Original Message-----
>
>     From: Rajeev Chamyal
>
>     Sent: 13 January 2016 16:37
>
>     To: Sergey Bylokhov; Alexander Scherbatiy; Prasanta 
> Sadhukhan;swing-dev at openjdk.java.net  
> <mailto:swing-dev at openjdk.java.net>
>
>     Subject: Review request for JDK-8139213 : Mac OS X Aqua Look and Feel: JOptionPane can truncate the first button.
>
>       
>
>     Hello All,
>
>       
>
>     Please review the following fix for Jdk9:
>
>       
>
>     Bug :https://bugs.openjdk.java.net/browse/JDK-8139213
>
>     Webrev :http://cr.openjdk.java.net/~rchamyal/8139213/webrev.00/  
> <http://cr.openjdk.java.net/%7Erchamyal/8139213/webrev.00/>
>
>       
>
>     Issue : In Mac OS X Aqua LAF JOptionPane truncates the first button if multiple buttons are added to it.
>
>       
>
>     Cause: AquaButtonAreaLayout class is not overriding base class method minimumLayoutSize as a result it is not taking to account the default button width for Aqua LAF.
>
>     Hence it is calculating incorrect dimensions for JOptionPane which results in truncation of button.
>
>       
>
>     Fix: Overriding minimumLayoutSize in AquaButtonAreaLayout to consider default button width and height while calculating minimum size for JOptionPane.
>
>
>   Is it possible to call  the minimumLayoutSize(Container) from the 
> super class and adjust the returned size to take the default button 
> size into account?
>
>   Thanks,
>   Alexandr.
>
>       
>
>       
>
>     Regards,
>
>     Rajeev Chamyal
>



From Sergey.Bylokhov at oracle.com  Wed Jan 20 12:45:43 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Jan 2016 15:45:43 +0300
Subject: <Swing Dev> [9] Review Request for 8081722: Provide public API
 for file hierarchy provided by sun.awt.shell.ShellFolder
In-Reply-To: <56543585.60401@oracle.com>
References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com>
	<5637C2DD.6060801@oracle.com> <56543585.60401@oracle.com>
Message-ID: <569F8177.9050308@oracle.com>

On 24/11/15 13:01, Semyon Sadetsky wrote:
>
>
> On 11/2/2015 11:09 PM, Sergey Bylokhov wrote:
>> On 29.10.15 21:30, Phil Race wrote:
>>> We should specify what happens if you pass in to get(String)
>>> a) null
>>> b) an unrecognised name.
>>>
>>> Would it make sense to define string constants on FileSystemView
>>> as otherwise people have to spell these exactly right without compiler
>>> help ?
>>>
>>> Also I expect (hope!) that we do not assert any privileges here so there
>>> will be a SecurityException if the caller does not have the necessary
>>> permissions.
>>> That should be documented.
>>>
>>> I find it odd that isLink(File) catches FNFE and just returns "false"
>>> like this
>>> was a normal file. Why is that ? In fact I find it particularly odd
>>> since
>>> getLinkLocation() *does* throw FNFE if it does not exist.
>>
>>     I guess the new code should follow the rules which are used by
>> other methods in the same class, most of them catch FNFE and return
>> some default value. Also most of them returns default value if the
>> passed File is null. Anyway I think that NPE is better than IAE. At
>> least we should discuss this.
> Could you explain why NPE is better?

Because it is caused by incorrect usage of null, for which NPE was created.

I supposed in case of an incorrect
> method usage IAE is more precise than generic NPE.
> The FNFE is used in some methods of the class. I think that is justified
> if the linked file is not found. In other cases it is caught.

There are still inconsistency. The isFileSystem(), isParent(), 
getSystemIcon, getSystemDisplayName() etc do not throw an exception in 
case of null, but return some default value(null,true,false). Same for 
FileNotFoundException() most of the methods just catch this exception 
and return the default value.

>>
>> I am not sure why this methods are static unlike old/others methods().
> I agree, we should be following the class "style", so I have removed
> static modifiers.
> The updated webrev:
> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.02/
>>
>> public static Object get(String key) {}
>>     Probably this method too flexible? What kind of use case for this
>> method inside the users application? How the user will know which
>> parameters to use in a cross-platform manner?
>>
>> For example "fileChooserDefaultFolder" property already covered by
>> FileSystemView.getDefaultDirectory(), the "roots" is covered by
>> getRoots().
> I don't think that we should elaborate a new Shell API in this fix,
> because we initially aimed to make the minimal change we can to support
> NetBeans ShellFolder extension.  We did a poll on the public alias which
> showed nobody else need this API to be opened.
>>
>>
>>>
>>> Also the docs casually say
>>> "a shell interpreted link" and "platform shell" without explaining
>>> what they mean by a shell. Should this term be used at all or
>>> should the docs describe this in some other words ?
>>>
>>> getLinkLocation says
>>>
>>> "Returns a file linked to the specified file if the specified file"
>>>
>>> What that reads like to me is that you get back a link if
>>> you pass in a regular file, whereas (I believe) you mean
>>> the opposite.
>>>
>>> I think you mean :
>>> "Returns the regular file referenced by the specified link file"
>>>
>>> I also note that one of the uses we located was of
>>> ShellFolder.getShellFolder(File)
>>> That internal API returns a ShellFolder but it we expose that it would
>>> have to
>>> be the java.io.File superclass I expect.
>>>
>>> -phil.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -phil.
>>>
>>>
>>> On 10/26/2015 06:51 AM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8081722
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.00
>>>>
>>>> As the solution it is suggested to have 3 new static methods in the
>>>> javax.swing.filechooser.FileSystemView class. Those methods proxy
>>>> sun.awt.shell.ShellFolder calls and it is enough to cover NetBeans
>>>> request. getShellFolder() method is not added because it returns the
>>>> ShellFolder instance which is not for public use under the proposed
>>>> approach.
>>>> The CCC request will be rework when the fix is approved.
>>>>
>>>> --Semyon
>>>
>>
>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Wed Jan 20 12:48:33 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 20 Jan 2016 15:48:33 +0300
Subject: <Swing Dev> Review request for JDK-8139213 : Mac OS X Aqua Look
 and Feel: JOptionPane can truncate the first button.
In-Reply-To: <813582c6-ed28-4fd3-a85b-14e2f29be7d7@default>
References: <567b8957-bded-44ad-83de-65e16a529910@default>
	<5361f711-9cec-4744-a22e-d789cc6f5936@default>
	<569E566D.9040500@oracle.com>
	<97028995-8e4c-42d2-abd7-0a7cb0317fc8@default>
	<569F709D.7000204@oracle.com>
	<813582c6-ed28-4fd3-a85b-14e2f29be7d7@default>
Message-ID: <569F8221.9060206@oracle.com>

On 1/20/2016 3:45 PM, Rajeev Chamyal wrote:
> Hello Alexandr,
>
> Thanks for the review.
> I have updated the webrev as suggested.
> http://cr.openjdk.java.net/~rchamyal/8139213/webrev.01/

    The fix looks good to me.

    Thanks,
    Alexandr.

>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexander Scherbatiy
> Sent: 20 January 2016 17:04
> To: Rajeev Chamyal
> Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8139213 : Mac OS X Aqua Look and Feel: JOptionPane can truncate the first button.
>
> On 1/20/2016 8:11 AM, Rajeev Chamyal wrote:
>> Hello Alexandr,
>>
>> Thanks for the review.
>>
>> Yes, we can call minimumLayoutSize(Container) of parent class but in
>> this case also again we need to check if any of the child components
>> are setting preferred size and compare it with the default values.
>>
>> And after this we need to find a delta that needs to be added to the
>> minimum size obtained from the parent class.
>>
>> The current webrev code I feel is much cleaner than getting the size
>> from parent class.
>>
>       The parent class also includes preffered sizes. It looks like it is possible to do something like:
>       ---------------
>       int kButtonLayoutSizeWidth = extraWidth
>               + (kOKCancelButtonWidth * numChildren)
>               + (numChildren - 1) * padding;
>       int kButtonLayoutSizeHeight = extraHeight + kButtonHeight;
>
>       Dimension size = super.minimumLayoutSize(c);
>       size.width = Math.max(size.width, kButtonLayoutSizeWidth);
>       size.height = Math.max(size.height, kButtonLayoutSizeHeight);
>      ---------------
>
>    Thanks,
>    Alexandr.
>
>> Regards,
>>
>> Rajeev Chamyal
>>
>> *From:*Alexander Scherbatiy
>> *Sent:* 19 January 2016 21:00
>> *To:* Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan;
>> swing-dev at openjdk.java.net
>> *Subject:* Re: Review request for JDK-8139213 : Mac OS X Aqua Look and
>> Feel: JOptionPane can truncate the first button.
>>
>> On 19/01/16 15:48, Rajeev Chamyal wrote:
>>
>>      Hello All,
>>
>>        
>>
>>      Gentle reminder for review.
>>
>>        
>>
>>      Regards,
>>
>>      Rajeev Chamyal
>>
>>        
>>
>>      -----Original Message-----
>>
>>      From: Rajeev Chamyal
>>
>>      Sent: 13 January 2016 16:37
>>
>>      To: Sergey Bylokhov; Alexander Scherbatiy; Prasanta
>> Sadhukhan;swing-dev at openjdk.java.net
>> <mailto:swing-dev at openjdk.java.net>
>>
>>      Subject: Review request for JDK-8139213 : Mac OS X Aqua Look and Feel: JOptionPane can truncate the first button.
>>
>>        
>>
>>      Hello All,
>>
>>        
>>
>>      Please review the following fix for Jdk9:
>>
>>        
>>
>>      Bug :https://bugs.openjdk.java.net/browse/JDK-8139213
>>
>>      Webrev :http://cr.openjdk.java.net/~rchamyal/8139213/webrev.00/
>> <http://cr.openjdk.java.net/%7Erchamyal/8139213/webrev.00/>
>>
>>        
>>
>>      Issue : In Mac OS X Aqua LAF JOptionPane truncates the first button if multiple buttons are added to it.
>>
>>        
>>
>>      Cause: AquaButtonAreaLayout class is not overriding base class method minimumLayoutSize as a result it is not taking to account the default button width for Aqua LAF.
>>
>>      Hence it is calculating incorrect dimensions for JOptionPane which results in truncation of button.
>>
>>        
>>
>>      Fix: Overriding minimumLayoutSize in AquaButtonAreaLayout to consider default button width and height while calculating minimum size for JOptionPane.
>>
>>
>>    Is it possible to call  the minimumLayoutSize(Container) from the
>> super class and adjust the returned size to take the default button
>> size into account?
>>
>>    Thanks,
>>    Alexandr.
>>
>>        
>>
>>        
>>
>>      Regards,
>>
>>      Rajeev Chamyal
>>



From avik.niyogi at oracle.com  Wed Jan 20 15:45:50 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 20 Jan 2016 21:15:50 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <569F7E77.2050807@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> <569F7E77.2050807@oracle.com>
Message-ID: <04A9900B-EDDB-4D5D-A6D7-0771AE454332@oracle.com>

The fix is for Aqua Look and Feel. It works after the fix on JDK9

> On 20-Jan-2016, at 6:02 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Avik.
> The test still pass before the fix, but it should fail.
> 
> On 20/01/16 14:00, Alexander Scherbatiy 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
>>> *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>> 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>> 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>> 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>> 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>>
>>>                            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>>
>>>                                    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>>
>>>                                            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>>
>>>                                                    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>>
>>>                                                            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  Wed Jan 20 16:18:41 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Jan 2016 19:18:41 +0300
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: <04A9900B-EDDB-4D5D-A6D7-0771AE454332@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> <569F7E77.2050807@oracle.com>
	<04A9900B-EDDB-4D5D-A6D7-0771AE454332@oracle.com>
Message-ID: <569FB361.9020505@oracle.com>

On 20/01/16 18:45, Avik Niyogi wrote:
> The fix is for Aqua Look and Feel. It works after the fix on JDK9

correct, it is for aqua and it works on jdk9. My point was that it works 
without the fix also, this is incorrect behavior, it should not pass 
before the fix.

>
>> On 20-Jan-2016, at 6:02 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> Hi, Avik.
>> The test still pass before the fix, but it should fail.
>>
>> On 20/01/16 14:00, Alexander Scherbatiy 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
>>>> *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>> 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>> 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>> 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>> 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>>
>>>>                             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>>
>>>>                                     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>>
>>>>                                             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>>
>>>>                                                     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>>
>>>>                                                             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  Wed Jan 20 17:05:07 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Jan 2016 20:05:07 +0300
Subject: <Swing Dev> Review Request of 8146321: [macosx] JInternalFrame
 frame icon in wrong position on Mac L&F if icon is not ImageIcon
In-Reply-To: <7DC88C61-FFB3-494A-A94C-9728DD29121F@oracle.com>
References: <431B2640-2D19-4EFC-824E-52AE3D25D2D8@oracle.com>
	<56973AEA.1040308@oracle.com>
	<BEB3BF05-B31A-4595-BCBB-E9DC915AED19@oracle.com>
	<13420C14-4119-4EF4-A037-1F4C2BF87E3C@oracle.com>
	<328DE551-87E2-4D51-89DC-AA7BAE40B610@oracle.com>
	<569F6B96.8070309@oracle.com>
	<7DC88C61-FFB3-494A-A94C-9728DD29121F@oracle.com>
Message-ID: <569FBE43.1080705@oracle.com>

On 20/01/16 18:43, Avik Niyogi wrote:
> if ((icon.getIconWidth() > sMaxIconWidth
>                  || icon.getIconHeight() > sMaxIconHeight)) {
>              final Graphics2D g2 = (Graphics2D) g;
>              final AffineTransform savedAT = g2.getTransform();
>              g2.scale((float)sMaxIconWidth/icon.getIconWidth(),
>                      (float)sMaxIconWidth/icon.getIconHeight());
>              icon.paintIcon(frame, g2, x, y);
>              g2.setTransform(savedAT);
>          }

This code does not take into account that x,y whcih are passed to the 
paintIcon should be adjusted, because after the scale they contain 
incorrect starting points.

>
> then for a test code with the following:
>
> import java.awt.*;
> import javax.swing.*;
>
> public class JInternalFrameBug {
>
>     public static void main(String[] args) {
>        SwingUtilities.invokeLater(
>              new Runnable() {
>                 public void run() {
>                    try {
>
>   UIManager.setLookAndFeel("com.apple.laf.AquaLookAndFeel"); }
>                    catch(Exception e) {
>                       System.out.println("This is not a Mac.");
>                       return;
>                    }
>                    JFrame f = new JFrame();
>                    f.setSize(400, 400);
>                    JDesktopPane dtp = new JDesktopPane();
>                    JInternalFrame jif = new JInternalFrame();
>                    jif.setTitle("Test");
>                    jif.setFrameIcon(new
> ImageIcon("/Users/avniyogi/Downloads/FeedbinNotifier-master/FeedbinNotifier/Images.xcassets/AppIcon.appiconset/icon_128x128 at 2x.png"));
>                    jif.setSize(200, 200);
>                    jif.setVisible(true);
>                    dtp.add(jif);
>
>                    f.getContentPane().setLayout(new BorderLayout());
>                    f.getContentPane().add(dtp, "Center");
>                    f.setVisible(true);
>                 }
>              });
>     }
> }
>
> results in this:
>
>
>
>> On 20-Jan-2016, at 4:42 pm, Alexander Scherbatiy
>> <alexandr.scherbatiy at oracle.com
>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>
>> On 1/20/2016 7:59 AM, Avik Niyogi wrote:
>>> Hi All,
>>> A gentle reminder, please review my code changes as in the webrev
>>> below in the mail trail.
>>> With Regards,
>>> Avik Niyogi
>>>> On 18-Jan-2016, at 3:01 pm, Avik Niyogi <avik.niyogi at oracle.com
>>>> <mailto:avik.niyogi at oracle.com> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>
>>>> Hi Sergey,
>>>>
>>>> Please review the webrev taking inputs as per the discussion before:
>>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.01/>
>>
>>    The idea was to scale the graphics that the drawn icon fits to the
>> target sizes.
>>    Something like:
>>       --------
>>       g2d.scale(targetIconWidth/icon.getWidth(),
>> targetIconHeight/icon.getHeight());
>>       icon.paintIcon(frame, g2d, x, y);
>>      ---------
>>
>>   This should work not only for ImageIcon but for any type of icons.
>>
>>   Thanks,
>>   Alexandr.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>
>>>>> On 14-Jan-2016, at 12:55 pm, Avik Niyogi <avik.niyogi at oracle.com
>>>>> <mailto:avik.niyogi at oracle.com> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>
>>>>> Hi Sergey,
>>>>> I have verified it with the test case as well. If a test case
>>>>> overrides these methods to imply a change with icons larger than
>>>>> 16x16 it will show that for ImageIcon and Icon as before. The
>>>>> resize of ImageIcon is only in case it has an image file that it
>>>>> will try to fit. I had a similar query myself and have found out
>>>>> that *getImage()* exists for ImageIcon class only and not Icon class.
>>>>> Example:
>>>>> private static void createImageIconUI(final String lookAndFeelString)
>>>>>            throws Exception {
>>>>> SwingUtilities.invokeAndWait(new Runnable() {
>>>>>            @Override
>>>>>            public void run() {
>>>>>                desktopPane = new JDesktopPane();
>>>>>                internalFrame = new JInternalFrame();
>>>>>                frame = new JFrame();
>>>>> internalFrame.setTitle(lookAndFeelString);
>>>>>                titleImageIcon = new ImageIcon() {
>>>>>                    @Override
>>>>>                    public int getIconWidth() {
>>>>>                        return 16;
>>>>>                    }
>>>>>
>>>>>                    @Override
>>>>>                    public int getIconHeight() {
>>>>>                        return 16;
>>>>>                    }
>>>>>
>>>>>                    @Override
>>>>>                    public void paintIcon(
>>>>> Component c, Graphics g, int x, int y) {
>>>>> g.setColor(java.awt.Color.black);
>>>>> *g.fillRect(x, y, 50, 50);*
>>>>>                    }
>>>>>                };
>>>>> internalFrame.setFrameIcon(titleImageIcon);
>>>>> internalFrame.setSize(500, 200);
>>>>> internalFrame.setVisible(true);
>>>>> desktopPane.add(internalFrame);
>>>>>
>>>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>> frame.getContentPane().setLayout(new BorderLayout());
>>>>> frame.getContentPane().add(desktopPane, "Center");
>>>>> frame.setSize(500, 500);
>>>>> frame.setLocationRelativeTo(null);
>>>>> frame.setVisible(true);
>>>>> frame.toFront();
>>>>>            }
>>>>>        });
>>>>>    }
>>>>> In this case the ImageIcon will NOT be resized to 16 x 16 even
>>>>> before my fix was implemented. That resize as shown in code is
>>>>> *only for Image files to fit in default ImageIcon* size as returned
>>>>> from the getIconHeight() and getIconWidth() methods. If user
>>>>> changes the ImageIcon size as in the example, that is upto to user
>>>>> to choose to do so and no control exists to prevent that. *So, with
>>>>> or without my fix, this behaviour will be same for ImageIcon and
>>>>> Icon custom instances.*
>>>>> Hope this clarifies the query.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>
>>>>>> On 14-Jan-2016, at 11:36 am, Sergey Bylokhov
>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>>
>>>>>> Hi, Avik.
>>>>>> In the fix you update getIconWidth() and getIconHeight, so now we
>>>>>> take the Icon into account. but it seems if the Icon is bigger
>>>>>> that the maximum size it will not be resided to 16x16, right?
>>>>>>
>>>>>> On 14/01/16 07:49, Avik Niyogi wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>
>>>>>>> *Bug:*
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146321
>>>>>>>
>>>>>>> *Webrev:*
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.00/>
>>>>>>>
>>>>>>> *Issue:*
>>>>>>> Under the Mac Look&Feel, if an icon type other than an ImageIcon
>>>>>>> is used
>>>>>>> in JInternalFrame.setFrameIcon(),
>>>>>>> the icon will show up in the wrong position.
>>>>>>>
>>>>>>> *Cause:*
>>>>>>> the "instanceof Icon" was not checked for. Also, customs
>>>>>>> ImageIcon with
>>>>>>> color fill (and no image URL) which would
>>>>>>> have resulted in null value for resized ImageIcon image was not well
>>>>>>> handled.
>>>>>>>
>>>>>>> *Fix:*
>>>>>>> All places in Aqua LAF where "instanceof Icon? (and not just
>>>>>>> ImageIcon
>>>>>>> class) is required,
>>>>>>> inputs were added after significant analyses.
>>>>>>> Check for null for getImage was done to remove a Null Pointer
>>>>>>> Exception.
>>>>>>>
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Jan 21 01:25:40 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Jan 2016 04:25:40 +0300
Subject: <Swing Dev> Review Request for Bug 8146320 JTextField ignores
 setPreferredSize when having columns
In-Reply-To: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>
References: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>
Message-ID: <56A03394.4010405@oracle.com>

Hi, Prem.
This change actually contradicts to the specification of JTextField.

Check the specification:
     /**
      * Constructs a new <code>JTextField</code> that uses the given text
      * storage model and the given number of columns.
      * @param columns  the number of columns to use to calculate
      *   the preferred width >= 0; if <code>columns</code>
      *   is set to zero, the preferred width will be whatever
      *   naturally results from the component implementation
      */
     public JTextField(Document doc, String text, int columns) {

     /**
      * Returns the preferred size <code>Dimensions</code> needed for this
      * <code>TextField</code>.  If a non-zero number of columns has been
      * set, the width is set to the columns multiplied by
      * the column width.
      *
      * @return the dimension of this textfield
      */
     public Dimension getPreferredSize() {

Note that this class explicitly states in two places that if the columns 
are set then they will be used for calculation of the preferred size. So 
such change will require a javadoc update.

PS: I wonder why the same functionality in JTextArea is specified and 
implemented differently....



On 18/01/16 13:46, Prem Balakrishnan wrote:
> Hi,
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-8146320
>
> *Webrev:*http://cr.openjdk.java.net/~rchamyal/prem/8146320/webrev.00/
>
> *Issue:*
>
> JTextField ignores setPreferredSize when having columns
>
> *Cause:*
>
> JTextField setPreferredSize is not actually ignored , when column value
> is set>0.
>
> While retrieving the values set using getPreferredSize(), wrong values
> were returned.
>
> *Fix:*
>
> Check added, if Column>0 and if Preferred size is not set after setting
> columns, while retrieving values.
>
> Regards,
> Prem
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Jan 21 01:31:58 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Jan 2016 04:31:58 +0300
Subject: <Swing Dev> JDK9 Review Request for JDK-7104635 HTMLEditorKit
 fails to write down some html files
In-Reply-To: <5fe87987-972f-498d-8a8a-420eedac9bbd@default>
References: <c0ae2d3b-14cb-48e6-934b-9d517c0d3155@default>
	<56673B25.4010706@oracle.com>
	<399c7b07-836f-426b-b5cf-48d7b8327045@default>
	<5fe87987-972f-498d-8a8a-420eedac9bbd@default>
Message-ID: <56A0350E.4010309@oracle.com>

Looks fine.

On 17/12/15 12:31, Rajeev Chamyal wrote:
> Hello,
>
> Gentle reminder for review.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Rajeev Chamyal
> Sent: 10 December 2015 22:42
> To: Sergey Bylokhov; Alexander Scherbatiy; swing-dev at openjdk.java.net; Prasanta Sadhukhan
> Subject: RE: <Swing Dev> JDK9 Review Request for JDK-7104635 HTMLEditorKit fails to write down some html files
>
> Hello Sergey,
>
> Thanks for the review.
> indentLevel is decremented in AbstractWriter :: incrIndent method as well.
> Here also we have a check before decrementing indentLevel.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 09 December 2015 01:49
> To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net; Prasanta Sadhukhan
> Subject: Re: <Swing Dev> JDK9 Review Request for JDK-7104635 HTMLEditorKit fails to write down some html files
>
> Hi, Rajeev.
> Did you check another place where it is decremented?
> Also it seems this change in some way contradicts the specification of
> getIndentLevel() method, because it is quite general:
>       /**
>        * Returns the current indentation level. That is, the number of times
>        * <code>incrIndent</code> has been invoked minus the number of times
>        * <code>decrIndent</code> has been invoked.
>        * @return the current indentation level
>        * @since 1.3
>        */
>
> it is unclear can it return negative value or not.
>
> On 26/11/15 11:36, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-7104635
>>
>> Webrev: http://cr.openjdk.java.net/~rchamyal/7104635/webrev.00/
>>
>> Issue: If the minimized HTML has spaces the writing is failing with
>> index out of bounds exception.
>>
>> Cause: The AbstractWriter::indent method is passing negative length of
>> indentChars to writer.
>>
>> Fix: Added checks for negative value while decrementing the
>> AbstractWriter::indentlevel.
>>
>> Regards,
>>
>> Rajeev Chamyal
>>
>
>
> --
> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From avik.niyogi at oracle.com  Thu Jan 21 02:56:31 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 21 Jan 2016 08:26:31 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <569F68DD.3010705@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>
Message-ID: <6398FB4E-663B-4DC6-97CE-19A0BB3574D4@oracle.com>

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> 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
>> *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>> 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>> 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>> 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>> 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>>
>>                            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>>
>>                                    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>>
>>                                            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>>
>>                                                    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>>
>>                                                            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.
>> 
> 

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

From avik.niyogi at oracle.com  Thu Jan 21 03:00:10 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 21 Jan 2016 08:30:10 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <6398FB4E-663B-4DC6-97CE-19A0BB3574D4@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>
Message-ID: <28266B2D-3427-4938-BC7D-9C62E1E43BC4@oracle.com>

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> 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/~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>>> 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>>> 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/~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>>> 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/ <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/~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/ <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 <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/~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/>>
>>>                                        <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>>
>>>                                            <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 <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/~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/>>
>>>                                                <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>>
>>>                                                    <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/~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/ <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 <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 <https://bugs.openjdk.java.net/browse/JDK-8015748>
>>> 
>>>                                                                *Webrev:*
>>>                                                                http://cr.openjdk.java.net/~aniyogi/8015748/webrev.00/ <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/>>
>>>                                                                <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 <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/20160121/dda6d316/attachment.html>

From avik.niyogi at oracle.com  Thu Jan 21 03:49:45 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 21 Jan 2016 09:19:45 +0530
Subject: <Swing Dev> Review request for 8015748: JProgressbar with Aqua
	LaF ignores
	JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
	call
In-Reply-To: <28266B2D-3427-4938-BC7D-9C62E1E43BC4@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>
Message-ID: <A53CB1FD-28A4-4B22-BDF9-2268A122C764@oracle.com>

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> 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/~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>>> 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>>> 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/~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>>> 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/ <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/~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/ <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 <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/~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/>>
>>>>                                        <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>>
>>>>                                            <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 <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/~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/>>
>>>>                                                <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>>
>>>>                                                    <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/~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/ <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 <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 <https://bugs.openjdk.java.net/browse/JDK-8015748>
>>>> 
>>>>                                                                *Webrev:*
>>>>                                                                http://cr.openjdk.java.net/~aniyogi/8015748/webrev.00/ <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/>>
>>>>                                                                <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 <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/20160121/a5e8cae2/attachment.html>

From prem.balakrishnan at oracle.com  Thu Jan 21 05:52:05 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Wed, 20 Jan 2016 21:52:05 -0800 (PST)
Subject: <Swing Dev> Review Request for Bug 8146320 JTextField ignores
 setPreferredSize when having columns
In-Reply-To: <56A03394.4010405@oracle.com>
References: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>
	<56A03394.4010405@oracle.com>
Message-ID: <1797a2d0-95f7-49df-abfa-62138fcb280d@default>

Hi Sergey, Alexander

Updated Webrev: documentation updated respectively
http://cr.openjdk.java.net/~rchamyal/prem/8146320/webrev.01/ 

Regarding JTextArea:
The behavior of setting preferred size and columns/rows are similar to JTextField.
i.e., If Columns and rows are set, the values are used to calculate the area size.
	If setPreferredSize() is called explicitly, then the size is modified respectively,
      overriding the size set by columns/rows, But when getPreferredSize() is called, 
      it still returns the size multiplied by colum/row. 
	Hence check similar to JTextField is required in case of JTextArea.
	Should I update changes to JTextArea ????

Regards,
Prem



-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, January 21, 2016 6:56 AM
To: Prem Balakrishnan; Alexander Scherbatiy; Ambarish Rapte; Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re: Review Request for Bug 8146320 JTextField ignores setPreferredSize when having columns

Hi, Prem.
This change actually contradicts to the specification of JTextField.

Check the specification:
     /**
      * Constructs a new <code>JTextField</code> that uses the given text
      * storage model and the given number of columns.
      * @param columns  the number of columns to use to calculate
      *   the preferred width >= 0; if <code>columns</code>
      *   is set to zero, the preferred width will be whatever
      *   naturally results from the component implementation
      */
     public JTextField(Document doc, String text, int columns) {

     /**
      * Returns the preferred size <code>Dimensions</code> needed for this
      * <code>TextField</code>.  If a non-zero number of columns has been
      * set, the width is set to the columns multiplied by
      * the column width.
      *
      * @return the dimension of this textfield
      */
     public Dimension getPreferredSize() {

Note that this class explicitly states in two places that if the columns are set then they will be used for calculation of the preferred size. So such change will require a javadoc update.

PS: I wonder why the same functionality in JTextArea is specified and implemented differently....



On 18/01/16 13:46, Prem Balakrishnan wrote:
> Hi,
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-8146320
>
> *Webrev:*http://cr.openjdk.java.net/~rchamyal/prem/8146320/webrev.00/
>
> *Issue:*
>
> JTextField ignores setPreferredSize when having columns
>
> *Cause:*
>
> JTextField setPreferredSize is not actually ignored , when column value
> is set>0.
>
> While retrieving the values set using getPreferredSize(), wrong values
> were returned.
>
> *Fix:*
>
> Check added, if Column>0 and if Preferred size is not set after setting
> columns, while retrieving values.
>
> Regards,
> Prem
>


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Thu Jan 21 06:16:01 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 21 Jan 2016 09:16:01 +0300
Subject: <Swing Dev> [9] Review Request for 8081722: Provide public API
 for file hierarchy provided by sun.awt.shell.ShellFolder
In-Reply-To: <569F8177.9050308@oracle.com>
References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com>
	<5637C2DD.6060801@oracle.com> <56543585.60401@oracle.com>
	<569F8177.9050308@oracle.com>
Message-ID: <56A077A1.3040904@oracle.com>



On 1/20/2016 3:45 PM, Sergey Bylokhov wrote:
> On 24/11/15 13:01, Semyon Sadetsky wrote:
>>
>>
>> On 11/2/2015 11:09 PM, Sergey Bylokhov wrote:
>>> On 29.10.15 21:30, Phil Race wrote:
>>>> We should specify what happens if you pass in to get(String)
>>>> a) null
>>>> b) an unrecognised name.
>>>>
>>>> Would it make sense to define string constants on FileSystemView
>>>> as otherwise people have to spell these exactly right without compiler
>>>> help ?
>>>>
>>>> Also I expect (hope!) that we do not assert any privileges here so 
>>>> there
>>>> will be a SecurityException if the caller does not have the necessary
>>>> permissions.
>>>> That should be documented.
>>>>
>>>> I find it odd that isLink(File) catches FNFE and just returns "false"
>>>> like this
>>>> was a normal file. Why is that ? In fact I find it particularly odd
>>>> since
>>>> getLinkLocation() *does* throw FNFE if it does not exist.
>>>
>>>     I guess the new code should follow the rules which are used by
>>> other methods in the same class, most of them catch FNFE and return
>>> some default value. Also most of them returns default value if the
>>> passed File is null. Anyway I think that NPE is better than IAE. At
>>> least we should discuss this.
>> Could you explain why NPE is better?
>
> Because it is caused by incorrect usage of null, for which NPE was 
> created.
>
> I supposed in case of an incorrect
>> method usage IAE is more precise than generic NPE.
>> The FNFE is used in some methods of the class. I think that is justified
>> if the linked file is not found. In other cases it is caught.
>
> There are still inconsistency. The isFileSystem(), isParent(), 
> getSystemIcon, getSystemDisplayName() etc do not throw an exception in 
> case of null, but return some default value(null,true,false). Same for 
> FileNotFoundException() most of the methods just catch this exception 
> and return the default value.
The methods you've mentioned do not throw NPE but other methods in the 
FSV class do throw NPE if called with null argument.
Your point that there is inconsistency sounds a bit odd.  If this 
reasoning we can not add a new method which throws an exception to the 
class not having methods throwing this exception. How methods of the FSV 
class related to different aspects of the file system can be 
inconsistent? They are simply not related to each other.
>
>>>
>>> I am not sure why this methods are static unlike old/others methods().
>> I agree, we should be following the class "style", so I have removed
>> static modifiers.
>> The updated webrev:
>> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.02/
>>>
>>> public static Object get(String key) {}
>>>     Probably this method too flexible? What kind of use case for this
>>> method inside the users application? How the user will know which
>>> parameters to use in a cross-platform manner?
>>>
>>> For example "fileChooserDefaultFolder" property already covered by
>>> FileSystemView.getDefaultDirectory(), the "roots" is covered by
>>> getRoots().
>> I don't think that we should elaborate a new Shell API in this fix,
>> because we initially aimed to make the minimal change we can to support
>> NetBeans ShellFolder extension.  We did a poll on the public alias which
>> showed nobody else need this API to be opened.
>>>
>>>
>>>>
>>>> Also the docs casually say
>>>> "a shell interpreted link" and "platform shell" without explaining
>>>> what they mean by a shell. Should this term be used at all or
>>>> should the docs describe this in some other words ?
>>>>
>>>> getLinkLocation says
>>>>
>>>> "Returns a file linked to the specified file if the specified file"
>>>>
>>>> What that reads like to me is that you get back a link if
>>>> you pass in a regular file, whereas (I believe) you mean
>>>> the opposite.
>>>>
>>>> I think you mean :
>>>> "Returns the regular file referenced by the specified link file"
>>>>
>>>> I also note that one of the uses we located was of
>>>> ShellFolder.getShellFolder(File)
>>>> That internal API returns a ShellFolder but it we expose that it would
>>>> have to
>>>> be the java.io.File superclass I expect.
>>>>
>>>> -phil.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 10/26/2015 06:51 AM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8081722
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.00
>>>>>
>>>>> As the solution it is suggested to have 3 new static methods in the
>>>>> javax.swing.filechooser.FileSystemView class. Those methods proxy
>>>>> sun.awt.shell.ShellFolder calls and it is enough to cover NetBeans
>>>>> request. getShellFolder() method is not added because it returns the
>>>>> ShellFolder instance which is not for public use under the proposed
>>>>> approach.
>>>>> The CCC request will be rework when the fix is approved.
>>>>>
>>>>> --Semyon
>>>>
>>>
>>>
>>
>
>



From prasanta.sadhukhan at oracle.com  Thu Jan 21 07:48:48 2016
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Thu, 21 Jan 2016 13:18:48 +0530
Subject: <Swing Dev> Review request for JDK-8139213 : Mac OS X Aqua Look
 and Feel: JOptionPane can truncate the first button.
In-Reply-To: <569F8221.9060206@oracle.com>
References: <567b8957-bded-44ad-83de-65e16a529910@default>
	<5361f711-9cec-4744-a22e-d789cc6f5936@default>
	<569E566D.9040500@oracle.com>
	<97028995-8e4c-42d2-abd7-0a7cb0317fc8@default>
	<569F709D.7000204@oracle.com>
	<813582c6-ed28-4fd3-a85b-14e2f29be7d7@default>
	<569F8221.9060206@oracle.com>
Message-ID: <56A08D60.7070301@oracle.com>

Fix looks good to me.

Regards
Prasanta
On 1/20/2016 6:18 PM, Alexander Scherbatiy wrote:
> On 1/20/2016 3:45 PM, Rajeev Chamyal wrote:
>> Hello Alexandr,
>>
>> Thanks for the review.
>> I have updated the webrev as suggested.
>> http://cr.openjdk.java.net/~rchamyal/8139213/webrev.01/
>
>    The fix looks good to me.
>
>    Thanks,
>    Alexandr.
>
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexander Scherbatiy
>> Sent: 20 January 2016 17:04
>> To: Rajeev Chamyal
>> Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>> Subject: Re: Review request for JDK-8139213 : Mac OS X Aqua Look and 
>> Feel: JOptionPane can truncate the first button.
>>
>> On 1/20/2016 8:11 AM, Rajeev Chamyal wrote:
>>> Hello Alexandr,
>>>
>>> Thanks for the review.
>>>
>>> Yes, we can call minimumLayoutSize(Container) of parent class but in
>>> this case also again we need to check if any of the child components
>>> are setting preferred size and compare it with the default values.
>>>
>>> And after this we need to find a delta that needs to be added to the
>>> minimum size obtained from the parent class.
>>>
>>> The current webrev code I feel is much cleaner than getting the size
>>> from parent class.
>>>
>>       The parent class also includes preffered sizes. It looks like 
>> it is possible to do something like:
>>       ---------------
>>       int kButtonLayoutSizeWidth = extraWidth
>>               + (kOKCancelButtonWidth * numChildren)
>>               + (numChildren - 1) * padding;
>>       int kButtonLayoutSizeHeight = extraHeight + kButtonHeight;
>>
>>       Dimension size = super.minimumLayoutSize(c);
>>       size.width = Math.max(size.width, kButtonLayoutSizeWidth);
>>       size.height = Math.max(size.height, kButtonLayoutSizeHeight);
>>      ---------------
>>
>>    Thanks,
>>    Alexandr.
>>
>>> Regards,
>>>
>>> Rajeev Chamyal
>>>
>>> *From:*Alexander Scherbatiy
>>> *Sent:* 19 January 2016 21:00
>>> *To:* Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan;
>>> swing-dev at openjdk.java.net
>>> *Subject:* Re: Review request for JDK-8139213 : Mac OS X Aqua Look and
>>> Feel: JOptionPane can truncate the first button.
>>>
>>> On 19/01/16 15:48, Rajeev Chamyal wrote:
>>>
>>>      Hello All,
>>>
>>>
>>>      Gentle reminder for review.
>>>
>>>
>>>      Regards,
>>>
>>>      Rajeev Chamyal
>>>
>>>
>>>      -----Original Message-----
>>>
>>>      From: Rajeev Chamyal
>>>
>>>      Sent: 13 January 2016 16:37
>>>
>>>      To: Sergey Bylokhov; Alexander Scherbatiy; Prasanta
>>> Sadhukhan;swing-dev at openjdk.java.net
>>> <mailto:swing-dev at openjdk.java.net>
>>>
>>>      Subject: Review request for JDK-8139213 : Mac OS X Aqua Look 
>>> and Feel: JOptionPane can truncate the first button.
>>>
>>>
>>>      Hello All,
>>>
>>>
>>>      Please review the following fix for Jdk9:
>>>
>>>
>>>      Bug :https://bugs.openjdk.java.net/browse/JDK-8139213
>>>
>>>      Webrev :http://cr.openjdk.java.net/~rchamyal/8139213/webrev.00/
>>> <http://cr.openjdk.java.net/%7Erchamyal/8139213/webrev.00/>
>>>
>>>
>>>      Issue : In Mac OS X Aqua LAF JOptionPane truncates the first 
>>> button if multiple buttons are added to it.
>>>
>>>
>>>      Cause: AquaButtonAreaLayout class is not overriding base class 
>>> method minimumLayoutSize as a result it is not taking to account the 
>>> default button width for Aqua LAF.
>>>
>>>      Hence it is calculating incorrect dimensions for JOptionPane 
>>> which results in truncation of button.
>>>
>>>
>>>      Fix: Overriding minimumLayoutSize in AquaButtonAreaLayout to 
>>> consider default button width and height while calculating minimum 
>>> size for JOptionPane.
>>>
>>>
>>>    Is it possible to call  the minimumLayoutSize(Container) from the
>>> super class and adjust the returned size to take the default button
>>> size into account?
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>>
>>>
>>>      Regards,
>>>
>>>      Rajeev Chamyal
>>>
>



From andrej.golovnin at gmail.com  Thu Jan 21 07:50:59 2016
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Thu, 21 Jan 2016 08:50:59 +0100
Subject: <Swing Dev> Review Request for Bug 8146320 JTextField ignores
 setPreferredSize when having columns
In-Reply-To: <1797a2d0-95f7-49df-abfa-62138fcb280d@default>
References: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>
	<56A03394.4010405@oracle.com>
	<1797a2d0-95f7-49df-abfa-62138fcb280d@default>
Message-ID: <CAM6ZMz-Q28TZ2un8NnPgOhMDc68ks2rmr5zA6kvuLjHq8AsAUA@mail.gmail.com>

Hi all,

as a long time Swing developer I want to vote against this change.
This change may break the layout of existing applications and make
them unusable. This code exists for very long time. And it should stay
as is. The only change that you should make is to document the current
behaviour.

Please run the following application to see what this change may cause:

import java.awt.Dimension;
import java.awt.EventQueue;
import javax.swing.BoxLayout;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;
import javax.swing.WindowConstants;
import javax.swing.border.EmptyBorder;

/**
 * @author Andrej Golovnin
 */
public class Main {

    public static void main(String... argv) {
        EventQueue.invokeLater(Main::createAndShowUI);
    }

    private static void createAndShowUI() {
        JTextField jdk8 = new JTextField(10);
        jdk8.setPreferredSize(new Dimension(10, 20));

        JTextField jdk9 = new JDK9TextField(10);
        jdk9.setPreferredSize(new Dimension(10, 20));

        JPanel content = new JPanel();
        content.setBorder(new EmptyBorder(10, 10, 10 , 10));
        BoxLayout layout = new BoxLayout(content, BoxLayout.X_AXIS);
        content.setLayout(layout);

        content.add(jdk8);
        content.add(jdk9);

        JFrame frame = new JFrame("Bug 8146320");
        frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
        frame.setContentPane(content);
        frame.pack();
        frame.setVisible(true);
    }


    static class JDK9TextField extends JTextField {

        private Dimension prefSize;

        JDK9TextField(int columns) {
            super(columns);
        }

        @Override
        public Dimension getPreferredSize() {
            if (isPreferredSizeSet()) {
                return prefSize;
            }
            return super.getPreferredSize();
        }

        @Override
        public void setPreferredSize(Dimension preferredSize) {
            super.setPreferredSize(preferredSize);
            this.prefSize = preferredSize;
        }

    }

}

Best regards,
Andrej Golovnin


From prasanta.sadhukhan at oracle.com  Thu Jan 21 08:04:43 2016
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Thu, 21 Jan 2016 13:34:43 +0530
Subject: <Swing Dev> Review request for JDK-8146276 : Right aligned
 ToolBar component does not appear
In-Reply-To: <569F714C.1010302@oracle.com>
References: <37426965-3e73-4526-9ead-1acf10616ce5@default>
	<569E5E4E.7020400@oracle.com>
	<2ea3eb72-e562-4f93-aaa1-7e620095b196@default>
	<569F714C.1010302@oracle.com>
Message-ID: <56A0911B.80600@oracle.com>

FIx looks good to me too.

Regards
Prasanta

On 1/20/2016 5:06 PM, Alexander Scherbatiy wrote:
>
>   The fix looks good to me.
>
>   Thanks,
>   Alexandr.
>
> On 1/20/2016 9:52 AM, Rajeev Chamyal wrote:
>> Hello Alexandr,
>>
>> Thanks for the review.
>> This issue is seen only if we have glue added to any SynthToolBar.
>> While doing layoutContainer we need to distribute the empty space 
>> among glue and currently its  done by finding minimum width of parent 
>> using minimumLayoutSize which doesn't consider preferred size of 
>> child comps.
>> The preferred layout size is not getting called in this case. I have 
>> replaced the minimumLayoutSize with preferredLayoutSize and updated 
>> the webrev.
>> http://cr.openjdk.java.net/~rchamyal/8146276/webrev.01/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexander Scherbatiy
>> Sent: 19 January 2016 21:33
>> To: Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan; 
>> swing-dev at openjdk.java.net
>> Subject: Re: Review request for JDK-8146276 : Right aligned ToolBar 
>> component does not appear
>>
>> On 12/01/16 08:21, Rajeev Chamyal wrote:
>>> Hello All,
>>>
>>> Please review the following fix for Jdk9:
>>>
>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8146276
>>> Webrev: http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/
>>>
>>> Issue : Right aligned ToolBar component does not appear
>>> Cause: While calculating the minimum layout size for the components 
>>> SynthToolBar is not checking if preferred size is set for the 
>>> components.
>>>
>>> Fix: Updated the minimumLayoutSize method of SynthToolBarUI.java to 
>>> check preferred size of components as well.
>> Could you give more details why it is not enough to properly layout 
>> buttons when the minimum layout size is only calculated on the 
>> minimum size and the preferred layout size is based on the buttons 
>> preferred size?
>>
>>    Thanks,
>>    Alexandr.
>>> Regards,
>>> Rajeev Chamyal
>



From prem.balakrishnan at oracle.com  Thu Jan 21 10:46:53 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 21 Jan 2016 02:46:53 -0800 (PST)
Subject: <Swing Dev> Review Request for Bug 8146320 JTextField ignores
 setPreferredSize when having columns
In-Reply-To: <CAM6ZMz-Q28TZ2un8NnPgOhMDc68ks2rmr5zA6kvuLjHq8AsAUA@mail.gmail.com>
References: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>
	<56A03394.4010405@oracle.com>
	<1797a2d0-95f7-49df-abfa-62138fcb280d@default>
	<CAM6ZMz-Q28TZ2un8NnPgOhMDc68ks2rmr5zA6kvuLjHq8AsAUA@mail.gmail.com>
Message-ID: <1f46a740-13a9-434b-b221-e4bfcade730c@default>

Hi Andrej,

I executed the below test code.
Didn?t find any inconsistent behavior before and after the fix.
Can you give little brief description on the issues, which this fix may give rise to.

Regards,
Prem
I 

-----Original Message-----
From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] 
Sent: Thursday, January 21, 2016 1:21 PM
To: Prem Balakrishnan
Cc: Sergey Bylokhov; Alexander Scherbatiy; Ambarish Rapte; Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review Request for Bug 8146320 JTextField ignores setPreferredSize when having columns

Hi all,

as a long time Swing developer I want to vote against this change.
This change may break the layout of existing applications and make them unusable. This code exists for very long time. And it should stay as is. The only change that you should make is to document the current behaviour.

Please run the following application to see what this change may cause:

import java.awt.Dimension;
import java.awt.EventQueue;
import javax.swing.BoxLayout;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;
import javax.swing.WindowConstants;
import javax.swing.border.EmptyBorder;

/**
 * @author Andrej Golovnin
 */
public class Main {

    public static void main(String... argv) {
        EventQueue.invokeLater(Main::createAndShowUI);
    }

    private static void createAndShowUI() {
        JTextField jdk8 = new JTextField(10);
        jdk8.setPreferredSize(new Dimension(10, 20));

        JTextField jdk9 = new JDK9TextField(10);
        jdk9.setPreferredSize(new Dimension(10, 20));

        JPanel content = new JPanel();
        content.setBorder(new EmptyBorder(10, 10, 10 , 10));
        BoxLayout layout = new BoxLayout(content, BoxLayout.X_AXIS);
        content.setLayout(layout);

        content.add(jdk8);
        content.add(jdk9);

        JFrame frame = new JFrame("Bug 8146320");
        frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
        frame.setContentPane(content);
        frame.pack();
        frame.setVisible(true);
    }


    static class JDK9TextField extends JTextField {

        private Dimension prefSize;

        JDK9TextField(int columns) {
            super(columns);
        }

        @Override
        public Dimension getPreferredSize() {
            if (isPreferredSizeSet()) {
                return prefSize;
            }
            return super.getPreferredSize();
        }

        @Override
        public void setPreferredSize(Dimension preferredSize) {
            super.setPreferredSize(preferredSize);
            this.prefSize = preferredSize;
        }

    }

}

Best regards,
Andrej Golovnin


From andrej.golovnin at gmail.com  Thu Jan 21 11:19:12 2016
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Thu, 21 Jan 2016 12:19:12 +0100
Subject: <Swing Dev> Review Request for Bug 8146320 JTextField ignores
 setPreferredSize when having columns
In-Reply-To: <1f46a740-13a9-434b-b221-e4bfcade730c@default>
References: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>
	<56A03394.4010405@oracle.com>
	<1797a2d0-95f7-49df-abfa-62138fcb280d@default>
	<CAM6ZMz-Q28TZ2un8NnPgOhMDc68ks2rmr5zA6kvuLjHq8AsAUA@mail.gmail.com>
	<1f46a740-13a9-434b-b221-e4bfcade730c@default>
Message-ID: <CAM6ZMz8EHQ=0zJL8fCukJbmxRP3c3ACDLjp0+y6YoVw9keJWeA@mail.gmail.com>

Hi Perm,

I'm sorry, my mistake. To see the difference you must run the example
with JDK 8, e.g. without your patch. The example contains two fields
"jdk8" and "jdk9". The "jdk9" field simulates the behaviour of
JTextField with your patch. Both fields "jdk8" and "jdk9" should have
the same size on the screen. But after your patch the "jdk9" field is
only 10 pixel wide.

Suppose developers had following use case in the past:

We need a field which should be 10 columns wide and 20 pixels high.
The field must be inside of a panel with BoxLayout and laid out
horizontally from left to right.

What did they done in such situations:

JTextField field = new JTextField(10):
field.setPreferredSize(new Dimension(10, 20)); // The real width will
be calculated by JTextField using the number of columns.

JPanel content = new JPanel();
BoxLayout layout = new BoxLayout(content, BoxLayout.X_AXIS);
content.setLayout(layout);

content.add(field);

This code implements the use case above (from JavaDocs of BoxLayout:
BoxLayout attempts to arrange components at their preferred widths
(for horizontal layout) or heights (for vertical layout).). But your
change would break now this implementation. After your change the
field would have only the size of 10 pixels x 20 pixels ant not the
expected 10 columns x 20 pixels.

Best regards,
Andrej Golovnin


From Sergey.Bylokhov at oracle.com  Thu Jan 21 15:25:36 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Jan 2016 18:25:36 +0300
Subject: <Swing Dev> [9] Review Request for 8081722: Provide public API
 for file hierarchy provided by sun.awt.shell.ShellFolder
In-Reply-To: <56A077A1.3040904@oracle.com>
References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com>
	<5637C2DD.6060801@oracle.com> <56543585.60401@oracle.com>
	<569F8177.9050308@oracle.com> <56A077A1.3040904@oracle.com>
Message-ID: <56A0F870.7010602@oracle.com>

On 21/01/16 09:16, Semyon Sadetsky wrote:
>>
>> There are still inconsistency. The isFileSystem(), isParent(),
>> getSystemIcon, getSystemDisplayName() etc do not throw an exception in
>> case of null, but return some default value(null,true,false). Same for
>> FileNotFoundException() most of the methods just catch this exception
>> and return the default value.
> The methods you've mentioned do not throw NPE but other methods in the
> FSV class do throw NPE if called with null argument.

they raise NPE not an IAE. ok I am fine to use NPE.

Some other issue is inconsistency between isLink() vs getLinkLocation()
getLinkLocation() should "Returns {@code null} if the specified file is 
not a shell interpreted link", but isLink() return false if 
FileNotFoundException which means that getLinkLocation() should return null;

the next code can work incorrectly:
         FileSystemView fsv = FileSystemView.getFileSystemView();
         File file = "some unexisted file";
         if (fsv.isLink(file)) {
             if (fsv.getLinkLocation(file) == null) {
                 throw new RuntimeException();
             }
         } else {
             if (fsv.getLinkLocation(file) != null) {
                 throw new RuntimeException();
             }
         }

There are some checks in the code related to "C:\pagefile.sys" and 
"C:\Winnt\Profiles\joe\history\History.IE5" can you double check how the 
new methods will work with these files.


> Your point that there is inconsistency sounds a bit odd.  If this
> reasoning we can not add a new method which throws an exception to the
> class not having methods throwing this exception. How methods of the FSV
> class related to different aspects of the file system can be
> inconsistent? They are simply not related to each other.


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Fri Jan 22 06:34:31 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 22 Jan 2016 09:34:31 +0300
Subject: <Swing Dev> [9] Review Request for 8081722: Provide public API
 for file hierarchy provided by sun.awt.shell.ShellFolder
In-Reply-To: <56A0F870.7010602@oracle.com>
References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com>
	<5637C2DD.6060801@oracle.com> <56543585.60401@oracle.com>
	<569F8177.9050308@oracle.com> <56A077A1.3040904@oracle.com>
	<56A0F870.7010602@oracle.com>
Message-ID: <56A1CD76.2030406@oracle.com>



On 1/21/2016 6:25 PM, Sergey Bylokhov wrote:
> On 21/01/16 09:16, Semyon Sadetsky wrote:
>>>
>>> There are still inconsistency. The isFileSystem(), isParent(),
>>> getSystemIcon, getSystemDisplayName() etc do not throw an exception in
>>> case of null, but return some default value(null,true,false). Same for
>>> FileNotFoundException() most of the methods just catch this exception
>>> and return the default value.
>> The methods you've mentioned do not throw NPE but other methods in the
>> FSV class do throw NPE if called with null argument.
>
> they raise NPE not an IAE. ok I am fine to use NPE.
>
> Some other issue is inconsistency between isLink() vs getLinkLocation()
> getLinkLocation() should "Returns {@code null} if the specified file 
> is not a shell interpreted link", but isLink() return false if 
> FileNotFoundException which means that getLinkLocation() should return 
> null;
>
> the next code can work incorrectly:
>         FileSystemView fsv = FileSystemView.getFileSystemView();
>         File file = "some unexisted file";
>         if (fsv.isLink(file)) {
>             if (fsv.getLinkLocation(file) == null) {
>                 throw new RuntimeException();
>             }
>         } else {
>             if (fsv.getLinkLocation(file) != null) {
>                 throw new RuntimeException();
>             }
>         }
>
The code will not compile because FileNotFoundException is not caught.

The logic of getLinkLocation() is pretty simple:
- If the file is not a link, it refers to nothing and the method returns 
nothing (null).
- If the file is a link, it refers to an another file but in case the 
another file cannot be found in the FS the FileNotFoundException is thrown.
> There are some checks in the code related to "C:\pagefile.sys" and 
> "C:\Winnt\Profiles\joe\history\History.IE5" can you double check how 
> the new methods will work with these files.
This situations are only possible for the listFiles() return. If it 
happens for a File object then it is a real error which should be reported.
>
>
>> Your point that there is inconsistency sounds a bit odd.  If this
>> reasoning we can not add a new method which throws an exception to the
>> class not having methods throwing this exception. How methods of the FSV
>> class related to different aspects of the file system can be
>> inconsistent? They are simply not related to each other.
>
>



From alexandr.scherbatiy at oracle.com  Fri Jan 22 10:59:55 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 22 Jan 2016 14:59:55 +0400
Subject: <Swing Dev> Review Request for Bug 8146320 JTextField ignores
 setPreferredSize when having columns
In-Reply-To: <CAM6ZMz8EHQ=0zJL8fCukJbmxRP3c3ACDLjp0+y6YoVw9keJWeA@mail.gmail.com>
References: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>
	<56A03394.4010405@oracle.com>
	<1797a2d0-95f7-49df-abfa-62138fcb280d@default>
	<CAM6ZMz-Q28TZ2un8NnPgOhMDc68ks2rmr5zA6kvuLjHq8AsAUA@mail.gmail.com>
	<1f46a740-13a9-434b-b221-e4bfcade730c@default>
	<CAM6ZMz8EHQ=0zJL8fCukJbmxRP3c3ACDLjp0+y6YoVw9keJWeA@mail.gmail.com>
Message-ID: <56A20BAB.8080701@oracle.com>

On 21/01/16 15:19, Andrej Golovnin wrote:
> Hi Perm,
>
> I'm sorry, my mistake. To see the difference you must run the example
> with JDK 8, e.g. without your patch. The example contains two fields
> "jdk8" and "jdk9". The "jdk9" field simulates the behaviour of
> JTextField with your patch. Both fields "jdk8" and "jdk9" should have
> the same size on the screen. But after your patch the "jdk9" field is
> only 10 pixel wide.
>
> Suppose developers had following use case in the past:
>
> We need a field which should be 10 columns wide and 20 pixels high.
> The field must be inside of a panel with BoxLayout and laid out
> horizontally from left to right.
>
> What did they done in such situations:
>
> JTextField field = new JTextField(10):
> field.setPreferredSize(new Dimension(10, 20)); // The real width will
> be calculated by JTextField using the number of columns.
>
> JPanel content = new JPanel();
> BoxLayout layout = new BoxLayout(content, BoxLayout.X_AXIS);
> content.setLayout(layout);
>
> content.add(field);
>
> This code implements the use case above (from JavaDocs of BoxLayout:
> BoxLayout attempts to arrange components at their preferred widths
> (for horizontal layout) or heights (for vertical layout).). But your
> change would break now this implementation. After your change the
> field would have only the size of 10 pixels x 20 pixels ant not the
> expected 10 columns x 20 pixels.
   Usually you are right that if there is a public javadoc and 
developers relies on it, changing the API could break their programs.

  This case looks slightly different.  The javadoc for 
JTextField.getPreferredSize() contradicts to the parent 
JComponent.getPreferredSize() documentation: If the preferredSize has 
been set to a non-null value just returns it.

  The JTextField behavior looks like a bug and misleads developers that 
rely on it as on an ordinary JComponent component and expect that a 
custom preferred size should be returned.

  However, this really looks like a corner case between a real bug and 
already used public API.
  It would be better to have more opinions about it.

  Thanks,
  Alexandr.
>
> Best regards,
> Andrej Golovnin



From andrej.golovnin at gmail.com  Fri Jan 22 13:10:22 2016
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Fri, 22 Jan 2016 14:10:22 +0100
Subject: <Swing Dev> Review Request for Bug 8146320 JTextField ignores
 setPreferredSize when having columns
In-Reply-To: <56A20BAB.8080701@oracle.com>
References: <19401ae5-85bc-4dbe-bf85-9526cd9ca405@default>
	<56A03394.4010405@oracle.com>
	<1797a2d0-95f7-49df-abfa-62138fcb280d@default>
	<CAM6ZMz-Q28TZ2un8NnPgOhMDc68ks2rmr5zA6kvuLjHq8AsAUA@mail.gmail.com>
	<1f46a740-13a9-434b-b221-e4bfcade730c@default>
	<CAM6ZMz8EHQ=0zJL8fCukJbmxRP3c3ACDLjp0+y6YoVw9keJWeA@mail.gmail.com>
	<56A20BAB.8080701@oracle.com>
Message-ID: <CAM6ZMz9GquxDAujeCOp-imw09B=MEKEXjyhqNLn4fAwNeB9bBA@mail.gmail.com>

Hi Alexandr,

>   Usually you are right that if there is a public javadoc and developers
> relies on it, changing the API could break their programs.
>
>  This case looks slightly different.  The javadoc for
> JTextField.getPreferredSize() contradicts to the parent
> JComponent.getPreferredSize() documentation: If the preferredSize has been
> set to a non-null value just returns it.

Take for example IdentityHashMap. It implements the Map interface but
it does not fulfil the Map's general contract. IdentityHashMap
documents this violation of the Map contract. And as far as I know
nobody tries now to fix IdentityHashMap. JTextField overrides
getPreferredSize() and implements it differently and documents the new
behaviour of JTextField.getPreferredSize. Therefore I personally don't
see here a problem or some contradiction.

>
>  The JTextField behavior looks like a bug and misleads developers that rely
> on it as on an ordinary JComponent component and expect that a custom
> preferred size should be returned.

And what those developers do with the following components:

JEditorPane, if it's parent is a JViewport and it's
#getScrollableTracksViewportWidth/Height()-methods return false.
JTextArea created with columns and rows.
MetalScrollButton (it is a part of the public API therefore people may use it).
BasicArrowButton (it is a part of the public API therefore people may use it).
MotifScrollBarButton (it is a part of the public API therefore people
may use it).
JToolBar.Separator.

All of them override getPreferredSize() and may return a different
value than the one set by setPreferredSize(). BasicArrowButton, for
example, always return new Dimension(16,16). The most strange
behaviour has JToolBar.Separator. If you set the preferred size on a
JToolBar.Separator by setPreferredSize(), then it returns the value
you set. But as soon as you call setSeparatorSize() on a
JToolBar.Separator, it starts to return the value you set by
setSeparatorSize() and ignores whatever you set by setPreferredSize()
before.

The fact is: Swing is very old. And the fact is that the code you try
to change is also very old and people relied in the past on the
current behaviour of JTextField.getPreferredSize(). Not-one of
Oracle/Sun developers cared about it for years. And now you are going
to change it? OK, but then be prepared to see bug reports as soon as
JDK 9 is released.

Best regards,
Andrej Golovnin

>
>  However, this really looks like a corner case between a real bug and
> already used public API.
>  It would be better to have more opinions about it.
>
>  Thanks,
>  Alexandr.
>>
>>
>> Best regards,
>> Andrej Golovnin
>
>


From alexandr.scherbatiy at oracle.com  Mon Jan 25 06:43:23 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Mon, 25 Jan 2016 09:43:23 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <569963B6.2050604@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>
Message-ID: <56A5C40B.7010107@oracle.com>


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


Thanks,
Alexandr.


On 16/01/16 01:25, Sergey Bylokhov wrote:
> On 15/01/16 19:31, Alexander Scherbatiy wrote:
>>    - the description of the getClippedString method is updated to
>> mention that ellipsis is added at the end of the clipped string
>
> It seems that we go far far away from the description of mission of 
> this method to the description of its implementation. The goal of the 
> method is possibility for clients to use the same draw functions which 
> are used by our L&F so the custom components will look the same as 
> standard components. Description that something is added to the end of 
> the clipped string, the exact list of client properties seems 
> unnecessary?
> Moreover it seems that if the requested space is really small we can 
> return ellipses which will occupy more space than requested.(i guess 
> this is a separate bug)
>
>>
>> On 1/15/2016 1:16 PM, Semyon Sadetsky wrote:
>>> Hi,
>>>
>>> getClippedString() : It is worth to explain that 3dots are added at
>>> end or returned.
>>>
>>> getStringWidth(): It is worth to add a note that the returning value
>>> is not the exact visual string width because rendering hints are not
>>> taken into account.
>>      I thought that rendering hints can affect a string quaility and
>> drawing performance. Do they really change the visual string width?
>>>
>>> What was the reason for renaming clipStringIfNecessary() and
>>> stringWidth()?
>>>
>>> stringWidth() is a standard method name to get the advance in all
>>> other JDK interfaces.
>>      The 'get' prefix is used here not because it is JavaBeans
>> requirements but because of the method name conventions.
>>      For example, the same Utilities class contains getTabbedTextWidth()
>> method which also has the 'get' prefix.
>>
>>> clipStringIfNecessary method name better reflects the method operation
>>> than the proposed one.
>>      The 'necessary' word is vague in this case. Is there any need to
>> clip a string if it is not necessary?
>>      The method description gives the explanation in which case the
>> string will be clipped.
>>
>>   Thanks,
>>   Alexandr.
>>
>>> This is an utility static API and we don't need to follow JavaBeans
>>> naming conventions here.
>>>
>>> --Semyon
>>>
>>>
>>> On 1/13/2016 6:03 PM, Alexander Scherbatiy wrote:
>>>>
>>>>   Hello,
>>>>
>>>>   Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.05/
>>>>
>>>>   - the methods description are updated to mention a component
>>>> numeric shaper and non-print graphics context
>>>>   - @since tag value is updated to 9
>>>>
>>>>  Thanks,
>>>>  Alexandr.
>>>>
>>>> On 1/12/2016 10:42 PM, Philip Race wrote:
>>>>> @since needs to be just "9" as of the updated verona versioning 
>>>>> scheme.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 1/12/16, 4:25 AM, Semyon Sadetsky wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> I see that you've added the next clarifications to the methods 
>>>>>> specs:
>>>>>>
>>>>>> > draws string/returns width ... using text properties and
>>>>>> anti-aliasing hints from the provided component
>>>>>>
>>>>>> It still seems too brief and even incorrect for getStringWidth().
>>>>>>
>>>>>> For drawString():
>>>>>>
>>>>>> For non-printing case I would write:
>>>>>>
>>>>>> Sets the anti-aliasing rendering hints to the Graphics object if
>>>>>> those are specified in the component properties. Then the string is
>>>>>> drawn using the provided Graphics object with the numeric shaper
>>>>>> taken into account if it is defined for the component.
>>>>>>
>>>>>> Please consider the printing case...
>>>>>>
>>>>>> For getStringWidth():
>>>>>>
>>>>>> Did not get which anti-aliasing hints it takes into account while
>>>>>> there is no Graphics in the params list...
>>>>>> On the contrary, it does not take into account the rendering 
>>>>>> context.
>>>>>> My suggestion:
>>>>>>
>>>>>> Returns string pixel width by the provided font metrics and
>>>>>> according to the numeric shaper if it is defined for the component.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> For
>>>>>> On 12/10/2015 5:06 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>  Hello,
>>>>>>>
>>>>>>>  Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>>>>>>
>>>>>>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>
>>>>>>>> I suggest using {@code underlinedIndex} in this sentence:
>>>>>>>>
>>>>>>>> * The {@code underlinedIndex} parameter points to a char value
>>>>>>>> (Unicode code unit) in the
>>>>>>>> * given string.
>>>>>>>>
>>>>>>>> in the Javadoc for drawStringUnderlineCharAt().
>>>>>>>>
>>>>>>>>
>>>>>>>> And I suggest using "fits" instead of "can fit" in @return for
>>>>>>>> getClippedString() and rephrasing the conditions where empty
>>>>>>>> string is returned:
>>>>>>>>
>>>>>>>> * @return the clipped string that fits in the provided space, an
>>>>>>>> empty
>>>>>>>> *         string if the given string argument is {@code null} or
>>>>>>>> empty.
>>>>>>>
>>>>>>>    The fix is updated according to the provided comments.
>>>>>>>
>>>>>>>    Thanks,
>>>>>>>    Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey
>>>>>>>>
>>>>>>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>>>>>>
>>>>>>>>> - methods description is updated to mention used text properties
>>>>>>>>> and anti-aliasing hints from the provided component
>>>>>>>>> - the drawStringUnderlineCharAt method description is updated
>>>>>>>>> - @since tag is added for the drawString() method
>>>>>>>>> - the description that some parameters may/must not be null is
>>>>>>>>> added
>>>>>>>>> - the test is updated to call the methods on EDT
>>>>>>>>> - the test is updated to check passed null arguments
>>>>>>>>>
>>>>>>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>
>>>>>>>>>> Shouldn't drawString() also have @since tag?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Could you please also clarify whether underlinedIndex in
>>>>>>>>>> drawStringUnderlineCharAt refers to the char index in the 
>>>>>>>>>> string?
>>>>>>>>>>
>>>>>>>>>> The statement
>>>>>>>>>> * The underlined index refers to char values (Unicode code 
>>>>>>>>>> units).
>>>>>>>>>> makes it unclear: underlinedIndex is an *index* or a *char*
>>>>>>>>>> (Unicode code point).
>>>>>>>>>
>>>>>>>>>  I updated it to "The underlined index points to a char value
>>>>>>>>> (Unicode code unit) in the given string."
>>>>>>>>>  The 'refers' word was used for a value at the given index.
>>>>>>>>>  However, I am not sure that the new variant is better.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> * Nothing is drawn for null string. No character is underlined
>>>>>>>>>> for the
>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if the
>>>>>>>>>> char value
>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>
>>>>>>>>>> I think it will be better to spell comparison operators, I mean
>>>>>>>>>> to use  "greater than" rather than ">=". And "length" must be
>>>>>>>>>> used instead of "width".
>>>>>>>>>>
>>>>>>>>>> I propose the following text:
>>>>>>>>>>
>>>>>>>>>> No character is underlined if the index is negative or greater
>>>>>>>>>> than the string length or if the char value specified at the
>>>>>>>>>> given index is in the low-surrogate range.
>>>>>>>>>>
>>>>>>>>>> For the first part of condition, you can add clarification in
>>>>>>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>>>>>>  Updated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> For consistency, please remove the full stop in @return tag in
>>>>>>>>>> description of getClippedString.
>>>>>>>>>
>>>>>>>>> Updated.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alexey
>>>>>>>>>>
>>>>>>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>>>>>>
>>>>>>>>>>> The javadoc references for the #drawStringUnderlineCharAt and
>>>>>>>>>>> #getClippedString methods are moved after parameters 
>>>>>>>>>>> description.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with
>>>>>>>>>>>> chars that have
>>>>>>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>>>>>>> The whole glyph is underlined.
>>>>>>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>>>>>>
>>>>>>>>>>>> The char value specified the the underlined index should
>>>>>>>>>>>> point to the high-surrogate range of a supplementary 
>>>>>>>>>>>> character.
>>>>>>>>>>>> I updated the javadoc for the
>>>>>>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>> /**
>>>>>>>>>>>> * Draws the given string at the specified location underlining
>>>>>>>>>>>> * the specified character.
>>>>>>>>>>>> * <p>
>>>>>>>>>>>> * The underlined index refers to char values (Unicode code
>>>>>>>>>>>> units).
>>>>>>>>>>>> * If the char value specified at the given underlined index
>>>>>>>>>>>> is in
>>>>>>>>>>>> * the high-surrogate range and the char value at the
>>>>>>>>>>>> following index is in
>>>>>>>>>>>> * the low-surrogate range then the supplementary character
>>>>>>>>>>>> corresponding
>>>>>>>>>>>> * to this surrogate pair is underlined.
>>>>>>>>>>>> * <p>
>>>>>>>>>>>> * Nothing is drawn for null string. No character is
>>>>>>>>>>>> underlined for the
>>>>>>>>>>>> * index {@code < 0}, {@code >=} than the string width or if
>>>>>>>>>>>> the char value
>>>>>>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>>>>>>> -----------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>>>>>>> I don't remember or know how Swing resolves this but the
>>>>>>>>>>>>>> measurement ones
>>>>>>>>>>>>>> are not reliable since they do not take a Graphics context,
>>>>>>>>>>>>>> so you cannot
>>>>>>>>>>>>>> measure the string properly. You need a FontRenderContext
>>>>>>>>>>>>>> to measure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The provided methods use
>>>>>>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method
>>>>>>>>>>>>> which returns the FontRenderContext associated with the
>>>>>>>>>>>>> component.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So as it stands these APIs do not appear suitable to be
>>>>>>>>>>>>>> made public as they
>>>>>>>>>>>>>> are not reliable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Whilst I could look at the code, if I instead just look at
>>>>>>>>>>>>>> the API, I am scratching my
>>>>>>>>>>>>>> head over :-
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> public static void drawString(JComponent c, Graphics g,
>>>>>>>>>>>>>> String text, int x, int y)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>>>>>>> So I am supposing that there is optional information that
>>>>>>>>>>>>>> may be pulled from the
>>>>>>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The optional information provided by the component is:
>>>>>>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>>>>>>> - antialiasing hints
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if
>>>>>>>>>>>>>> the index is code point
>>>>>>>>>>>>>> or UTF16 char index and what happens if there is not 1:1
>>>>>>>>>>>>>> code point:glyph mapping.
>>>>>>>>>>>>> I will update this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are we sure that (any of) these really ought/need to be
>>>>>>>>>>>>>> public - particularly given the
>>>>>>>>>>>>>> resolution of 
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>>>>>>
>>>>>>>>>>>>> These methods are used by JDK L&Fs to draw text. The initial
>>>>>>>>>>>>> request was to provide public methods that can be used by a
>>>>>>>>>>>>> custom L&F to draw strings consistently with other L&Fs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> They are also designed to properly render text for printing.
>>>>>>>>>>>>> To do that they use call to internal ProxyPrintGraphics
>>>>>>>>>>>>> class to obtain the print graphics context.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Even if printing staff will be public, these methods are
>>>>>>>>>>>>> just utility methods (in the same way as other text methods
>>>>>>>>>>>>> in the javax.swing.text.Utilities class) that help easily to
>>>>>>>>>>>>> draw and print text in the same way as JDK L&Fs do that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt,
>>>>>>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>
>




From andrej.golovnin at gmail.com  Mon Jan 25 09:44:39 2016
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Mon, 25 Jan 2016 10:44:39 +0100
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56A5C40B.7010107@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>
Message-ID: <CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>

Hi Alexandr,

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

src/java.desktop/share/classes/javax/swing/plaf/ComponentUI.java:

- in the line 56 there is one space too much before the "private" keyword.
- the empty line 91 is not needed.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java:

- the line 74 can be removed.

src/java.desktop/share/classes/sun/swing/SwingUtilities2.java:

- in the line 2101 javadocs should mention that the component may be null.
  At least SwingUtilities2.clipStringIfNecessary allows it.

src/java.desktop/share/classes/javax/swing/plaf/TextUIDrawing.java:

- in the line 103 javadocs should mention that the component may be null.

>
> - 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.

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.

Best regards,
Andrej Golovnin


From vikrant.v.agarwal at oracle.com  Thu Jan 28 10:32:17 2016
From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal)
Date: Thu, 28 Jan 2016 02:32:17 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8131751: Test
 javax/swing/plaf/gtk/crash/RenderBadPictureCrash.java fails
 UnsupportedOperationException
Message-ID: <2998194d-ebf9-4123-880f-071432ca8482@default>

Hi All,

Kindly review the fix for JDK9.

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

Webrev: http://cr.openjdk.java.net/~srastogi/8131751/webrev.00/

Issue: [TEST_BUG] Test javax/swing/plaf/gtk/crash/RenderBadPictureCrash.java fails UnsupportedOperationException

Cause: test failed on those systems where PERPIXEL_TRANSLUCENT translucency is not supported as it is doing  f.setBackground(new Color(0, 0, 0, 0)); (making alpha value 0)

Fix: Added a check for checking support for PERPIXEL_TRANSLUCENT translucency before f.setBackground(new Color(0, 0, 0, 0));

Best Regards,

Vikrant Agarwal

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

From alexandr.scherbatiy at oracle.com  Thu Jan 28 17:43:26 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Thu, 28 Jan 2016 09:43:26 -0800
Subject: <Swing Dev> Review request for JDK-8131751: Test
 javax/swing/plaf/gtk/crash/RenderBadPictureCrash.java fails
 UnsupportedOperationException
In-Reply-To: <2998194d-ebf9-4123-880f-071432ca8482@default>
References: <2998194d-ebf9-4123-880f-071432ca8482@default>
Message-ID: <56AA533E.6010203@oracle.com>


The fix looks good to me.

Just a small note: it could be better to get the graphics device from 
the frame itself (f.getGraphicsConfiguration().getDevice()).

Thanks,
Alexandr.

On 1/28/2016 2:32 AM, Vikrant Agarwal wrote:
>
> Hi All,
>
> Kindly review the fix for JDK9.
>
> *Bug:* https://bugs.openjdk.java.net/browse/JDK-8131751
>
> *Webrev:* http://cr.openjdk.java.net/~srastogi/8131751/webrev.00/
>
> *Issue:* [TEST_BUG] Test 
> javax/swing/plaf/gtk/crash/RenderBadPictureCrash.java fails 
> UnsupportedOperationException
>
> *Cause:* test failed on those systems where PERPIXEL_TRANSLUCENT 
> translucency is not supported as it is doing  f.setBackground(new 
> Color(0, 0, 0, 0)); (making alpha value 0)
>
> *Fix:* Added a check for checking support for PERPIXEL_TRANSLUCENT 
> translucency before f.setBackground(new Color(0, 0, 0, 0));
>
> Best Regards,
>
> Vikrant Agarwal
>

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

From prem.balakrishnan at oracle.com  Fri Jan 29 05:45:25 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 28 Jan 2016 21:45:25 -0800 (PST)
Subject: <Swing Dev> Review Request for 8062846 : Transparent JDialog will
 lose transparency upon iconify/deiconify sequence.
Message-ID: <521f1ec3-9046-43a4-b008-677a4f14f6c8@default>

Hi,

Please review fix for JDK9,

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

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

 

Issue:

Transparent JDialog will lose transparency upon iconify/deiconify sequence.

 

Cause:

Regression: due to 6780496: Javaw process taking up 80-90 percent of CPU time!

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

Intentionally when JDialog is iconified transparency is disabled, 

And transparency is not enabled when JDialog is deiconified.

 

Fix:

Transparency is enabled when JDialog is deiconified.

 

Regards,
Prem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160128/ea675bb3/attachment.html>

From alexandr.scherbatiy at oracle.com  Fri Jan 29 15:51:48 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 29 Jan 2016 19:51:48 +0400
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.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>
Message-ID: <56AB8A94.2070404@oracle.com>

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  Wed Jan 20 15:43:58 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 20 Jan 2016 15:43:58 -0000
Subject: <Swing Dev> Review Request of 8146321: [macosx] JInternalFrame
	frame icon in wrong position on Mac L&F if icon is not ImageIcon
In-Reply-To: <569F6B96.8070309@oracle.com>
References: <431B2640-2D19-4EFC-824E-52AE3D25D2D8@oracle.com>
	<56973AEA.1040308@oracle.com>
	<BEB3BF05-B31A-4595-BCBB-E9DC915AED19@oracle.com>
	<13420C14-4119-4EF4-A037-1F4C2BF87E3C@oracle.com>
	<328DE551-87E2-4D51-89DC-AA7BAE40B610@oracle.com>
	<569F6B96.8070309@oracle.com>
Message-ID: <7DC88C61-FFB3-494A-A94C-9728DD29121F@oracle.com>

Hi Alexander,

If we use a code like this:

if ((icon.getIconWidth() > sMaxIconWidth
                || icon.getIconHeight() > sMaxIconHeight)) {
            final Graphics2D g2 = (Graphics2D) g;
            final AffineTransform savedAT = g2.getTransform();
            g2.scale((float)sMaxIconWidth/icon.getIconWidth(),
                    (float)sMaxIconWidth/icon.getIconHeight());
            icon.paintIcon(frame, g2, x, y);
            g2.setTransform(savedAT);
        }

then for a test code with the following:

import java.awt.*;
import javax.swing.*;

public class JInternalFrameBug {

   public static void main(String[] args) {
      SwingUtilities.invokeLater(
            new Runnable() {
               public void run() {
                  try {
                     UIManager.setLookAndFeel("com.apple.laf.AquaLookAndFeel"); }
                  catch(Exception e) {
                     System.out.println("This is not a Mac.");
                     return;
                  }
                  JFrame f = new JFrame();
                  f.setSize(400, 400);
                  JDesktopPane dtp = new JDesktopPane();
                  JInternalFrame jif = new JInternalFrame();
                  jif.setTitle("Test");
                  jif.setFrameIcon(new ImageIcon("/Users/avniyogi/Downloads/FeedbinNotifier-master/FeedbinNotifier/Images.xcassets/AppIcon.appiconset/icon_128x128 at 2x.png"));
                  jif.setSize(200, 200);
                  jif.setVisible(true);
                  dtp.add(jif);

                  f.getContentPane().setLayout(new BorderLayout());
                  f.getContentPane().add(dtp, "Center");
                  f.setVisible(true);
               }
            });
   }
}

results in this:




> On 20-Jan-2016, at 4:42 pm, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> On 1/20/2016 7:59 AM, Avik Niyogi wrote:
>> Hi All,
>> A gentle reminder, please review my code changes as in the webrev below in the mail trail.
>> With Regards,
>> Avik Niyogi
>>> On 18-Jan-2016, at 3:01 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>> 
>>> Hi Sergey,
>>> 
>>> Please review the webrev taking inputs as per the discussion before:
>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/ <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.01/>
> 
>    The idea was to scale the graphics that the drawn icon fits to the target sizes.
>    Something like:
>       --------
>       g2d.scale(targetIconWidth/icon.getWidth(), targetIconHeight/icon.getHeight());
>       icon.paintIcon(frame, g2d, x, y);
>      ---------
> 
>   This should work not only for ImageIcon but for any type of icons.
> 
>   Thanks,
>   Alexandr.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 14-Jan-2016, at 12:55 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>>>> 
>>>> Hi Sergey,
>>>> I have verified it with the test case as well. If a test case overrides these methods to imply a change with icons larger than 16x16 it will show that for ImageIcon and Icon as before. The resize of ImageIcon is only in case it has an image file that it will try to fit. I had a similar query myself and have found out that *getImage()* exists for ImageIcon class only and not Icon class.
>>>> Example:
>>>> private static void createImageIconUI(final String lookAndFeelString)
>>>>            throws Exception {
>>>> SwingUtilities.invokeAndWait(new Runnable() {
>>>>            @Override
>>>>            public void run() {
>>>>                desktopPane = new JDesktopPane();
>>>>                internalFrame = new JInternalFrame();
>>>>                frame = new JFrame();
>>>> internalFrame.setTitle(lookAndFeelString);
>>>>                titleImageIcon = new ImageIcon() {
>>>>                    @Override
>>>>                    public int getIconWidth() {
>>>>                        return 16;
>>>>                    }
>>>> 
>>>>                    @Override
>>>>                    public int getIconHeight() {
>>>>                        return 16;
>>>>                    }
>>>> 
>>>>                    @Override
>>>>                    public void paintIcon(
>>>> Component c, Graphics g, int x, int y) {
>>>> g.setColor(java.awt.Color.black);
>>>> *g.fillRect(x, y, 50, 50);*
>>>>                    }
>>>>                };
>>>> internalFrame.setFrameIcon(titleImageIcon);
>>>> internalFrame.setSize(500, 200);
>>>> internalFrame.setVisible(true);
>>>> desktopPane.add(internalFrame);
>>>> 
>>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>> frame.getContentPane().setLayout(new BorderLayout());
>>>> frame.getContentPane().add(desktopPane, "Center");
>>>> frame.setSize(500, 500);
>>>> frame.setLocationRelativeTo(null);
>>>> frame.setVisible(true);
>>>> frame.toFront();
>>>>            }
>>>>        });
>>>>    }
>>>> In this case the ImageIcon will NOT be resized to 16 x 16 even before my fix was implemented. That resize as shown in code is *only for Image files to fit in default ImageIcon* size as returned from the getIconHeight() and getIconWidth() methods. If user changes the ImageIcon size as in the example, that is upto to user to choose to do so and no control exists to prevent that. *So, with or without my fix, this behaviour will be same for ImageIcon and Icon custom instances.*
>>>> Hope this clarifies the query.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 14-Jan-2016, at 11:36 am, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>> 
>>>>> Hi, Avik.
>>>>> In the fix you update getIconWidth() and getIconHeight, so now we take the Icon into account. but it seems if the Icon is bigger that the maximum size it will not be resided to 16x16, right?
>>>>> 
>>>>> On 14/01/16 07:49, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> Kindly review the bug fix for JDK 9.
>>>>>> 
>>>>>> *Bug:*
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146321
>>>>>> 
>>>>>> *Webrev:*
>>>>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.00/>
>>>>>> 
>>>>>> *Issue:*
>>>>>> Under the Mac Look&Feel, if an icon type other than an ImageIcon is used
>>>>>> in JInternalFrame.setFrameIcon(),
>>>>>> the icon will show up in the wrong position.
>>>>>> 
>>>>>> *Cause:*
>>>>>> the "instanceof Icon" was not checked for. Also, customs ImageIcon with
>>>>>> color fill (and no image URL) which would
>>>>>> have resulted in null value for resized ImageIcon image was not well
>>>>>> handled.
>>>>>> 
>>>>>> *Fix:*
>>>>>> All places in Aqua LAF where "instanceof Icon? (and not just ImageIcon
>>>>>> class) is required,
>>>>>> inputs were added after significant analyses.
>>>>>> Check for null for getImage was done to remove a Null Pointer Exception.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Best regards, Sergey.
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160120/e3c20f26/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 925006 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160120/e3c20f26/PastedGraphic-1.tiff>