From prasanta.sadhukhan at oracle.com  Fri Jun  1 06:07:44 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 1 Jun 2018 11:37:44 +0530
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
Message-ID: <5964a636-2753-3206-2a52-080daf7026b3@oracle.com>

Hi Phil,

Any feedback as to why you find this is not the right fix? I could not 
find anything in JDK-8168992 to guess it is not.
As told, there was no regression with jck and jtreg tests with the fix.

Regards
Prasanta
On 5/9/2018 12:41 AM, Phil Race wrote:
> I am not sure this is the right fix.
> If the intention had been to change all calls to getTabbedTextOffset() 
> to use the FP
> API it would have just been changed .. rather than adding a new API 
> that provides
> the option to specify whether to use FP.
>
> So perhaps the problem is that internal code needs to be updated to 
> call the FP
> version directly ..
> I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992 to see
> what was said there but JBS just went down for 5 hours maintenance ..
>
> -phil.
>
> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> I have run javax/swing/text jtreg and jck tests and did not observe 
>> any regressions.
>>
>> Regards
>> Prasanta
>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Please confirm that you run related jck/reg tests.
>>>
>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for an issue where it is seen that,
>>>> ? with a screen resolution higher than 100% and then clicking in a 
>>>> JTextArea having setLineWrap(true) set, the caret (insertion point) 
>>>> is not aligned with the cursor.
>>>>
>>>> The issue seems to stem from the fact that caret position 
>>>> calculation in DefaultCaret class utilises API that uses integer 
>>>> calculation than floating point calculations.
>>>> The code flow as seen is
>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset 
>>>>
>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses 
>>>> integer arithmetic to get the caret position.
>>>> The same getTabbedOffset uses Font.getStringBounds() which uses 
>>>> floating point arithmetic via Rectangle2D.Float.
>>>>
>>>> Proposed fix is to make sure getTabbedOffset uses floating point 
>>>> calculations by using getStringBounds() instead of charsWidth() so 
>>>> that it calculates
>>>> the character width(s) of text present in JTextArea in floating 
>>>> point to align the caret.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Mon Jun  4 20:57:33 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 4 Jun 2018 13:57:33 -0700
Subject: <Swing Dev> [11] Review Request: 8202768 [macos] Appkit thread
 slows when any Window Manager active
Message-ID: <5a63d492-0e06-0cd4-6251-6ed006da9580@oracle.com>

Hello.
Please review the fix for jdk11.

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

Short description:
The root cause of the bug is tremendous complexity of code which iterate 
over hierarchy of accessibility components, it was added unintentionally 
in JDK-8145207:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/233b59b7ea2f#l8.97

Description:
Our NSView component implements a accessibilityHitTest() method which is 
part of accessibility api. When this method is called we need to return 
the first meaningful  accessibility component: "For example, when you 
place a button in a window, the system typically creates a button cell 
inside a button control inside a container view inside a window. Users, 
however, don?t care about the view hierarchy details. They should only 
be told that there?s a button in a window. "

To iterate the accessibility components we use 
NSAccessibilityUnignoredAncestor() method
https://developer.apple.com/documentation/appkit/1531456-nsaccessibilityunignoredancestor?language=objc

which usually should work in this way:
   1 Check is the component is ignored, if not then return it.
   2 If the component is ignored, then request a 
NSAccessibilityParentAttribute.
   3 If NSAccessibilityParentAttribute is supported then repeat the 
step1 for the parent. etc.

But our implementation works in this way:
   1 Check is the component is ignored, if not then return it.
   2 If the component is ignored, then request a 
NSAccessibilityParentAttribute.
   3 Check that NSAccessibilityParentAttribute is supported. We create a 
list of all supported attributes in accessibilityAttributeNames() - 
method which was updated in the fix.
   4 in the accessibilityAttributeNames() we need to access the parent 
so we repeat the step 1 for the parent and its parent, and its parent, etc.
   5 We return back to the first iteration in accessibilityAttributeNames()
   6 We report that NSAccessibilityParentAttribute is supported(it was 
requested at step3).
   7 We return the NSAccessibilityParentAttribute requested at step2.
   8 Repeat the step 1 until we will found unignored parent.
(...) some intermediate steps were skipped.


As you see at step4 we iterate hierarchy of accessibility components, we 
do this for each component. So it is quite slow when we have big 
hierarchy of ignored components.

To block such iteration at step4 I have added a check that it is not 
necessary to access the parent when we build the list of supported 
attributes if the current component is "ignored".

Note: The bug can be reproduced on macOS by the testcase when the iSnap 
is active.


-- 
Best regards, Sergey.


From philip.race at oracle.com  Tue Jun  5 18:17:47 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 5 Jun 2018 11:17:47 -0700
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <5964a636-2753-3206-2a52-080daf7026b3@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
 <5964a636-2753-3206-2a52-080daf7026b3@oracle.com>
Message-ID: <0e86dfb5-73f7-9f95-c281-648f81a5dc2c@oracle.com>

My explanation for my thinking is already written in the email you are 
replying to ..

-phil.

On 05/31/2018 11:07 PM, Prasanta Sadhukhan wrote:
> Hi Phil,
>
> Any feedback as to why you find this is not the right fix? I could not 
> find anything in JDK-8168992 to guess it is not.
> As told, there was no regression with jck and jtreg tests with the fix.
>
> Regards
> Prasanta
> On 5/9/2018 12:41 AM, Phil Race wrote:
>> I am not sure this is the right fix.
>> If the intention had been to change all calls to 
>> getTabbedTextOffset() to use the FP
>> API it would have just been changed .. rather than adding a new API 
>> that provides
>> the option to specify whether to use FP.
>>
>> So perhaps the problem is that internal code needs to be updated to 
>> call the FP
>> version directly ..
>> I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992 to see
>> what was said there but JBS just went down for 5 hours maintenance ..
>>
>> -phil.
>>
>> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>>> Hi Sergey,
>>>
>>> I have run javax/swing/text jtreg and jck tests and did not observe 
>>> any regressions.
>>>
>>> Regards
>>> Prasanta
>>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>> Please confirm that you run related jck/reg tests.
>>>>
>>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for an issue where it is seen that,
>>>>>   with a screen resolution higher than 100% and then clicking in a 
>>>>> JTextArea having setLineWrap(true) set, the caret (insertion 
>>>>> point) is not aligned with the cursor.
>>>>>
>>>>> The issue seems to stem from the fact that caret position 
>>>>> calculation in DefaultCaret class utilises API that uses integer 
>>>>> calculation than floating point calculations.
>>>>> The code flow as seen is
>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset 
>>>>>
>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses 
>>>>> integer arithmetic to get the caret position.
>>>>> The same getTabbedOffset uses Font.getStringBounds() which uses 
>>>>> floating point arithmetic via Rectangle2D.Float.
>>>>>
>>>>> Proposed fix is to make sure getTabbedOffset uses floating point 
>>>>> calculations by using getStringBounds() instead of charsWidth() so 
>>>>> that it calculates
>>>>> the character width(s) of text present in JTextArea in floating 
>>>>> point to align the caret.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>
>>>>
>>>
>>
>



From philip.race at oracle.com  Tue Jun  5 20:24:48 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 5 Jun 2018 13:24:48 -0700
Subject: <Swing Dev> RFR: 8203499 Uninitialised memory in WinAccessBridge.cpp
Message-ID: <6ca51aed-f6e5-70ed-624b-79b6d3430d64@oracle.com>

Bug: Uninitialised memory in WinAccessBridge.cpp:485
webrev: http://cr.openjdk.java.net/~prr/8203499/

element is not initialised on declaration.

It should be initialised when its address is passed here
messageQueue->remove(&element);

but it is too hard to prove, so just initialise it to NULL .. and remove 
DEBUG code which will SEGV if it is NULL.

-phil.


From Sergey.Bylokhov at oracle.com  Tue Jun  5 20:57:57 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Jun 2018 13:57:57 -0700
Subject: <Swing Dev> RFR: 8203499 Uninitialised memory in
 WinAccessBridge.cpp
In-Reply-To: <6ca51aed-f6e5-70ed-624b-79b6d3430d64@oracle.com>
References: <6ca51aed-f6e5-70ed-624b-79b6d3430d64@oracle.com>
Message-ID: <9c1c10f4-4ee6-d017-b2a4-1f0f12c9561c@oracle.com>

Looks fine.

On 05/06/2018 13:24, Phil Race wrote:
> Bug: Uninitialised memory in WinAccessBridge.cpp:485
> webrev: http://cr.openjdk.java.net/~prr/8203499/
> 
> element is not initialised on declaration.
> 
> It should be initialised when its address is passed here
> messageQueue->remove(&element);
> 
> but it is too hard to prove, so just initialise it to NULL .. and remove 
> DEBUG code which will SEGV if it is NULL.
> 
> -phil.


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Wed Jun  6 07:04:20 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 6 Jun 2018 12:34:20 +0530
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
Message-ID: <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>



On 5/9/2018 12:41 AM, Phil Race wrote:
> I am not sure this is the right fix.
> If the intention had been to change all calls to getTabbedTextOffset() 
> to use the FP
> API it would have just been changed .. rather than adding a new API 
> that provides
> the option to specify whether to use FP.
>
> So perhaps the problem is that internal code needs to be updated to 
> call the FP
> version directly ..
I have updated the internal code to use the FP version directly
http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.01/
There are no new regressions in jtreg and jck tests.

Regards
Prasanta
> I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992 to see
> what was said there but JBS just went down for 5 hours maintenance ..
>
> -phil.
>
> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> I have run javax/swing/text jtreg and jck tests and did not observe 
>> any regressions.
>>
>> Regards
>> Prasanta
>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Please confirm that you run related jck/reg tests.
>>>
>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for an issue where it is seen that,
>>>> ? with a screen resolution higher than 100% and then clicking in a 
>>>> JTextArea having setLineWrap(true) set, the caret (insertion point) 
>>>> is not aligned with the cursor.
>>>>
>>>> The issue seems to stem from the fact that caret position 
>>>> calculation in DefaultCaret class utilises API that uses integer 
>>>> calculation than floating point calculations.
>>>> The code flow as seen is
>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset 
>>>>
>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses 
>>>> integer arithmetic to get the caret position.
>>>> The same getTabbedOffset uses Font.getStringBounds() which uses 
>>>> floating point arithmetic via Rectangle2D.Float.
>>>>
>>>> Proposed fix is to make sure getTabbedOffset uses floating point 
>>>> calculations by using getStringBounds() instead of charsWidth() so 
>>>> that it calculates
>>>> the character width(s) of text present in JTextArea in floating 
>>>> point to align the caret.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>>
>>
>



From philip.race at oracle.com  Wed Jun  6 22:03:32 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 6 Jun 2018 15:03:32 -0700
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
 <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>
Message-ID: <1cdaa1da-9954-f15d-c68a-2d07913c9f87@oracle.com>

This is changing the internals of getTabbedTextOffset and using FP 
regardless
of whether useFPAPI is true. This is not what I said.

I wrote that you should call the FP version directly.

Look at this
---
      * @deprecated replaced by
      *     {@link #getTabbedTextOffset(Segment, FontMetrics, float, float,
      *                                 TabExpander, int, boolean)}
      */
     @Deprecated(since = "9")
     public static final int getTabbedTextOffset(Segment s, FontMetrics 
metrics,
                                              int x0, int x, TabExpander e,
                                              int startOffset) {
         return getTabbedTextOffset(s, metrics, x0, x, e, startOffset, 
true);
----
If we had wanted what you proposed in the first webrev and I think
this one is effectively same, we'd have altered the behaviour to and not
deprecated and added new API

So whatever code in our L&F is currently calling

getTabbedTextOffset(Segment s,
                     FontMetrics metrics,
                     int x0, int x, TabExpander e,
                     int startOffset)

should instead call

getTabbedTextOffset(Segment s,
                     FontMetrics metrics,
                     float x0, float x, TabExpander e,
                     int startOffset,
                     boolean round)

I am not sure if round should be true or false but calling the float version is the key.

This (and no other change needed) does the trick for me :

--- a/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java
+++ b/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java
@@ -360,11 +360,11 @@
          int currentWidth = getWidth();
          if (wordWrap) {
              p = p0 + Utilities.getBreakLocation(segment, metrics,
-                                                tabBase, tabBase + currentWidth,
+                                                (float)tabBase, (float)(tabBase + currentWidth),
                                                  this, p0);
          } else {
              p = p0 + Utilities.getTabbedTextOffset(segment, metrics,
-                                                   tabBase, tabBase + currentWidth,
+                                                   (float)tabBase, (float)(tabBase + currentWidth),
                                                     this, p0, false);
          }
          SegmentCache.releaseSharedSegment(segment);
@@ -847,8 +847,8 @@
                          Segment segment = SegmentCache.getSharedSegment();
                          loadText(segment, p0, p1);
                          int n = Utilities.getTabbedTextOffset(segment, metrics,
-                                                   alloc.x, x,
-                                                   WrappedPlainView.this, p0);
+                                                   (float)(alloc.x), (float)x,
+                                                   WrappedPlainView.this, p0, false);
                          SegmentCache.releaseSharedSegment(segment);
                          return Math.min(p0 + n, p1 - 1);
                      }

I may have missed something else but to verify I downloaded and used your test, which BTW has DOS line-endings !

-phil.

On 06/06/2018 12:04 AM, Prasanta Sadhukhan wrote:
>
>
> On 5/9/2018 12:41 AM, Phil Race wrote:
>> I am not sure this is the right fix.
>> If the intention had been to change all calls to 
>> getTabbedTextOffset() to use the FP
>> API it would have just been changed .. rather than adding a new API 
>> that provides
>> the option to specify whether to use FP.
>>
>> So perhaps the problem is that internal code needs to be updated to 
>> call the FP
>> version directly ..
> I have updated the internal code to use the FP version directly
> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.01/
> There are no new regressions in jtreg and jck tests.
>
> Regards
> Prasanta
>> I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992 to see
>> what was said there but JBS just went down for 5 hours maintenance ..
>>
>> -phil.
>>
>> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>>> Hi Sergey,
>>>
>>> I have run javax/swing/text jtreg and jck tests and did not observe 
>>> any regressions.
>>>
>>> Regards
>>> Prasanta
>>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>> Please confirm that you run related jck/reg tests.
>>>>
>>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for an issue where it is seen that,
>>>>>   with a screen resolution higher than 100% and then clicking in a 
>>>>> JTextArea having setLineWrap(true) set, the caret (insertion 
>>>>> point) is not aligned with the cursor.
>>>>>
>>>>> The issue seems to stem from the fact that caret position 
>>>>> calculation in DefaultCaret class utilises API that uses integer 
>>>>> calculation than floating point calculations.
>>>>> The code flow as seen is
>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset 
>>>>>
>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses 
>>>>> integer arithmetic to get the caret position.
>>>>> The same getTabbedOffset uses Font.getStringBounds() which uses 
>>>>> floating point arithmetic via Rectangle2D.Float.
>>>>>
>>>>> Proposed fix is to make sure getTabbedOffset uses floating point 
>>>>> calculations by using getStringBounds() instead of charsWidth() so 
>>>>> that it calculates
>>>>> the character width(s) of text present in JTextArea in floating 
>>>>> point to align the caret.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>
>>>>
>>>
>>
>



From prasanta.sadhukhan at oracle.com  Thu Jun  7 11:12:55 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 7 Jun 2018 16:42:55 +0530
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <1cdaa1da-9954-f15d-c68a-2d07913c9f87@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
 <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>
 <1cdaa1da-9954-f15d-c68a-2d07913c9f87@oracle.com>
Message-ID: <cd672b2a-e801-8814-0c74-897359d2598b@oracle.com>

Updated webrev (as you pointed) to modify WrappedPlainView to use FP version

http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.02/

I have used "round" to be true as
public static final int getTabbedTextOffset(Segment s, FontMetrics metrics,
 ???????????????????????????????????????????? int x0, int x, TabExpander e,
 ???????????????????????????????????????????? int startOffset) {
uses "round" value as true.
I did not find any other usage of this int version of the API other than 
WrappedPlainView.

static final int getTabbedTextOffset(View view, Segment s, FontMetrics 
metrics,
 ???????????????????????????????????????? int x0, int x, TabExpander e,
 ???????????????????????????????????????? int startOffset,
 ???????????????????????????????????????? int[] justificationData) {}
is used in GLyphPainter1#viewToModel but it was not needed for this 
particular issue so I have not changed it for now.

Regards
Prasanta
On 6/7/2018 3:33 AM, Phil Race wrote:
> This is changing the internals of getTabbedTextOffset and using FP 
> regardless
> of whether useFPAPI is true. This is not what I said.
>
> I wrote that you should call the FP version directly.
>
> Look at this
> ---
> ???? * @deprecated replaced by
> ???? *???? {@link #getTabbedTextOffset(Segment, FontMetrics, float, 
> float,
> ???? *???????????????????????????????? TabExpander, int, boolean)}
> ???? */
> ??? @Deprecated(since = "9")
> ??? public static final int getTabbedTextOffset(Segment s, FontMetrics 
> metrics,
> ???????????????????????????????????????????? int x0, int x, 
> TabExpander e,
> ???????????????????????????????????????????? int startOffset) {
> ??????? return getTabbedTextOffset(s, metrics, x0, x, e, startOffset, 
> true);
> ----
> If we had wanted what you proposed in the first webrev and I think
> this one is effectively same, we'd have altered the behaviour to and not
> deprecated and added new API
>
> So whatever code in our L&F is currently calling
>
> getTabbedTextOffset(Segment s,
> ??????????????????? FontMetrics metrics,
> ??????????????????? int x0, int x, TabExpander e,
> ??????????????????? int startOffset)
>
> should instead call
>
> getTabbedTextOffset(Segment s,
> ??????????????????? FontMetrics metrics,
> ??????????????????? float x0, float x, TabExpander e,
> ??????????????????? int startOffset,
> ??????????????????? boolean round)
>
> I am not sure if round should be true or false but calling the float 
> version is the key.
>
> This (and no other change needed) does the trick for me :
>
> --- 
> a/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java
> +++ 
> b/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java
> @@ -360,11 +360,11 @@
> ???????? int currentWidth = getWidth();
> ???????? if (wordWrap) {
> ???????????? p = p0 + Utilities.getBreakLocation(segment, metrics,
> -??????????????????????????????????????????????? tabBase, tabBase + 
> currentWidth,
> +??????????????????????????????????????????????? (float)tabBase, 
> (float)(tabBase + currentWidth),
> ???????????????????????????????????????????????? this, p0);
> ???????? } else {
> ???????????? p = p0 + Utilities.getTabbedTextOffset(segment, metrics,
> -?????????????????????????????????????????????????? tabBase, tabBase + 
> currentWidth,
> + (float)tabBase, (float)(tabBase + currentWidth),
> ??????????????????????????????????????????????????? this, p0, false);
> ???????? }
> ???????? SegmentCache.releaseSharedSegment(segment);
> @@ -847,8 +847,8 @@
> ???????????????????????? Segment segment = 
> SegmentCache.getSharedSegment();
> ???????????????????????? loadText(segment, p0, p1);
> ???????????????????????? int n = 
> Utilities.getTabbedTextOffset(segment, metrics,
> -?????????????????????????????????????????????????? alloc.x, x,
> - WrappedPlainView.this, p0);
> + (float)(alloc.x), (float)x,
> + WrappedPlainView.this, p0, false);
> SegmentCache.releaseSharedSegment(segment);
> ???????????????????????? return Math.min(p0 + n, p1 - 1);
> ???????????????????? }
>
> I may have missed something else but to verify I downloaded and used 
> your test, which BTW has DOS line-endings !
>
> -phil.
>
> On 06/06/2018 12:04 AM, Prasanta Sadhukhan wrote:
>>
>>
>> On 5/9/2018 12:41 AM, Phil Race wrote:
>>> I am not sure this is the right fix.
>>> If the intention had been to change all calls to 
>>> getTabbedTextOffset() to use the FP
>>> API it would have just been changed .. rather than adding a new API 
>>> that provides
>>> the option to specify whether to use FP.
>>>
>>> So perhaps the problem is that internal code needs to be updated to 
>>> call the FP
>>> version directly ..
>> I have updated the internal code to use the FP version directly
>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.01/
>> There are no new regressions in jtreg and jck tests.
>>
>> Regards
>> Prasanta
>>> I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992 to 
>>> see
>>> what was said there but JBS just went down for 5 hours maintenance ..
>>>
>>> -phil.
>>>
>>> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>>>> Hi Sergey,
>>>>
>>>> I have run javax/swing/text jtreg and jck tests and did not observe 
>>>> any regressions.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Please confirm that you run related jck/reg tests.
>>>>>
>>>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review a fix for an issue where it is seen that,
>>>>>> ? with a screen resolution higher than 100% and then clicking in 
>>>>>> a JTextArea having setLineWrap(true) set, the caret (insertion 
>>>>>> point) is not aligned with the cursor.
>>>>>>
>>>>>> The issue seems to stem from the fact that caret position 
>>>>>> calculation in DefaultCaret class utilises API that uses integer 
>>>>>> calculation than floating point calculations.
>>>>>> The code flow as seen is
>>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset 
>>>>>>
>>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses 
>>>>>> integer arithmetic to get the caret position.
>>>>>> The same getTabbedOffset uses Font.getStringBounds() which uses 
>>>>>> floating point arithmetic via Rectangle2D.Float.
>>>>>>
>>>>>> Proposed fix is to make sure getTabbedOffset uses floating point 
>>>>>> calculations by using getStringBounds() instead of charsWidth() 
>>>>>> so that it calculates
>>>>>> the character width(s) of text present in JTextArea in floating 
>>>>>> point to align the caret.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>
>>>>>
>>>>
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Fri Jun  8 00:43:54 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 7 Jun 2018 17:43:54 -0700
Subject: <Swing Dev> [11] Review Request: 6608234 SwingWorker.get throws
 CancellationException
Message-ID: <fb3fcb74-df50-3951-4b29-25ca023ba50a@oracle.com>

Hello.
Please review the fix for jdk11.

Bug: https://bugs.openjdk.java.net/browse/JDK-6608234
Webrev: http://cr.openjdk.java.net/~serb/6608234/webrev.00
CSR: https://bugs.openjdk.java.net/browse/JDK-8204587

The SwingWorker.get(XX) methods copy the text of exceptions from the 
parent class, but the text for CancellationException is not copied, 
because CancellationException is unchecked exception and not declared in 
the method.

The similar bug was fixed for the parent class[1], so I used the same 
approach and add a "@throws CancellationException {@inheritDoc}" to the 
methods.

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

-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Fri Jun  8 04:46:21 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 8 Jun 2018 10:16:21 +0530
Subject: <Swing Dev> [11] Review Request: 6608234 SwingWorker.get throws
 CancellationException
In-Reply-To: <fb3fcb74-df50-3951-4b29-25ca023ba50a@oracle.com>
References: <fb3fcb74-df50-3951-4b29-25ca023ba50a@oracle.com>
Message-ID: <c4b9ea5c-6926-1308-b27a-feb1f76ab409@oracle.com>

looks good to me.

Regards
Prasanta
On 6/8/2018 6:13 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6608234
> Webrev: http://cr.openjdk.java.net/~serb/6608234/webrev.00
> CSR: https://bugs.openjdk.java.net/browse/JDK-8204587
>
> The SwingWorker.get(XX) methods copy the text of exceptions from the 
> parent class, but the text for CancellationException is not copied, 
> because CancellationException is unchecked exception and not declared 
> in the method.
>
> The similar bug was fixed for the parent class[1], so I used the same 
> approach and add a "@throws CancellationException {@inheritDoc}" to 
> the methods.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-6299797
>



From krishna.addepalli at oracle.com  Fri Jun  8 04:49:23 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 7 Jun 2018 21:49:23 -0700 (PDT)
Subject: <Swing Dev> [11] Review Request: 6608234 SwingWorker.get throws
 CancellationException
In-Reply-To: <c4b9ea5c-6926-1308-b27a-feb1f76ab409@oracle.com>
References: <fb3fcb74-df50-3951-4b29-25ca023ba50a@oracle.com>
 <c4b9ea5c-6926-1308-b27a-feb1f76ab409@oracle.com>
Message-ID: <41993c6c-96ca-4f01-866d-5e164a6a4757@default>

+1

-----Original Message-----
From: Prasanta Sadhukhan 
Sent: Friday, June 8, 2018 10:16 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: 6608234 SwingWorker.get throws CancellationException

looks good to me.

Regards
Prasanta
On 6/8/2018 6:13 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6608234
> Webrev: http://cr.openjdk.java.net/~serb/6608234/webrev.00
> CSR: https://bugs.openjdk.java.net/browse/JDK-8204587
>
> The SwingWorker.get(XX) methods copy the text of exceptions from the 
> parent class, but the text for CancellationException is not copied, 
> because CancellationException is unchecked exception and not declared 
> in the method.
>
> The similar bug was fixed for the parent class[1], so I used the same 
> approach and add a "@throws CancellationException {@inheritDoc}" to 
> the methods.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-6299797
>



From anton.tarasov at jetbrains.com  Fri Jun  8 14:57:58 2018
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Fri, 8 Jun 2018 17:57:58 +0300
Subject: <Swing Dev> [11] Review Request: 8202768 [macos] Appkit thread
 slows when any Window Manager active
In-Reply-To: <5a63d492-0e06-0cd4-6251-6ed006da9580@oracle.com>
References: <5a63d492-0e06-0cd4-6251-6ed006da9580@oracle.com>
Message-ID: <d069a723-83bf-6ad2-bbd6-c1e74c30e4e2@jetbrains.com>

Hi Sergey,

Is it possible that 'accessibilityAttributeNames' is called not from 
'NSAccessibilityUnignoredAncestor'? In that case it will behave 
differently when the element is ignored. From the other hand, it's 
probably useless to return any attribute except 
'NSAccessibilityParentAttribute' from an ignored element. In scope of 
that, does it make sense to return only 'NSAccessibilityParentAttribute' 
for an ignored element?

Regards,
Anton.

On 6/4/2018 11:57 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202768
> Webrev: http://cr.openjdk.java.net/~serb/8202768/webrev.00
>
> Short description:
> The root cause of the bug is tremendous complexity of code which 
> iterate over hierarchy of accessibility components, it was added 
> unintentionally in JDK-8145207:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/233b59b7ea2f#l8.97
>
> Description:
> Our NSView component implements a accessibilityHitTest() method which 
> is part of accessibility api. When this method is called we need to 
> return the first meaningful? accessibility component: "For example, 
> when you place a button in a window, the system typically creates a 
> button cell inside a button control inside a container view inside a 
> window. Users, however, don?t care about the view hierarchy details. 
> They should only be told that there?s a button in a window. "
>
> To iterate the accessibility components we use 
> NSAccessibilityUnignoredAncestor() method
> https://developer.apple.com/documentation/appkit/1531456-nsaccessibilityunignoredancestor?language=objc 
>
>
> which usually should work in this way:
> ? 1 Check is the component is ignored, if not then return it.
> ? 2 If the component is ignored, then request a 
> NSAccessibilityParentAttribute.
> ? 3 If NSAccessibilityParentAttribute is supported then repeat the 
> step1 for the parent. etc.
>
> But our implementation works in this way:
> ? 1 Check is the component is ignored, if not then return it.
> ? 2 If the component is ignored, then request a 
> NSAccessibilityParentAttribute.
> ? 3 Check that NSAccessibilityParentAttribute is supported. We create 
> a list of all supported attributes in accessibilityAttributeNames() - 
> method which was updated in the fix.
> ? 4 in the accessibilityAttributeNames() we need to access the parent 
> so we repeat the step 1 for the parent and its parent, and its parent, 
> etc.
> ? 5 We return back to the first iteration in 
> accessibilityAttributeNames()
> ? 6 We report that NSAccessibilityParentAttribute is supported(it was 
> requested at step3).
> ? 7 We return the NSAccessibilityParentAttribute requested at step2.
> ? 8 Repeat the step 1 until we will found unignored parent.
> (...) some intermediate steps were skipped.
>
>
> As you see at step4 we iterate hierarchy of accessibility components, 
> we do this for each component. So it is quite slow when we have big 
> hierarchy of ignored components.
>
> To block such iteration at step4 I have added a check that it is not 
> necessary to access the parent when we build the list of supported 
> attributes if the current component is "ignored".
>
> Note: The bug can be reproduced on macOS by the testcase when the 
> iSnap is active.
>
>



From Sergey.Bylokhov at oracle.com  Fri Jun  8 20:38:26 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 8 Jun 2018 13:38:26 -0700
Subject: <Swing Dev> [11] Review Request: 8202768 [macos] Appkit thread
 slows when any Window Manager active
In-Reply-To: <d069a723-83bf-6ad2-bbd6-c1e74c30e4e2@jetbrains.com>
References: <5a63d492-0e06-0cd4-6251-6ed006da9580@oracle.com>
 <d069a723-83bf-6ad2-bbd6-c1e74c30e4e2@jetbrains.com>
Message-ID: <c7109d95-e2ae-f344-f31f-c2afeab222d9@oracle.com>

Hi, Anton.

On 08/06/2018 07:57, Anton Tarasov wrote:
> Is it possible that 'accessibilityAttributeNames' is called not from 
> 'NSAccessibilityUnignoredAncestor'? In that case it will behave 
> differently when the element is ignored. From the other hand, it's 
> probably useless to return any attribute except 
> 'NSAccessibilityParentAttribute' from an ignored element. In scope of 
> that, does it make sense to return only 'NSAccessibilityParentAttribute' 
> for an ignored element?

Yes I think that most of the attributes are not necessary(not used) in 
case of "ignored elements". But I do not know for sure which, except 
"NSAccessibilityParentAttribute", should remain(like 
NSAccessibilityRoleAttribute/NSAccessibilityHelpAttribute or maybe 
children related attributes). So I decided to skip any additional 
attributes which are not set by default, because default attributes are 
cached and should not affect performance.

> 
> Regards,
> Anton.
> 
> On 6/4/2018 11:57 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk11.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202768
>> Webrev: http://cr.openjdk.java.net/~serb/8202768/webrev.00
>>
>> Short description:
>> The root cause of the bug is tremendous complexity of code which 
>> iterate over hierarchy of accessibility components, it was added 
>> unintentionally in JDK-8145207:
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/233b59b7ea2f#l8.97
>>
>> Description:
>> Our NSView component implements a accessibilityHitTest() method which 
>> is part of accessibility api. When this method is called we need to 
>> return the first meaningful? accessibility component: "For example, 
>> when you place a button in a window, the system typically creates a 
>> button cell inside a button control inside a container view inside a 
>> window. Users, however, don?t care about the view hierarchy details. 
>> They should only be told that there?s a button in a window. "
>>
>> To iterate the accessibility components we use 
>> NSAccessibilityUnignoredAncestor() method
>> https://developer.apple.com/documentation/appkit/1531456-nsaccessibilityunignoredancestor?language=objc 
>>
>>
>> which usually should work in this way:
>> ? 1 Check is the component is ignored, if not then return it.
>> ? 2 If the component is ignored, then request a 
>> NSAccessibilityParentAttribute.
>> ? 3 If NSAccessibilityParentAttribute is supported then repeat the 
>> step1 for the parent. etc.
>>
>> But our implementation works in this way:
>> ? 1 Check is the component is ignored, if not then return it.
>> ? 2 If the component is ignored, then request a 
>> NSAccessibilityParentAttribute.
>> ? 3 Check that NSAccessibilityParentAttribute is supported. We create 
>> a list of all supported attributes in accessibilityAttributeNames() - 
>> method which was updated in the fix.
>> ? 4 in the accessibilityAttributeNames() we need to access the parent 
>> so we repeat the step 1 for the parent and its parent, and its parent, 
>> etc.
>> ? 5 We return back to the first iteration in 
>> accessibilityAttributeNames()
>> ? 6 We report that NSAccessibilityParentAttribute is supported(it was 
>> requested at step3).
>> ? 7 We return the NSAccessibilityParentAttribute requested at step2.
>> ? 8 Repeat the step 1 until we will found unignored parent.
>> (...) some intermediate steps were skipped.
>>
>>
>> As you see at step4 we iterate hierarchy of accessibility components, 
>> we do this for each component. So it is quite slow when we have big 
>> hierarchy of ignored components.
>>
>> To block such iteration at step4 I have added a check that it is not 
>> necessary to access the parent when we build the list of supported 
>> attributes if the current component is "ignored".
>>
>> Note: The bug can be reproduced on macOS by the testcase when the 
>> iSnap is active.
>>
>>
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Fri Jun  8 22:19:40 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 08 Jun 2018 15:19:40 -0700
Subject: <Swing Dev> [11] Review Request: 6608234 SwingWorker.get throws
 CancellationException
In-Reply-To: <fb3fcb74-df50-3951-4b29-25ca023ba50a@oracle.com>
References: <fb3fcb74-df50-3951-4b29-25ca023ba50a@oracle.com>
Message-ID: <5B1B00FC.1040701@oracle.com>

+1

-phil.

On 6/7/18, 5:43 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6608234
> Webrev: http://cr.openjdk.java.net/~serb/6608234/webrev.00
> CSR: https://bugs.openjdk.java.net/browse/JDK-8204587
>
> The SwingWorker.get(XX) methods copy the text of exceptions from the 
> parent class, but the text for CancellationException is not copied, 
> because CancellationException is unchecked exception and not declared 
> in the method.
>
> The similar bug was fixed for the parent class[1], so I used the same 
> approach and add a "@throws CancellationException {@inheritDoc}" to 
> the methods.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-6299797
>


From philip.race at oracle.com  Fri Jun  8 22:23:00 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 08 Jun 2018 15:23:00 -0700
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <cd672b2a-e801-8814-0c74-897359d2598b@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
 <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>
 <1cdaa1da-9954-f15d-c68a-2d07913c9f87@oracle.com>
 <cd672b2a-e801-8814-0c74-897359d2598b@oracle.com>
Message-ID: <5B1B01C4.3050806@oracle.com>

The oddity about using round=true at line 845 is the other case seems to 
be using round == false ?

I think round==false was intended for use with fractional metrics but it 
is not clear.

-phil

On 6/7/18, 4:12 AM, Prasanta Sadhukhan wrote:
> Updated webrev (as you pointed) to modify WrappedPlainView to use FP 
> version
>
> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.02/
>
> I have used "round" to be true as
> public static final int getTabbedTextOffset(Segment s, FontMetrics 
> metrics,
>                                              int x0, int x, 
> TabExpander e,
>                                              int startOffset) {
> uses "round" value as true.
> I did not find any other usage of this int version of the API other 
> than WrappedPlainView.
>
> static final int getTabbedTextOffset(View view, Segment s, FontMetrics 
> metrics,
>                                          int x0, int x, TabExpander e,
>                                          int startOffset,
>                                          int[] justificationData) {}
> is used in GLyphPainter1#viewToModel but it was not needed for this 
> particular issue so I have not changed it for now.
>
> Regards
> Prasanta
> On 6/7/2018 3:33 AM, Phil Race wrote:
>> This is changing the internals of getTabbedTextOffset and using FP 
>> regardless
>> of whether useFPAPI is true. This is not what I said.
>>
>> I wrote that you should call the FP version directly.
>>
>> Look at this
>> ---
>>      * @deprecated replaced by
>>      *     {@link #getTabbedTextOffset(Segment, FontMetrics, float, 
>> float,
>>      *                                 TabExpander, int, boolean)}
>>      */
>>     @Deprecated(since = "9")
>>     public static final int getTabbedTextOffset(Segment s, 
>> FontMetrics metrics,
>>                                              int x0, int x, 
>> TabExpander e,
>>                                              int startOffset) {
>>         return getTabbedTextOffset(s, metrics, x0, x, e, startOffset, 
>> true);
>> ----
>> If we had wanted what you proposed in the first webrev and I think
>> this one is effectively same, we'd have altered the behaviour to and not
>> deprecated and added new API
>>
>> So whatever code in our L&F is currently calling
>>
>> getTabbedTextOffset(Segment s,
>>                     FontMetrics metrics,
>>                     int x0, int x, TabExpander e,
>>                     int startOffset)
>>
>> should instead call
>>
>> getTabbedTextOffset(Segment s,
>>                     FontMetrics metrics,
>>                     float x0, float x, TabExpander e,
>>                     int startOffset,
>>                     boolean round)
>>
>> I am not sure if round should be true or false but calling the float 
>> version is the key.
>>
>> This (and no other change needed) does the trick for me :
>>
>> --- 
>> a/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java
>> +++ 
>> b/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java
>> @@ -360,11 +360,11 @@
>>          int currentWidth = getWidth();
>>          if (wordWrap) {
>>              p = p0 + Utilities.getBreakLocation(segment, metrics,
>> -                                                tabBase, tabBase + 
>> currentWidth,
>> +                                                (float)tabBase, 
>> (float)(tabBase + currentWidth),
>>                                                  this, p0);
>>          } else {
>>              p = p0 + Utilities.getTabbedTextOffset(segment, metrics,
>> -                                                   tabBase, tabBase 
>> + currentWidth,
>> + (float)tabBase, (float)(tabBase + currentWidth),
>>                                                     this, p0, false);
>>          }
>>          SegmentCache.releaseSharedSegment(segment);
>> @@ -847,8 +847,8 @@
>>                          Segment segment = 
>> SegmentCache.getSharedSegment();
>>                          loadText(segment, p0, p1);
>>                          int n = 
>> Utilities.getTabbedTextOffset(segment, metrics,
>> -                                                   alloc.x, x,
>> - WrappedPlainView.this, p0);
>> + (float)(alloc.x), (float)x,
>> + WrappedPlainView.this, p0, false);
>> SegmentCache.releaseSharedSegment(segment);
>>                          return Math.min(p0 + n, p1 - 1);
>>                      }
>>
>> I may have missed something else but to verify I downloaded and used 
>> your test, which BTW has DOS line-endings !
>>
>> -phil.
>>
>> On 06/06/2018 12:04 AM, Prasanta Sadhukhan wrote:
>>>
>>>
>>> On 5/9/2018 12:41 AM, Phil Race wrote:
>>>> I am not sure this is the right fix.
>>>> If the intention had been to change all calls to 
>>>> getTabbedTextOffset() to use the FP
>>>> API it would have just been changed .. rather than adding a new API 
>>>> that provides
>>>> the option to specify whether to use FP.
>>>>
>>>> So perhaps the problem is that internal code needs to be updated to 
>>>> call the FP
>>>> version directly ..
>>> I have updated the internal code to use the FP version directly
>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.01/
>>> There are no new regressions in jtreg and jck tests.
>>>
>>> Regards
>>> Prasanta
>>>> I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992 
>>>> to see
>>>> what was said there but JBS just went down for 5 hours maintenance ..
>>>>
>>>> -phil.
>>>>
>>>> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> I have run javax/swing/text jtreg and jck tests and did not 
>>>>> observe any regressions.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>>>>> Hi, Prasanta.
>>>>>> Please confirm that you run related jck/reg tests.
>>>>>>
>>>>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review a fix for an issue where it is seen that,
>>>>>>>   with a screen resolution higher than 100% and then clicking in 
>>>>>>> a JTextArea having setLineWrap(true) set, the caret (insertion 
>>>>>>> point) is not aligned with the cursor.
>>>>>>>
>>>>>>> The issue seems to stem from the fact that caret position 
>>>>>>> calculation in DefaultCaret class utilises API that uses integer 
>>>>>>> calculation than floating point calculations.
>>>>>>> The code flow as seen is
>>>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset 
>>>>>>>
>>>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which 
>>>>>>> uses integer arithmetic to get the caret position.
>>>>>>> The same getTabbedOffset uses Font.getStringBounds() which uses 
>>>>>>> floating point arithmetic via Rectangle2D.Float.
>>>>>>>
>>>>>>> Proposed fix is to make sure getTabbedOffset uses floating point 
>>>>>>> calculations by using getStringBounds() instead of charsWidth() 
>>>>>>> so that it calculates
>>>>>>> the character width(s) of text present in JTextArea in floating 
>>>>>>> point to align the caret.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From anton.tarasov at jetbrains.com  Sat Jun  9 14:20:43 2018
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Sat, 9 Jun 2018 17:20:43 +0300
Subject: <Swing Dev> [11] Review Request: 8202768 [macos] Appkit thread
 slows when any Window Manager active
In-Reply-To: <c7109d95-e2ae-f344-f31f-c2afeab222d9@oracle.com>
References: <5a63d492-0e06-0cd4-6251-6ed006da9580@oracle.com>
 <d069a723-83bf-6ad2-bbd6-c1e74c30e4e2@jetbrains.com>
 <c7109d95-e2ae-f344-f31f-c2afeab222d9@oracle.com>
Message-ID: <0db94623-ad0e-1c8e-0899-b6653cd1d2eb@jetbrains.com>

On 6/8/2018 11:38 PM, Sergey Bylokhov wrote:
> Hi, Anton.
>
> On 08/06/2018 07:57, Anton Tarasov wrote:
>> Is it possible that 'accessibilityAttributeNames' is called not from 
>> 'NSAccessibilityUnignoredAncestor'? In that case it will behave 
>> differently when the element is ignored. From the other hand, it's 
>> probably useless to return any attribute except 
>> 'NSAccessibilityParentAttribute' from an ignored element. In scope of 
>> that, does it make sense to return only 
>> 'NSAccessibilityParentAttribute' for an ignored element?
>
> Yes I think that most of the attributes are not necessary(not used) in 
> case of "ignored elements". But I do not know for sure which, except 
> "NSAccessibilityParentAttribute", should remain(like 
> NSAccessibilityRoleAttribute/NSAccessibilityHelpAttribute or maybe 
> children related attributes). So I decided to skip any additional 
> attributes which are not set by default, because default attributes 
> are cached and should not affect performance.

Ok, then. I'm fine with the fix.

Regards,
Anton.

>
>>
>> Regards,
>> Anton.
>>
>> On 6/4/2018 11:57 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk11.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202768
>>> Webrev: http://cr.openjdk.java.net/~serb/8202768/webrev.00
>>>
>>> Short description:
>>> The root cause of the bug is tremendous complexity of code which 
>>> iterate over hierarchy of accessibility components, it was added 
>>> unintentionally in JDK-8145207:
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/233b59b7ea2f#l8.97
>>>
>>> Description:
>>> Our NSView component implements a accessibilityHitTest() method 
>>> which is part of accessibility api. When this method is called we 
>>> need to return the first meaningful? accessibility component: "For 
>>> example, when you place a button in a window, the system typically 
>>> creates a button cell inside a button control inside a container 
>>> view inside a window. Users, however, don?t care about the view 
>>> hierarchy details. They should only be told that there?s a button in 
>>> a window. "
>>>
>>> To iterate the accessibility components we use 
>>> NSAccessibilityUnignoredAncestor() method
>>> https://developer.apple.com/documentation/appkit/1531456-nsaccessibilityunignoredancestor?language=objc 
>>>
>>>
>>> which usually should work in this way:
>>> ? 1 Check is the component is ignored, if not then return it.
>>> ? 2 If the component is ignored, then request a 
>>> NSAccessibilityParentAttribute.
>>> ? 3 If NSAccessibilityParentAttribute is supported then repeat the 
>>> step1 for the parent. etc.
>>>
>>> But our implementation works in this way:
>>> ? 1 Check is the component is ignored, if not then return it.
>>> ? 2 If the component is ignored, then request a 
>>> NSAccessibilityParentAttribute.
>>> ? 3 Check that NSAccessibilityParentAttribute is supported. We 
>>> create a list of all supported attributes in 
>>> accessibilityAttributeNames() - method which was updated in the fix.
>>> ? 4 in the accessibilityAttributeNames() we need to access the 
>>> parent so we repeat the step 1 for the parent and its parent, and 
>>> its parent, etc.
>>> ? 5 We return back to the first iteration in 
>>> accessibilityAttributeNames()
>>> ? 6 We report that NSAccessibilityParentAttribute is supported(it 
>>> was requested at step3).
>>> ? 7 We return the NSAccessibilityParentAttribute requested at step2.
>>> ? 8 Repeat the step 1 until we will found unignored parent.
>>> (...) some intermediate steps were skipped.
>>>
>>>
>>> As you see at step4 we iterate hierarchy of accessibility 
>>> components, we do this for each component. So it is quite slow when 
>>> we have big hierarchy of ignored components.
>>>
>>> To block such iteration at step4 I have added a check that it is not 
>>> necessary to access the parent when we build the list of supported 
>>> attributes if the current component is "ignored".
>>>
>>> Note: The bug can be reproduced on macOS by the testcase when the 
>>> iSnap is active.
>>>
>>>
>>
>
>



From prasanta.sadhukhan at oracle.com  Sun Jun 10 15:42:53 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sun, 10 Jun 2018 21:12:53 +0530
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <5B1B01C4.3050806@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
 <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>
 <1cdaa1da-9954-f15d-c68a-2d07913c9f87@oracle.com>
 <cd672b2a-e801-8814-0c74-897359d2598b@oracle.com>
 <5B1B01C4.3050806@oracle.com>
Message-ID: <e50f100f-7aef-71bd-e455-d0ce9ba56d49@oracle.com>



On 6/9/2018 3:53 AM, Philip Race wrote:
> The oddity about using round=true at line 845 is the other case seems 
> to be using round == false ?
>
> I think round==false was intended for use with fractional metrics but 
> it is not clear.
>
Seems logical.
Modified webrev
http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.03/

Regards
Prasanta
> -phil
>
> On 6/7/18, 4:12 AM, Prasanta Sadhukhan wrote:
>> Updated webrev (as you pointed) to modify WrappedPlainView to use FP 
>> version
>>
>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.02/
>>
>> I have used "round" to be true as
>> public static final int getTabbedTextOffset(Segment s, FontMetrics 
>> metrics,
>> ???????????????????????????????????????????? int x0, int x, 
>> TabExpander e,
>> ???????????????????????????????????????????? int startOffset) {
>> uses "round" value as true.
>> I did not find any other usage of this int version of the API other 
>> than WrappedPlainView.
>>
>> static final int getTabbedTextOffset(View view, Segment s, 
>> FontMetrics metrics,
>> ???????????????????????????????????????? int x0, int x, TabExpander e,
>> ???????????????????????????????????????? int startOffset,
>> ???????????????????????????????????????? int[] justificationData) {}
>> is used in GLyphPainter1#viewToModel but it was not needed for this 
>> particular issue so I have not changed it for now.
>>
>> Regards
>> Prasanta
>> On 6/7/2018 3:33 AM, Phil Race wrote:
>>> This is changing the internals of getTabbedTextOffset and using FP 
>>> regardless
>>> of whether useFPAPI is true. This is not what I said.
>>>
>>> I wrote that you should call the FP version directly.
>>>
>>> Look at this
>>> ---
>>> ???? * @deprecated replaced by
>>> ???? *???? {@link #getTabbedTextOffset(Segment, FontMetrics, float, 
>>> float,
>>> ???? *???????????????????????????????? TabExpander, int, boolean)}
>>> ???? */
>>> ??? @Deprecated(since = "9")
>>> ??? public static final int getTabbedTextOffset(Segment s, 
>>> FontMetrics metrics,
>>> ???????????????????????????????????????????? int x0, int x, 
>>> TabExpander e,
>>> ???????????????????????????????????????????? int startOffset) {
>>> ??????? return getTabbedTextOffset(s, metrics, x0, x, e, 
>>> startOffset, true);
>>> ----
>>> If we had wanted what you proposed in the first webrev and I think
>>> this one is effectively same, we'd have altered the behaviour to and 
>>> not
>>> deprecated and added new API
>>>
>>> So whatever code in our L&F is currently calling
>>>
>>> getTabbedTextOffset(Segment s,
>>> ??????????????????? FontMetrics metrics,
>>> ??????????????????? int x0, int x, TabExpander e,
>>> ??????????????????? int startOffset)
>>>
>>> should instead call
>>>
>>> getTabbedTextOffset(Segment s,
>>> ??????????????????? FontMetrics metrics,
>>> ??????????????????? float x0, float x, TabExpander e,
>>> ??????????????????? int startOffset,
>>> ??????????????????? boolean round)
>>>
>>> I am not sure if round should be true or false but calling the float 
>>> version is the key.
>>>
>>> This (and no other change needed) does the trick for me :
>>>
>>> --- 
>>> a/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java
>>> +++ 
>>> b/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java
>>> @@ -360,11 +360,11 @@
>>> ???????? int currentWidth = getWidth();
>>> ???????? if (wordWrap) {
>>> ???????????? p = p0 + Utilities.getBreakLocation(segment, metrics,
>>> -??????????????????????????????????????????????? tabBase, tabBase + 
>>> currentWidth,
>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>> ???????????????????????????????????????????????? this, p0);
>>> ???????? } else {
>>> ???????????? p = p0 + Utilities.getTabbedTextOffset(segment, metrics,
>>> -?????????????????????????????????????????????????? tabBase, tabBase 
>>> + currentWidth,
>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>> ??????????????????????????????????????????????????? this, p0, false);
>>> ???????? }
>>> ???????? SegmentCache.releaseSharedSegment(segment);
>>> @@ -847,8 +847,8 @@
>>> ???????????????????????? Segment segment = 
>>> SegmentCache.getSharedSegment();
>>> ???????????????????????? loadText(segment, p0, p1);
>>> ???????????????????????? int n = 
>>> Utilities.getTabbedTextOffset(segment, metrics,
>>> -?????????????????????????????????????????????????? alloc.x, x,
>>> - WrappedPlainView.this, p0);
>>> + (float)(alloc.x), (float)x,
>>> + WrappedPlainView.this, p0, false);
>>> SegmentCache.releaseSharedSegment(segment);
>>> ???????????????????????? return Math.min(p0 + n, p1 - 1);
>>> ???????????????????? }
>>>
>>> I may have missed something else but to verify I downloaded and used 
>>> your test, which BTW has DOS line-endings !
>>>
>>> -phil.
>>>
>>> On 06/06/2018 12:04 AM, Prasanta Sadhukhan wrote:
>>>>
>>>>
>>>> On 5/9/2018 12:41 AM, Phil Race wrote:
>>>>> I am not sure this is the right fix.
>>>>> If the intention had been to change all calls to 
>>>>> getTabbedTextOffset() to use the FP
>>>>> API it would have just been changed .. rather than adding a new 
>>>>> API that provides
>>>>> the option to specify whether to use FP.
>>>>>
>>>>> So perhaps the problem is that internal code needs to be updated 
>>>>> to call the FP
>>>>> version directly ..
>>>> I have updated the internal code to use the FP version directly
>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.01/
>>>> There are no new regressions in jtreg and jck tests.
>>>>
>>>> Regards
>>>> Prasanta
>>>>> I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992 
>>>>> to see
>>>>> what was said there but JBS just went down for 5 hours maintenance ..
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> I have run javax/swing/text jtreg and jck tests and did not 
>>>>>> observe any regressions.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>>>>>> Hi, Prasanta.
>>>>>>> Please confirm that you run related jck/reg tests.
>>>>>>>
>>>>>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review a fix for an issue where it is seen that,
>>>>>>>> ? with a screen resolution higher than 100% and then clicking 
>>>>>>>> in a JTextArea having setLineWrap(true) set, the caret 
>>>>>>>> (insertion point) is not aligned with the cursor.
>>>>>>>>
>>>>>>>> The issue seems to stem from the fact that caret position 
>>>>>>>> calculation in DefaultCaret class utilises API that uses 
>>>>>>>> integer calculation than floating point calculations.
>>>>>>>> The code flow as seen is
>>>>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset 
>>>>>>>>
>>>>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which 
>>>>>>>> uses integer arithmetic to get the caret position.
>>>>>>>> The same getTabbedOffset uses Font.getStringBounds() which uses 
>>>>>>>> floating point arithmetic via Rectangle2D.Float.
>>>>>>>>
>>>>>>>> Proposed fix is to make sure getTabbedOffset uses floating 
>>>>>>>> point calculations by using getStringBounds() instead of 
>>>>>>>> charsWidth() so that it calculates
>>>>>>>> the character width(s) of text present in JTextArea in floating 
>>>>>>>> point to align the caret.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>


From philip.race at oracle.com  Mon Jun 11 00:59:00 2018
From: philip.race at oracle.com (Philip Race)
Date: Sun, 10 Jun 2018 17:59:00 -0700
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <e50f100f-7aef-71bd-e455-d0ce9ba56d49@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
 <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>
 <1cdaa1da-9954-f15d-c68a-2d07913c9f87@oracle.com>
 <cd672b2a-e801-8814-0c74-897359d2598b@oracle.com>
 <5B1B01C4.3050806@oracle.com>
 <e50f100f-7aef-71bd-e455-d0ce9ba56d49@oracle.com>
Message-ID: <5B1DC954.3070908@oracle.com>

FWIW I looked at this comment in the getTabbedTextOffset method
                 // the length of the string measured as a whole may 
differ from
                 // the sum of individual character lengths, for example if
                 // fractional metrics are enabled; and we must guard 
from this.

I am not really sure what the author was trying to say here.
Fractional Metrics is NOT the same thing as using floating point to 
measure width.
You will need floating point for fractional metrics .. but that makes it 
a necessary condition,
not the same thing.

Also I looked at the rounding code

The logic for round==true seems to be trying to find the offset that is 
closest
to the target position, so it may be less, the same or greater.

For round=false, it is trying to find the largest offset that does not 
exceed it.

I am not sure who would use the true case, but at least we can be consistent
in using false in both cases.

+1

-phil.
-phil

On 6/10/18, 8:42 AM, Prasanta Sadhukhan wrote:
>
>
> On 6/9/2018 3:53 AM, Philip Race wrote:
>> The oddity about using round=true at line 845 is the other case seems 
>> to be using round == false ?
>>
>> I think round==false was intended for use with fractional metrics but 
>> it is not clear.
>>
> Seems logical.
> Modified webrev
> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.03/
>
> Regards
> Prasanta
>> -phil
>>
>> On 6/7/18, 4:12 AM, Prasanta Sadhukhan wrote:
>>> Updated webrev (as you pointed) to modify WrappedPlainView to use FP 
>>> version
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.02/
>>>
>>> I have used "round" to be true as
>>> public static final int getTabbedTextOffset(Segment s, FontMetrics 
>>> metrics,
>>>                                              int x0, int x, 
>>> TabExpander e,
>>>                                              int startOffset) {
>>> uses "round" value as true.
>>> I did not find any other usage of this int version of the API other 
>>> than WrappedPlainView.
>>>
>>> static final int getTabbedTextOffset(View view, Segment s, 
>>> FontMetrics metrics,
>>>                                          int x0, int x, TabExpander e,
>>>                                          int startOffset,
>>>                                          int[] justificationData) {}
>>> is used in GLyphPainter1#viewToModel but it was not needed for this 
>>> particular issue so I have not changed it for now.
>>>
>>> Regards
>>> Prasanta
>>> On 6/7/2018 3:33 AM, Phil Race wrote:
>>>> This is changing the internals of getTabbedTextOffset and using FP 
>>>> regardless
>>>> of whether useFPAPI is true. This is not what I said.
>>>>
>>>> I wrote that you should call the FP version directly.
>>>>
>>>> Look at this
>>>> ---
>>>>      * @deprecated replaced by
>>>>      *     {@link #getTabbedTextOffset(Segment, FontMetrics, float, 
>>>> float,
>>>>      *                                 TabExpander, int, boolean)}
>>>>      */
>>>>     @Deprecated(since = "9")
>>>>     public static final int getTabbedTextOffset(Segment s, 
>>>> FontMetrics metrics,
>>>>                                              int x0, int x, 
>>>> TabExpander e,
>>>>                                              int startOffset) {
>>>>         return getTabbedTextOffset(s, metrics, x0, x, e, 
>>>> startOffset, true);
>>>> ----
>>>> If we had wanted what you proposed in the first webrev and I think
>>>> this one is effectively same, we'd have altered the behaviour to 
>>>> and not
>>>> deprecated and added new API
>>>>
>>>> So whatever code in our L&F is currently calling
>>>>
>>>> getTabbedTextOffset(Segment s,
>>>>                     FontMetrics metrics,
>>>>                     int x0, int x, TabExpander e,
>>>>                     int startOffset)
>>>>
>>>> should instead call
>>>>
>>>> getTabbedTextOffset(Segment s,
>>>>                     FontMetrics metrics,
>>>>                     float x0, float x, TabExpander e,
>>>>                     int startOffset,
>>>>                     boolean round)
>>>>
>>>> I am not sure if round should be true or false but calling the 
>>>> float version is the key.
>>>>
>>>> This (and no other change needed) does the trick for me :
>>>>
>>>> --- 
>>>> a/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java 
>>>>
>>>> +++ 
>>>> b/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java 
>>>>
>>>> @@ -360,11 +360,11 @@
>>>>          int currentWidth = getWidth();
>>>>          if (wordWrap) {
>>>>              p = p0 + Utilities.getBreakLocation(segment, metrics,
>>>> -                                                tabBase, tabBase + 
>>>> currentWidth,
>>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>>>                                                  this, p0);
>>>>          } else {
>>>>              p = p0 + Utilities.getTabbedTextOffset(segment, metrics,
>>>> -                                                   tabBase, 
>>>> tabBase + currentWidth,
>>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>>>                                                     this, p0, false);
>>>>          }
>>>>          SegmentCache.releaseSharedSegment(segment);
>>>> @@ -847,8 +847,8 @@
>>>>                          Segment segment = 
>>>> SegmentCache.getSharedSegment();
>>>>                          loadText(segment, p0, p1);
>>>>                          int n = 
>>>> Utilities.getTabbedTextOffset(segment, metrics,
>>>> -                                                   alloc.x, x,
>>>> - WrappedPlainView.this, p0);
>>>> + (float)(alloc.x), (float)x,
>>>> + WrappedPlainView.this, p0, false);
>>>> SegmentCache.releaseSharedSegment(segment);
>>>>                          return Math.min(p0 + n, p1 - 1);
>>>>                      }
>>>>
>>>> I may have missed something else but to verify I downloaded and 
>>>> used your test, which BTW has DOS line-endings !
>>>>
>>>> -phil.
>>>>
>>>> On 06/06/2018 12:04 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>>
>>>>> On 5/9/2018 12:41 AM, Phil Race wrote:
>>>>>> I am not sure this is the right fix.
>>>>>> If the intention had been to change all calls to 
>>>>>> getTabbedTextOffset() to use the FP
>>>>>> API it would have just been changed .. rather than adding a new 
>>>>>> API that provides
>>>>>> the option to specify whether to use FP.
>>>>>>
>>>>>> So perhaps the problem is that internal code needs to be updated 
>>>>>> to call the FP
>>>>>> version directly ..
>>>>> I have updated the internal code to use the FP version directly
>>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.01/
>>>>> There are no new regressions in jtreg and jck tests.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>> I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992 
>>>>>> to see
>>>>>> what was said there but JBS just went down for 5 hours 
>>>>>> maintenance ..
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> I have run javax/swing/text jtreg and jck tests and did not 
>>>>>>> observe any regressions.
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Prasanta.
>>>>>>>> Please confirm that you run related jck/reg tests.
>>>>>>>>
>>>>>>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review a fix for an issue where it is seen that,
>>>>>>>>>   with a screen resolution higher than 100% and then clicking 
>>>>>>>>> in a JTextArea having setLineWrap(true) set, the caret 
>>>>>>>>> (insertion point) is not aligned with the cursor.
>>>>>>>>>
>>>>>>>>> The issue seems to stem from the fact that caret position 
>>>>>>>>> calculation in DefaultCaret class utilises API that uses 
>>>>>>>>> integer calculation than floating point calculations.
>>>>>>>>> The code flow as seen is
>>>>>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset 
>>>>>>>>>
>>>>>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which 
>>>>>>>>> uses integer arithmetic to get the caret position.
>>>>>>>>> The same getTabbedOffset uses Font.getStringBounds() which 
>>>>>>>>> uses floating point arithmetic via Rectangle2D.Float.
>>>>>>>>>
>>>>>>>>> Proposed fix is to make sure getTabbedOffset uses floating 
>>>>>>>>> point calculations by using getStringBounds() instead of 
>>>>>>>>> charsWidth() so that it calculates
>>>>>>>>> the character width(s) of text present in JTextArea in 
>>>>>>>>> floating point to align the caret.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>


From prasanta.sadhukhan at oracle.com  Wed Jun 13 07:48:57 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 13 Jun 2018 13:18:57 +0530
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <5B0DD789.8000809@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com>
 <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com>
 <a9af14aa-c92f-435e-57b2-5213f96f3431@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
Message-ID: <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>

Hi Phil, All

Please find modified webrev taking care of streamlining 
SwingInteropUtils class and handling of native window handle in 
LightweightFrameWrapper class by using JNI call in FX
http://cr.openjdk.java.net/~psadhukhan/fxswing.14/

Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175

Regards
Prasanta
On 5/30/2018 4:13 AM, Philip Race wrote:
> Some follow up comments.
>
> On 5/10/18, 5:49 PM, Philip Race wrote:
>> I've looked over the Swing code. No time to actually try it out so I 
>> can only comment on what I see.
>>
>> I am not sure what I think about class docs like "This class wraps 
>> <names internal interface> .."
>> I know no javadoc is generated but this module is exported and 
>> probably should say something
>> less specific.
>>
>> In general I really have to hold my nose when looking at this whole 
>> module and I
>> find it distasteful to endorse it.
>>
>> I really don't like all the things SwingInterOpUtils.java does.
>>
> Specific things we should look at in this file
> - getDefaultScaleX/Y .. JDK 9 will set a transform on the graphics that
> is passed to JComponent.paintComponent() .. so I wonder if we really
> need this internal API. I doubt any other code is updating the transform
> in a way that would make it a problem so the information you get 
> should be valid.
>
> The code to get the data array for the raster and associated information
> can be extracted via standard API like this :
>
> DataBuffer? db = BufferedImage.getRaster().getDataBuffer();
> if (db instanceof DataBufferInt) {
> ?data = (DataBufferInt)db.getData();
> }
>
> So all of those can be fixed.
>
> The code that accepts a native window handle maybe should require it 
> is accessed via JNI ...
> It could still be unsupported, but it would be package private or similar.
> If you have a native ID, then you are already using native code.
> This sidesteps any questions about the stability of such an API which
> accepts a native resource.
>
> The code that finds a component by location is probably harmless ...
>
> I'm less sure about the event posting and focus grabbing support.
> I'd like to have Sergey comment on those.
>
> the DnD code is too much for me to examine in detail.
>> I worry we are creating something we'll come to regret here.
>> The "unsupportedness" needs to be backed up by deprecated-for-removal 
>> being included
>> today so we can get rid of it the next release if we want to.
>
> I've looked at jdk.unsupported and they don't seem to have deprecation 
> tags so
> maybe that isn't an issue.
>
> -phil
>>
>> No @since tags anywhere....
>>
>> -phil.
>>
>> On 5/10/18, 8:32 AM, Kevin Rushforth wrote:
>>> I confirm that this fixes the issue. The interface change to make 
>>> the two static methods e instance methods is a good change in any case.
>>>
>>> I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me.
>>>
>>> -- Kevin
>>>
>>>
>>> On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote:
>>>>
>>>> Hi Kevin,All,
>>>>
>>>> Please find the modified webrev fixing this #1 issue
>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.13/
>>>> via change in 
>>>> jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext 
>>>> and FXDnD.java#postDropTargetEvent
>>>>
>>>> For me, #2 works, #3 doesn't work even now due to JDK-8141391 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8141391> and #4 works for me.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/9/2018 11:29 PM, Kevin Rushforth wrote:
>>>>> Hi Prasanta,
>>>>>
>>>>> The API looks good now.
>>>>>
>>>>> All of our automated tests work (except for the ones with a 
>>>>> security manager due to JDK-8202451 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8202451>).
>>>>>
>>>>> The only functional problem that I see is that Drag and Drop onto 
>>>>> a SwingNode doesn't work. We need to make sure that we test the 
>>>>> following four cases:
>>>>>
>>>>> 1. Drag / drop onto a Swing component in a SwingNode
>>>>> 2. Drag / drop from a Swing component in a SwingNode
>>>>> 3. Drag / drop onto a JavaFX control in a JFXPanel
>>>>> 4. Drag / drop from a JavaFX control in a JFXPanel
>>>>>
>>>>> So far I only tried the first one; the others still need to be 
>>>>> validated.
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>>
>>>>> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote:
>>>>>> Modified webrev to cater to this
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote:
>>>>>>> The following can also be abstract:
>>>>>>>
>>>>>>> LightweightContentWrapper:
>>>>>>> ? getComponent, createDragGestureRecognizer, 
>>>>>>> createDragSourceContextPeer
>>>>>>>
>>>>>>> DropTargetContextWrapper:
>>>>>>> ? getTargetActions, getDropTarget, getTransferDataFlavors, 
>>>>>>> getTransferable, isTransferableJVMLocal
>>>>>>>
>>>>>>> DispatcherWrapper:
>>>>>>> ? isDispatchThread, createSecondaryLoop
>>>>>>>
>>>>>>> The rest looks good to me (although I still see two public 
>>>>>>> methods with "Peer" in the name, so Phil may want those renamed).
>>>>>>>
>>>>>>> -- Kevin
>>>>>>>
>>>>>>>
>>>>>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:
>>>>>>>> Modified webrev to cater to these 3 observations
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>>
>>>>>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
>>>>>>>>> The module definition for jdk.unsupported.desktop and the 
>>>>>>>>> changes to java.desktop look fine.
>>>>>>>>>
>>>>>>>>> In reviewing the jdk.swing.interop API, I have the following 
>>>>>>>>> suggestions / observations:
>>>>>>>>>
>>>>>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, 
>>>>>>>>> DropTargetContextWrapper, and LightweightContentWrapper can 
>>>>>>>>> all be abstract, along with most of the methods (rather than 
>>>>>>>>> having an empty body return value that is never used).
>>>>>>>>>
>>>>>>>>> 2. The addNotify method in LightweightFrameWrapper is unused. 
>>>>>>>>> Should be used somewhere? If not, then it can be removed.
>>>>>>>>>
>>>>>>>>> The implementation of the new wrapper classes looks OK to me 
>>>>>>>>> with one observation that might or might not matter:
>>>>>>>>>
>>>>>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in 
>>>>>>>>> SwingInteropUtils) has changed in the case where the Graphics 
>>>>>>>>> is not an instance of SunGraphics2D. The former behavior was 
>>>>>>>>> to leave the instance variables X and Y unchanged. The new 
>>>>>>>>> behavior will set them back to 1.0. Maybe this can't happen in 
>>>>>>>>> practice, but it is something to consider.
>>>>>>>>>
>>>>>>>>> -- Kevin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote:
>>>>>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote:
>>>>>>>>>>> Modified webrev to rename to InteropProviderImpl
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/
>>>>>>>>>> This looks okay to me.
>>>>>>>>>>
>>>>>>>>>> -Alan
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>

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

From prasanta.sadhukhan at oracle.com  Wed Jun 13 11:21:28 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 13 Jun 2018 16:51:28 +0530
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <5B1DC954.3070908@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
 <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>
 <1cdaa1da-9954-f15d-c68a-2d07913c9f87@oracle.com>
 <cd672b2a-e801-8814-0c74-897359d2598b@oracle.com>
 <5B1B01C4.3050806@oracle.com>
 <e50f100f-7aef-71bd-e455-d0ce9ba56d49@oracle.com>
 <5B1DC954.3070908@oracle.com>
Message-ID: <045a05d4-4f06-9228-e716-a78bb845317a@oracle.com>

Can I please have a 2nd +1 from someone?

Regards
Prasanta
On 6/11/2018 6:29 AM, Philip Race wrote:
> FWIW I looked at this comment in the getTabbedTextOffset method
> ??????????????? // the length of the string measured as a whole may 
> differ from
> ??????????????? // the sum of individual character lengths, for 
> example if
> ??????????????? // fractional metrics are enabled; and we must guard 
> from this.
>
> I am not really sure what the author was trying to say here.
> Fractional Metrics is NOT the same thing as using floating point to 
> measure width.
> You will need floating point for fractional metrics .. but that makes 
> it a necessary condition,
> not the same thing.
>
> Also I looked at the rounding code
>
> The logic for round==true seems to be trying to find the offset that 
> is closest
> to the target position, so it may be less, the same or greater.
>
> For round=false, it is trying to find the largest offset that does not 
> exceed it.
>
> I am not sure who would use the true case, but at least we can be 
> consistent
> in using false in both cases.
>
> +1
>
> -phil.
> -phil
>
> On 6/10/18, 8:42 AM, Prasanta Sadhukhan wrote:
>>
>>
>> On 6/9/2018 3:53 AM, Philip Race wrote:
>>> The oddity about using round=true at line 845 is the other case 
>>> seems to be using round == false ?
>>>
>>> I think round==false was intended for use with fractional metrics 
>>> but it is not clear.
>>>
>> Seems logical.
>> Modified webrev
>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.03/
>>
>> Regards
>> Prasanta
>>> -phil
>>>
>>> On 6/7/18, 4:12 AM, Prasanta Sadhukhan wrote:
>>>> Updated webrev (as you pointed) to modify WrappedPlainView to use 
>>>> FP version
>>>>
>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.02/
>>>>
>>>> I have used "round" to be true as
>>>> public static final int getTabbedTextOffset(Segment s, FontMetrics 
>>>> metrics,
>>>> ???????????????????????????????????????????? int x0, int x, 
>>>> TabExpander e,
>>>> ???????????????????????????????????????????? int startOffset) {
>>>> uses "round" value as true.
>>>> I did not find any other usage of this int version of the API other 
>>>> than WrappedPlainView.
>>>>
>>>> static final int getTabbedTextOffset(View view, Segment s, 
>>>> FontMetrics metrics,
>>>> ???????????????????????????????????????? int x0, int x, TabExpander e,
>>>> ???????????????????????????????????????? int startOffset,
>>>> ???????????????????????????????????????? int[] justificationData) {}
>>>> is used in GLyphPainter1#viewToModel but it was not needed for this 
>>>> particular issue so I have not changed it for now.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 6/7/2018 3:33 AM, Phil Race wrote:
>>>>> This is changing the internals of getTabbedTextOffset and using FP 
>>>>> regardless
>>>>> of whether useFPAPI is true. This is not what I said.
>>>>>
>>>>> I wrote that you should call the FP version directly.
>>>>>
>>>>> Look at this
>>>>> ---
>>>>> ???? * @deprecated replaced by
>>>>> ???? *???? {@link #getTabbedTextOffset(Segment, FontMetrics, 
>>>>> float, float,
>>>>> ???? *???????????????????????????????? TabExpander, int, boolean)}
>>>>> ???? */
>>>>> ??? @Deprecated(since = "9")
>>>>> ??? public static final int getTabbedTextOffset(Segment s, 
>>>>> FontMetrics metrics,
>>>>> ???????????????????????????????????????????? int x0, int x, 
>>>>> TabExpander e,
>>>>> ???????????????????????????????????????????? int startOffset) {
>>>>> ??????? return getTabbedTextOffset(s, metrics, x0, x, e, 
>>>>> startOffset, true);
>>>>> ----
>>>>> If we had wanted what you proposed in the first webrev and I think
>>>>> this one is effectively same, we'd have altered the behaviour to 
>>>>> and not
>>>>> deprecated and added new API
>>>>>
>>>>> So whatever code in our L&F is currently calling
>>>>>
>>>>> getTabbedTextOffset(Segment s,
>>>>> ??????????????????? FontMetrics metrics,
>>>>> ??????????????????? int x0, int x, TabExpander e,
>>>>> ??????????????????? int startOffset)
>>>>>
>>>>> should instead call
>>>>>
>>>>> getTabbedTextOffset(Segment s,
>>>>> ??????????????????? FontMetrics metrics,
>>>>> ??????????????????? float x0, float x, TabExpander e,
>>>>> ??????????????????? int startOffset,
>>>>> ??????????????????? boolean round)
>>>>>
>>>>> I am not sure if round should be true or false but calling the 
>>>>> float version is the key.
>>>>>
>>>>> This (and no other change needed) does the trick for me :
>>>>>
>>>>> --- 
>>>>> a/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java 
>>>>>
>>>>> +++ 
>>>>> b/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java 
>>>>>
>>>>> @@ -360,11 +360,11 @@
>>>>> ???????? int currentWidth = getWidth();
>>>>> ???????? if (wordWrap) {
>>>>> ???????????? p = p0 + Utilities.getBreakLocation(segment, metrics,
>>>>> -??????????????????????????????????????????????? tabBase, tabBase 
>>>>> + currentWidth,
>>>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>>>> ???????????????????????????????????????????????? this, p0);
>>>>> ???????? } else {
>>>>> ???????????? p = p0 + Utilities.getTabbedTextOffset(segment, metrics,
>>>>> - tabBase, tabBase + currentWidth,
>>>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>>>> ??????????????????????????????????????????????????? this, p0, false);
>>>>> ???????? }
>>>>> ???????? SegmentCache.releaseSharedSegment(segment);
>>>>> @@ -847,8 +847,8 @@
>>>>> ???????????????????????? Segment segment = 
>>>>> SegmentCache.getSharedSegment();
>>>>> ???????????????????????? loadText(segment, p0, p1);
>>>>> ???????????????????????? int n = 
>>>>> Utilities.getTabbedTextOffset(segment, metrics,
>>>>> - alloc.x, x,
>>>>> - WrappedPlainView.this, p0);
>>>>> + (float)(alloc.x), (float)x,
>>>>> + WrappedPlainView.this, p0, false);
>>>>> SegmentCache.releaseSharedSegment(segment);
>>>>> ???????????????????????? return Math.min(p0 + n, p1 - 1);
>>>>> ???????????????????? }
>>>>>
>>>>> I may have missed something else but to verify I downloaded and 
>>>>> used your test, which BTW has DOS line-endings !
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 06/06/2018 12:04 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>>
>>>>>> On 5/9/2018 12:41 AM, Phil Race wrote:
>>>>>>> I am not sure this is the right fix.
>>>>>>> If the intention had been to change all calls to 
>>>>>>> getTabbedTextOffset() to use the FP
>>>>>>> API it would have just been changed .. rather than adding a new 
>>>>>>> API that provides
>>>>>>> the option to specify whether to use FP.
>>>>>>>
>>>>>>> So perhaps the problem is that internal code needs to be updated 
>>>>>>> to call the FP
>>>>>>> version directly ..
>>>>>> I have updated the internal code to use the FP version directly
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.01/
>>>>>> There are no new regressions in jtreg and jck tests.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>>> I'd like to read 
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8168992 to see
>>>>>>> what was said there but JBS just went down for 5 hours 
>>>>>>> maintenance ..
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> I have run javax/swing/text jtreg and jck tests and did not 
>>>>>>>> observe any regressions.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>>>>>>>> Hi, Prasanta.
>>>>>>>>> Please confirm that you run related jck/reg tests.
>>>>>>>>>
>>>>>>>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review a fix for an issue where it is seen that,
>>>>>>>>>> ? with a screen resolution higher than 100% and then clicking 
>>>>>>>>>> in a JTextArea having setLineWrap(true) set, the caret 
>>>>>>>>>> (insertion point) is not aligned with the cursor.
>>>>>>>>>>
>>>>>>>>>> The issue seems to stem from the fact that caret position 
>>>>>>>>>> calculation in DefaultCaret class utilises API that uses 
>>>>>>>>>> integer calculation than floating point calculations.
>>>>>>>>>> The code flow as seen is
>>>>>>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset 
>>>>>>>>>>
>>>>>>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which 
>>>>>>>>>> uses integer arithmetic to get the caret position.
>>>>>>>>>> The same getTabbedOffset uses Font.getStringBounds() which 
>>>>>>>>>> uses floating point arithmetic via Rectangle2D.Float.
>>>>>>>>>>
>>>>>>>>>> Proposed fix is to make sure getTabbedOffset uses floating 
>>>>>>>>>> point calculations by using getStringBounds() instead of 
>>>>>>>>>> charsWidth() so that it calculates
>>>>>>>>>> the character width(s) of text present in JTextArea in 
>>>>>>>>>> floating point to align the caret.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>>>>>>>> webrev: 
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>


From krishna.addepalli at oracle.com  Wed Jun 13 12:17:11 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 13 Jun 2018 05:17:11 -0700 (PDT)
Subject: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not
 working properly in multi screen environments
Message-ID: <8f3e9dcc-1e44-4713-b8d5-a477d3887ee3@default>

Hi Sergey,

 

As per our conversation, please review a fix for 

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

Webrev: http://cr.openjdk.java.net/~kaddepalli/8176359/webrev00/

 

The problem is that when the secondary monitor is larger than the primary monitor, and the window needs to maximize onto the secondary screen, it results in wrong window sizes. 

The root cause is in WFramePeer::adjustMaximizedBounds, which tries to compensate the window bounds appropriately, but it is not adequate. It solves another related bug: JDK-6699851, but the requirement is that, for a window to be maximized even on a secondary screen, it still needs to provide the dimensions of the primary screen, and the Window Manager automatically compensates for the difference.

The proposed fix addresses this problem in both cases, but there are some more problems that were discovered on the way:

1.       The window bounds seem random (or atleast seem so), when maximized bounds that are larger than the primary screen bounds, but are smaller than the secondary screen bounds are provided. Unfortunately, there is no clear document/information regarding the way it is adjusted. The best I could get is this: https://blogs.msdn.microsoft.com/oldnewthing/20150501-00/?p=44964

2.       Scaling provides a new dimension of problems, and it seems hard to satisfy all the cases - due to the floating point computations. The proposed fix works for 100, 125, 150 and 175 % scalings, but again, it depends on the resolution of the monitors. 

3.       I have written a test case which tries to display maximized windows on each screen and tests if the bounds are proper. When I set the screen bounds as maximizedBounds, and then query the frame bounds post displaying the screen, they are not the same. However, I found that the contentPane bounds are closer, but still not exactly same. Is there something I'm missing?

 

Thanks,

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

From krishna.addepalli at oracle.com  Wed Jun 13 13:19:20 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 13 Jun 2018 06:19:20 -0700 (PDT)
Subject: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not
 working properly in multi screen environments
In-Reply-To: <8f3e9dcc-1e44-4713-b8d5-a477d3887ee3@default>
References: <8f3e9dcc-1e44-4713-b8d5-a477d3887ee3@default>
Message-ID: <e4c76f73-e5ae-4367-b7db-3d147999bd49@default>

One more question I forgot to ask:

4.       For running the test in different scaling modes, I have been manually changing the scaling values in the OS settings. However, I also have applied the -Dsun.java.uiScale vm parameter to run in different scaling modes. Is this equivalent to running the test in different scaling modes?

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, June 13, 2018 5:47 PM
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not working properly in multi screen environments

 

Hi Sergey,

 

As per our conversation, please review a fix for 

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

Webrev: http://cr.openjdk.java.net/~kaddepalli/8176359/webrev00/

 

The problem is that when the secondary monitor is larger than the primary monitor, and the window needs to maximize onto the secondary screen, it results in wrong window sizes. 

The root cause is in WFramePeer::adjustMaximizedBounds, which tries to compensate the window bounds appropriately, but it is not adequate. It solves another related bug: JDK-6699851, but the requirement is that, for a window to be maximized even on a secondary screen, it still needs to provide the dimensions of the primary screen, and the Window Manager automatically compensates for the difference.

The proposed fix addresses this problem in both cases, but there are some more problems that were discovered on the way:

1.       The window bounds seem random (or atleast seem so), when maximized bounds that are larger than the primary screen bounds, but are smaller than the secondary screen bounds are provided. Unfortunately, there is no clear document/information regarding the way it is adjusted. The best I could get is this: https://blogs.msdn.microsoft.com/oldnewthing/20150501-00/?p=44964

2.       Scaling provides a new dimension of problems, and it seems hard to satisfy all the cases - due to the floating point computations. The proposed fix works for 100, 125, 150 and 175 % scalings, but again, it depends on the resolution of the monitors. 

3.       I have written a test case which tries to display maximized windows on each screen and tests if the bounds are proper. When I set the screen bounds as maximizedBounds, and then query the frame bounds post displaying the screen, they are not the same. However, I found that the contentPane bounds are closer, but still not exactly same. Is there something I'm missing?

 

Thanks,

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

From kevin.rushforth at oracle.com  Thu Jun 14 01:04:51 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 13 Jun 2018 18:04:51 -0700
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com>
 <a9af14aa-c92f-435e-57b2-5213f96f3431@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
Message-ID: <d2ca2e89-215d-34b1-73f8-064c40eb512d@oracle.com>

The JDK changes look good to me, and as far as I have tested them, it 
works for me. I haven't tried Drag and Drop yet with the latest 
interface changes.

To repeat something I've mentioned before, just so there is no 
confusion, the FX side of the changes are intended to be a proof of 
concept to test the JDK side at this point. They will need refactoring 
before they can go in, so that FX will still be buildable and runnable 
with JDK 10.

-- Kevin


On 6/13/2018 12:48 AM, Prasanta Sadhukhan wrote:
>
> Hi Phil, All
>
> Please find modified webrev taking care of streamlining 
> SwingInteropUtils class and handling of native window handle in 
> LightweightFrameWrapper class by using JNI call in FX
> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/
>
> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175
>
> Regards
> Prasanta
> On 5/30/2018 4:13 AM, Philip Race wrote:
>> Some follow up comments.
>>
>> On 5/10/18, 5:49 PM, Philip Race wrote:
>>> I've looked over the Swing code. No time to actually try it out so I 
>>> can only comment on what I see.
>>>
>>> I am not sure what I think about class docs like "This class wraps 
>>> <names internal interface> .."
>>> I know no javadoc is generated but this module is exported and 
>>> probably should say something
>>> less specific.
>>>
>>> In general I really have to hold my nose when looking at this whole 
>>> module and I
>>> find it distasteful to endorse it.
>>>
>>> I really don't like all the things SwingInterOpUtils.java does.
>>>
>> Specific things we should look at in this file
>> - getDefaultScaleX/Y .. JDK 9 will set a transform on the graphics that
>> is passed to JComponent.paintComponent() .. so I wonder if we really
>> need this internal API. I doubt any other code is updating the transform
>> in a way that would make it a problem so the information you get 
>> should be valid.
>>
>> The code to get the data array for the raster and associated information
>> can be extracted via standard API like this :
>>
>> DataBuffer? db = BufferedImage.getRaster().getDataBuffer();
>> if (db instanceof DataBufferInt) {
>> ?data = (DataBufferInt)db.getData();
>> }
>>
>> So all of those can be fixed.
>>
>> The code that accepts a native window handle maybe should require it 
>> is accessed via JNI ...
>> It could still be unsupported, but it would be package private or 
>> similar.
>> If you have a native ID, then you are already using native code.
>> This sidesteps any questions about the stability of such an API which
>> accepts a native resource.
>>
>> The code that finds a component by location is probably harmless ...
>>
>> I'm less sure about the event posting and focus grabbing support.
>> I'd like to have Sergey comment on those.
>>
>> the DnD code is too much for me to examine in detail.
>>> I worry we are creating something we'll come to regret here.
>>> The "unsupportedness" needs to be backed up by 
>>> deprecated-for-removal being included
>>> today so we can get rid of it the next release if we want to.
>>
>> I've looked at jdk.unsupported and they don't seem to have 
>> deprecation tags so
>> maybe that isn't an issue.
>>
>> -phil
>>>
>>> No @since tags anywhere....
>>>
>>> -phil.
>>>
>>> On 5/10/18, 8:32 AM, Kevin Rushforth wrote:
>>>> I confirm that this fixes the issue. The interface change to make 
>>>> the two static methods e instance methods is a good change in any case.
>>>>
>>>> I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>> Hi Kevin,All,
>>>>>
>>>>> Please find the modified webrev fixing this #1 issue
>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.13/
>>>>> via change in 
>>>>> jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext 
>>>>> and FXDnD.java#postDropTargetEvent
>>>>>
>>>>> For me, #2 works, #3 doesn't work even now due to JDK-8141391 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8141391> and #4 works 
>>>>> for me.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 5/9/2018 11:29 PM, Kevin Rushforth wrote:
>>>>>> Hi Prasanta,
>>>>>>
>>>>>> The API looks good now.
>>>>>>
>>>>>> All of our automated tests work (except for the ones with a 
>>>>>> security manager due to JDK-8202451 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8202451>).
>>>>>>
>>>>>> The only functional problem that I see is that Drag and Drop onto 
>>>>>> a SwingNode doesn't work. We need to make sure that we test the 
>>>>>> following four cases:
>>>>>>
>>>>>> 1. Drag / drop onto a Swing component in a SwingNode
>>>>>> 2. Drag / drop from a Swing component in a SwingNode
>>>>>> 3. Drag / drop onto a JavaFX control in a JFXPanel
>>>>>> 4. Drag / drop from a JavaFX control in a JFXPanel
>>>>>>
>>>>>> So far I only tried the first one; the others still need to be 
>>>>>> validated.
>>>>>>
>>>>>> -- Kevin
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote:
>>>>>>> Modified webrev to cater to this
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote:
>>>>>>>> The following can also be abstract:
>>>>>>>>
>>>>>>>> LightweightContentWrapper:
>>>>>>>> ? getComponent, createDragGestureRecognizer, 
>>>>>>>> createDragSourceContextPeer
>>>>>>>>
>>>>>>>> DropTargetContextWrapper:
>>>>>>>> ? getTargetActions, getDropTarget, getTransferDataFlavors, 
>>>>>>>> getTransferable, isTransferableJVMLocal
>>>>>>>>
>>>>>>>> DispatcherWrapper:
>>>>>>>> ? isDispatchThread, createSecondaryLoop
>>>>>>>>
>>>>>>>> The rest looks good to me (although I still see two public 
>>>>>>>> methods with "Peer" in the name, so Phil may want those renamed).
>>>>>>>>
>>>>>>>> -- Kevin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:
>>>>>>>>> Modified webrev to cater to these 3 observations
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>>
>>>>>>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
>>>>>>>>>> The module definition for jdk.unsupported.desktop and the 
>>>>>>>>>> changes to java.desktop look fine.
>>>>>>>>>>
>>>>>>>>>> In reviewing the jdk.swing.interop API, I have the following 
>>>>>>>>>> suggestions / observations:
>>>>>>>>>>
>>>>>>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, 
>>>>>>>>>> DropTargetContextWrapper, and LightweightContentWrapper can 
>>>>>>>>>> all be abstract, along with most of the methods (rather than 
>>>>>>>>>> having an empty body return value that is never used).
>>>>>>>>>>
>>>>>>>>>> 2. The addNotify method in LightweightFrameWrapper is unused. 
>>>>>>>>>> Should be used somewhere? If not, then it can be removed.
>>>>>>>>>>
>>>>>>>>>> The implementation of the new wrapper classes looks OK to me 
>>>>>>>>>> with one observation that might or might not matter:
>>>>>>>>>>
>>>>>>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in 
>>>>>>>>>> SwingInteropUtils) has changed in the case where the Graphics 
>>>>>>>>>> is not an instance of SunGraphics2D. The former behavior was 
>>>>>>>>>> to leave the instance variables X and Y unchanged. The new 
>>>>>>>>>> behavior will set them back to 1.0. Maybe this can't happen 
>>>>>>>>>> in practice, but it is something to consider.
>>>>>>>>>>
>>>>>>>>>> -- Kevin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote:
>>>>>>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote:
>>>>>>>>>>>> Modified webrev to rename to InteropProviderImpl
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/
>>>>>>>>>>> This looks okay to me.
>>>>>>>>>>>
>>>>>>>>>>> -Alan
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>

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

From philip.race at oracle.com  Thu Jun 14 20:13:40 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 14 Jun 2018 13:13:40 -0700
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <d2ca2e89-215d-34b1-73f8-064c40eb512d@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <a9af14aa-c92f-435e-57b2-5213f96f3431@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
 <d2ca2e89-215d-34b1-73f8-064c40eb512d@oracle.com>
Message-ID: <7474446d-1829-c163-4c9c-fbadd863cbaf@oracle.com>

+1 from me for the JDK changes.

-phil.

On 06/13/2018 06:04 PM, Kevin Rushforth wrote:
> The JDK changes look good to me, and as far as I have tested them, it 
> works for me. I haven't tried Drag and Drop yet with the latest 
> interface changes.
>
> To repeat something I've mentioned before, just so there is no 
> confusion, the FX side of the changes are intended to be a proof of 
> concept to test the JDK side at this point. They will need refactoring 
> before they can go in, so that FX will still be buildable and runnable 
> with JDK 10.
>
> -- Kevin
>
>
> On 6/13/2018 12:48 AM, Prasanta Sadhukhan wrote:
>>
>> Hi Phil, All
>>
>> Please find modified webrev taking care of streamlining 
>> SwingInteropUtils class and handling of native window handle in 
>> LightweightFrameWrapper class by using JNI call in FX
>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/
>>
>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175
>>
>> Regards
>> Prasanta
>> On 5/30/2018 4:13 AM, Philip Race wrote:
>>> Some follow up comments.
>>>
>>> On 5/10/18, 5:49 PM, Philip Race wrote:
>>>> I've looked over the Swing code. No time to actually try it out so 
>>>> I can only comment on what I see.
>>>>
>>>> I am not sure what I think about class docs like "This class wraps 
>>>> <names internal interface> .."
>>>> I know no javadoc is generated but this module is exported and 
>>>> probably should say something
>>>> less specific.
>>>>
>>>> In general I really have to hold my nose when looking at this whole 
>>>> module and I
>>>> find it distasteful to endorse it.
>>>>
>>>> I really don't like all the things SwingInterOpUtils.java does.
>>>>
>>> Specific things we should look at in this file
>>> - getDefaultScaleX/Y .. JDK 9 will set a transform on the graphics that
>>> is passed to JComponent.paintComponent() .. so I wonder if we really
>>> need this internal API. I doubt any other code is updating the transform
>>> in a way that would make it a problem so the information you get 
>>> should be valid.
>>>
>>> The code to get the data array for the raster and associated information
>>> can be extracted via standard API like this :
>>>
>>> DataBuffer  db = BufferedImage.getRaster().getDataBuffer();
>>> if (db instanceof DataBufferInt) {
>>>  data = (DataBufferInt)db.getData();
>>> }
>>>
>>> So all of those can be fixed.
>>>
>>> The code that accepts a native window handle maybe should require it 
>>> is accessed via JNI ...
>>> It could still be unsupported, but it would be package private or 
>>> similar.
>>> If you have a native ID, then you are already using native code.
>>> This sidesteps any questions about the stability of such an API which
>>> accepts a native resource.
>>>
>>> The code that finds a component by location is probably harmless ...
>>>
>>> I'm less sure about the event posting and focus grabbing support.
>>> I'd like to have Sergey comment on those.
>>>
>>> the DnD code is too much for me to examine in detail.
>>>> I worry we are creating something we'll come to regret here.
>>>> The "unsupportedness" needs to be backed up by 
>>>> deprecated-for-removal being included
>>>> today so we can get rid of it the next release if we want to.
>>>
>>> I've looked at jdk.unsupported and they don't seem to have 
>>> deprecation tags so
>>> maybe that isn't an issue.
>>>
>>> -phil
>>>>
>>>> No @since tags anywhere....
>>>>
>>>> -phil.
>>>>
>>>> On 5/10/18, 8:32 AM, Kevin Rushforth wrote:
>>>>> I confirm that this fixes the issue. The interface change to make 
>>>>> the two static methods e instance methods is a good change in any 
>>>>> case.
>>>>>
>>>>> I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me.
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>> Hi Kevin,All,
>>>>>>
>>>>>> Please find the modified webrev fixing this #1 issue
>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.13/
>>>>>> via change in 
>>>>>> jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext 
>>>>>> and FXDnD.java#postDropTargetEvent
>>>>>>
>>>>>> For me, #2 works, #3 doesn't work even now due to JDK-8141391 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8141391> and #4 works 
>>>>>> for me.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 5/9/2018 11:29 PM, Kevin Rushforth wrote:
>>>>>>> Hi Prasanta,
>>>>>>>
>>>>>>> The API looks good now.
>>>>>>>
>>>>>>> All of our automated tests work (except for the ones with a 
>>>>>>> security manager due to JDK-8202451 
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8202451>).
>>>>>>>
>>>>>>> The only functional problem that I see is that Drag and Drop 
>>>>>>> onto a SwingNode doesn't work. We need to make sure that we test 
>>>>>>> the following four cases:
>>>>>>>
>>>>>>> 1. Drag / drop onto a Swing component in a SwingNode
>>>>>>> 2. Drag / drop from a Swing component in a SwingNode
>>>>>>> 3. Drag / drop onto a JavaFX control in a JFXPanel
>>>>>>> 4. Drag / drop from a JavaFX control in a JFXPanel
>>>>>>>
>>>>>>> So far I only tried the first one; the others still need to be 
>>>>>>> validated.
>>>>>>>
>>>>>>> -- Kevin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote:
>>>>>>>> Modified webrev to cater to this
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote:
>>>>>>>>> The following can also be abstract:
>>>>>>>>>
>>>>>>>>> LightweightContentWrapper:
>>>>>>>>>   getComponent, createDragGestureRecognizer, 
>>>>>>>>> createDragSourceContextPeer
>>>>>>>>>
>>>>>>>>> DropTargetContextWrapper:
>>>>>>>>>   getTargetActions, getDropTarget, getTransferDataFlavors, 
>>>>>>>>> getTransferable, isTransferableJVMLocal
>>>>>>>>>
>>>>>>>>> DispatcherWrapper:
>>>>>>>>>   isDispatchThread, createSecondaryLoop
>>>>>>>>>
>>>>>>>>> The rest looks good to me (although I still see two public 
>>>>>>>>> methods with "Peer" in the name, so Phil may want those renamed).
>>>>>>>>>
>>>>>>>>> -- Kevin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>> Modified webrev to cater to these 3 observations
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>>
>>>>>>>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
>>>>>>>>>>> The module definition for jdk.unsupported.desktop and the 
>>>>>>>>>>> changes to java.desktop look fine.
>>>>>>>>>>>
>>>>>>>>>>> In reviewing the jdk.swing.interop API, I have the following 
>>>>>>>>>>> suggestions / observations:
>>>>>>>>>>>
>>>>>>>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, 
>>>>>>>>>>> DropTargetContextWrapper, and LightweightContentWrapper can 
>>>>>>>>>>> all be abstract, along with most of the methods (rather than 
>>>>>>>>>>> having an empty body return value that is never used).
>>>>>>>>>>>
>>>>>>>>>>> 2. The addNotify method in LightweightFrameWrapper is 
>>>>>>>>>>> unused. Should be used somewhere? If not, then it can be 
>>>>>>>>>>> removed.
>>>>>>>>>>>
>>>>>>>>>>> The implementation of the new wrapper classes looks OK to me 
>>>>>>>>>>> with one observation that might or might not matter:
>>>>>>>>>>>
>>>>>>>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in 
>>>>>>>>>>> SwingInteropUtils) has changed in the case where the 
>>>>>>>>>>> Graphics is not an instance of SunGraphics2D. The former 
>>>>>>>>>>> behavior was to leave the instance variables X and Y 
>>>>>>>>>>> unchanged. The new behavior will set them back to 1.0. Maybe 
>>>>>>>>>>> this can't happen in practice, but it is something to consider.
>>>>>>>>>>>
>>>>>>>>>>> -- Kevin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote:
>>>>>>>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>> Modified webrev to rename to InteropProviderImpl
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/
>>>>>>>>>>>> This looks okay to me.
>>>>>>>>>>>>
>>>>>>>>>>>> -Alan
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>

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

From mandy.chung at oracle.com  Thu Jun 14 20:26:19 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 14 Jun 2018 13:26:19 -0700
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com>
 <a9af14aa-c92f-435e-57b2-5213f96f3431@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
Message-ID: <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>

I reviewed the module-info.java change.  @since 12 is missing in 
jdk.unsupported.desktop module-info.java

Otherwise it's fine.

Does the docs build exclude jdk.unsupported.desktop?  You might have 
confirmed that that I missed.

Mandy

On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote:
> Hi Phil, All
> 
> Please find modified webrev taking care of streamlining 
> SwingInteropUtils class and handling of native window handle in 
> LightweightFrameWrapper class by using JNI call in FX
> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/
> 
> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175
> 
> Regards
> Prasanta


From philip.race at oracle.com  Thu Jun 14 20:29:38 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 14 Jun 2018 13:29:38 -0700
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <a9af14aa-c92f-435e-57b2-5213f96f3431@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
 <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
Message-ID: <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com>

you surely mean
@since 11

I believe it has been verified that it is excluded from the docs build 
.. right Prasanta ?

-phil

On 06/14/2018 01:26 PM, mandy chung wrote:
> I reviewed the module-info.java change.  @since 12 is missing in 
> jdk.unsupported.desktop module-info.java
>
> Otherwise it's fine.
>
> Does the docs build exclude jdk.unsupported.desktop?  You might have 
> confirmed that that I missed.
>
> Mandy
>
> On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote:
>> Hi Phil, All
>>
>> Please find modified webrev taking care of streamlining 
>> SwingInteropUtils class and handling of native window handle in 
>> LightweightFrameWrapper class by using JNI call in FX
>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/
>>
>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175
>>
>> Regards
>> Prasanta



From mandy.chung at oracle.com  Thu Jun 14 20:45:35 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 14 Jun 2018 13:45:35 -0700
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
 <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
 <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com>
Message-ID: <0cf7246f-feae-3ef6-6923-8feb391b3b7f@oracle.com>



On 6/14/18 1:29 PM, Phil Race wrote:
> you surely mean
> @since 11

Oops typo. Yes @since 11

Mandy


From kevin.rushforth at oracle.com  Thu Jun 14 22:53:04 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 14 Jun 2018 15:53:04 -0700
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
 <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
 <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com>
Message-ID: <e14f8329-9026-78ed-a20e-de18ef2acde0@oracle.com>

I verified on an earlier version of the patch that it wasn't in the 
docs, but it would be good for Prasanta to double-check.

-- Kevin


On 6/14/2018 1:29 PM, Phil Race wrote:
> you surely mean
> @since 11
>
> I believe it has been verified that it is excluded from the docs build 
> .. right Prasanta ?
>
> -phil
>
> On 06/14/2018 01:26 PM, mandy chung wrote:
>> I reviewed the module-info.java change. @since 12 is missing in 
>> jdk.unsupported.desktop module-info.java
>>
>> Otherwise it's fine.
>>
>> Does the docs build exclude jdk.unsupported.desktop?? You might have 
>> confirmed that that I missed.
>>
>> Mandy
>>
>> On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote:
>>> Hi Phil, All
>>>
>>> Please find modified webrev taking care of streamlining 
>>> SwingInteropUtils class and handling of native window handle in 
>>> LightweightFrameWrapper class by using JNI call in FX
>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/
>>>
>>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175
>>>
>>> Regards
>>> Prasanta
>



From mandy.chung at oracle.com  Thu Jun 14 23:40:16 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 14 Jun 2018 16:40:16 -0700
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <e14f8329-9026-78ed-a20e-de18ef2acde0@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
 <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
 <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com>
 <e14f8329-9026-78ed-a20e-de18ef2acde0@oracle.com>
Message-ID: <362c8d68-30b8-5e0d-ae4d-6b8eafb8c29f@oracle.com>

Thanks for confirming that.

Mandy

On 6/14/18 3:53 PM, Kevin Rushforth wrote:
> I verified on an earlier version of the patch that it wasn't in the 
> docs, but it would be good for Prasanta to double-check.
> 
> -- Kevin
> 
> 
> On 6/14/2018 1:29 PM, Phil Race wrote:
>> you surely mean
>> @since 11
>>
>> I believe it has been verified that it is excluded from the docs build 
>> .. right Prasanta ?
>>
>> -phil
>>
>> On 06/14/2018 01:26 PM, mandy chung wrote:
>>> I reviewed the module-info.java change. @since 12 is missing in 
>>> jdk.unsupported.desktop module-info.java
>>>
>>> Otherwise it's fine.
>>>
>>> Does the docs build exclude jdk.unsupported.desktop?? You might have 
>>> confirmed that that I missed.
>>>
>>> Mandy
>>>
>>> On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote:
>>>> Hi Phil, All
>>>>
>>>> Please find modified webrev taking care of streamlining 
>>>> SwingInteropUtils class and handling of native window handle in 
>>>> LightweightFrameWrapper class by using JNI call in FX
>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/
>>>>
>>>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175
>>>>
>>>> Regards
>>>> Prasanta
>>
> 


From prasanta.sadhukhan at oracle.com  Fri Jun 15 07:31:17 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 15 Jun 2018 13:01:17 +0530
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <a9af14aa-c92f-435e-57b2-5213f96f3431@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
 <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
Message-ID: <a3258e61-bf78-91eb-5bce-bd8b40bd6d70@oracle.com>

Webrev to add @since 11 to jdk.swing.interop classes (only difference 
from .14)

http://cr.openjdk.java.net/~psadhukhan/fxswing.15/

I also tried submitting mach5 job from linux but it is failing to 
download jib (although I candownload from browser and ping 
java.se.oracle.com)
~/Downloads/mach5-1.0.1865-distribution/bin/mach5 --remote-build --email 
prasanta.sadhukhan at oracle.com
Mach 5 Health State: green

Creating job description... done
Creating build ID... 2018-06-15-0626444.prasanta.sadhukhan.open
Publishing source using JIB... 
[2018-06-15T06:26:42,870Z][INFO][main][c.o.j.s.c.SparkyClient] 
Downloading JIB bootstrap script
Failed to download 
https://java.se.oracle.com/artifactory/jdk-virtual/com/oracle/java/jib/jib/3.0-SNAPSHOT/jib-3.0-SNAPSHOT.jib.sh.gz

I am trying from windows but Phil told windows build does not probably 
built docs.
Are there any easier alternative to verify the doc build?

Regards
Prasanta
On 6/15/2018 1:56 AM, mandy chung wrote:
> I reviewed the module-info.java change.? @since 12 is missing in 
> jdk.unsupported.desktop module-info.java
>
> Otherwise it's fine.
>
> Does the docs build exclude jdk.unsupported.desktop?? You might have 
> confirmed that that I missed.
>
> Mandy
>
> On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote:
>> Hi Phil, All
>>
>> Please find modified webrev taking care of streamlining 
>> SwingInteropUtils class and handling of native window handle in 
>> LightweightFrameWrapper class by using JNI call in FX
>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/
>>
>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175
>>
>> Regards
>> Prasanta



From jayathirth.d.v at oracle.com  Fri Jun 15 08:21:32 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Fri, 15 Jun 2018 01:21:32 -0700 (PDT)
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <5B1DC954.3070908@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
 <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>
 <1cdaa1da-9954-f15d-c68a-2d07913c9f87@oracle.com>
 <cd672b2a-e801-8814-0c74-897359d2598b@oracle.com>
 <5B1B01C4.3050806@oracle.com>
 <e50f100f-7aef-71bd-e455-d0ce9ba56d49@oracle.com>
 <5B1DC954.3070908@oracle.com>
Message-ID: <ad70c1ca-b849-4eef-b71d-887cae08f08c@default>

Hello Phil & Prasanta,

Please find my observation:

I went through the history of webrev's to understand what we are trying to do with respect to "round" value.

It looks like the problem we have is : When we have floating point "view location" and "useFPAPI == true" whether to use round value as "true" or "false". 

I went through the logic of how round is used in Utilities.getTabbedTextOffset() and I agree with Phil's observation.

So I tried to find different use cases for "round" value:

1) In javax/swing/text/GlyphPainter1.getBoundedPosition() we call getTabbedTextOffset() with 
	a) floating values for viewLocation
	b) useFPAPI is true
	c) But "round" value is false.

2) In javax/swing/text/PlainView.viewToModel() we call getTabbedTextOffset() with
	a) one of viewLocation value is float(so by Widening conversion it will call getTabbedTextOffset(.. , .. , float, float, ....))
	b) useFPAPI is true
	c) But "round" value is true.

May be the difference in logic between above cases will help us to understand use case of "round" value and help us to decide "round value" in WrappedPlainView.java.

Thanks,
Jay

-----Original Message-----
From: Philip Race 
Sent: Monday, June 11, 2018 6:29 AM
To: Prasanta Sadhukhan
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in multiline text components on Windows with a screen resolution higher than 100%

FWIW I looked at this comment in the getTabbedTextOffset method
                 // the length of the string measured as a whole may differ from
                 // the sum of individual character lengths, for example if
                 // fractional metrics are enabled; and we must guard from this.

I am not really sure what the author was trying to say here.
Fractional Metrics is NOT the same thing as using floating point to measure width.
You will need floating point for fractional metrics .. but that makes it a necessary condition, not the same thing.

Also I looked at the rounding code

The logic for round==true seems to be trying to find the offset that is closest to the target position, so it may be less, the same or greater.

For round=false, it is trying to find the largest offset that does not exceed it.

I am not sure who would use the true case, but at least we can be consistent in using false in both cases.

+1

-phil.
-phil

On 6/10/18, 8:42 AM, Prasanta Sadhukhan wrote:
>
>
> On 6/9/2018 3:53 AM, Philip Race wrote:
>> The oddity about using round=true at line 845 is the other case seems 
>> to be using round == false ?
>>
>> I think round==false was intended for use with fractional metrics but 
>> it is not clear.
>>
> Seems logical.
> Modified webrev
> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.03/
>
> Regards
> Prasanta
>> -phil
>>
>> On 6/7/18, 4:12 AM, Prasanta Sadhukhan wrote:
>>> Updated webrev (as you pointed) to modify WrappedPlainView to use FP 
>>> version
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.02/
>>>
>>> I have used "round" to be true as
>>> public static final int getTabbedTextOffset(Segment s, FontMetrics 
>>> metrics,
>>>                                              int x0, int x, 
>>> TabExpander e,
>>>                                              int startOffset) { uses 
>>> "round" value as true.
>>> I did not find any other usage of this int version of the API other 
>>> than WrappedPlainView.
>>>
>>> static final int getTabbedTextOffset(View view, Segment s, 
>>> FontMetrics metrics,
>>>                                          int x0, int x, TabExpander e,
>>>                                          int startOffset,
>>>                                          int[] justificationData) {} 
>>> is used in GLyphPainter1#viewToModel but it was not needed for this 
>>> particular issue so I have not changed it for now.
>>>
>>> Regards
>>> Prasanta
>>> On 6/7/2018 3:33 AM, Phil Race wrote:
>>>> This is changing the internals of getTabbedTextOffset and using FP 
>>>> regardless of whether useFPAPI is true. This is not what I said.
>>>>
>>>> I wrote that you should call the FP version directly.
>>>>
>>>> Look at this
>>>> ---
>>>>      * @deprecated replaced by
>>>>      *     {@link #getTabbedTextOffset(Segment, FontMetrics, float, 
>>>> float,
>>>>      *                                 TabExpander, int, boolean)}
>>>>      */
>>>>     @Deprecated(since = "9")
>>>>     public static final int getTabbedTextOffset(Segment s, 
>>>> FontMetrics metrics,
>>>>                                              int x0, int x, 
>>>> TabExpander e,
>>>>                                              int startOffset) {
>>>>         return getTabbedTextOffset(s, metrics, x0, x, e, 
>>>> startOffset, true);
>>>> ----
>>>> If we had wanted what you proposed in the first webrev and I think 
>>>> this one is effectively same, we'd have altered the behaviour to 
>>>> and not deprecated and added new API
>>>>
>>>> So whatever code in our L&F is currently calling
>>>>
>>>> getTabbedTextOffset(Segment s,
>>>>                     FontMetrics metrics,
>>>>                     int x0, int x, TabExpander e,
>>>>                     int startOffset)
>>>>
>>>> should instead call
>>>>
>>>> getTabbedTextOffset(Segment s,
>>>>                     FontMetrics metrics,
>>>>                     float x0, float x, TabExpander e,
>>>>                     int startOffset,
>>>>                     boolean round)
>>>>
>>>> I am not sure if round should be true or false but calling the 
>>>> float version is the key.
>>>>
>>>> This (and no other change needed) does the trick for me :
>>>>
>>>> ---
>>>> a/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.
>>>> java
>>>>
>>>> +++ 
>>>> b/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.
>>>> java
>>>>
>>>> @@ -360,11 +360,11 @@
>>>>          int currentWidth = getWidth();
>>>>          if (wordWrap) {
>>>>              p = p0 + Utilities.getBreakLocation(segment, metrics,
>>>> -                                                tabBase, tabBase + 
>>>> currentWidth,
>>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>>>                                                  this, p0);
>>>>          } else {
>>>>              p = p0 + Utilities.getTabbedTextOffset(segment, metrics,
>>>> -                                                   tabBase, 
>>>> tabBase + currentWidth,
>>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>>>                                                     this, p0, false);
>>>>          }
>>>>          SegmentCache.releaseSharedSegment(segment);
>>>> @@ -847,8 +847,8 @@
>>>>                          Segment segment = 
>>>> SegmentCache.getSharedSegment();
>>>>                          loadText(segment, p0, p1);
>>>>                          int n =
>>>> Utilities.getTabbedTextOffset(segment, metrics,
>>>> -                                                   alloc.x, x,
>>>> - WrappedPlainView.this, p0);
>>>> + (float)(alloc.x), (float)x,
>>>> + WrappedPlainView.this, p0, false);
>>>> SegmentCache.releaseSharedSegment(segment);
>>>>                          return Math.min(p0 + n, p1 - 1);
>>>>                      }
>>>>
>>>> I may have missed something else but to verify I downloaded and 
>>>> used your test, which BTW has DOS line-endings !
>>>>
>>>> -phil.
>>>>
>>>> On 06/06/2018 12:04 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>>
>>>>> On 5/9/2018 12:41 AM, Phil Race wrote:
>>>>>> I am not sure this is the right fix.
>>>>>> If the intention had been to change all calls to
>>>>>> getTabbedTextOffset() to use the FP API it would have just been 
>>>>>> changed .. rather than adding a new API that provides the option 
>>>>>> to specify whether to use FP.
>>>>>>
>>>>>> So perhaps the problem is that internal code needs to be updated 
>>>>>> to call the FP version directly ..
>>>>> I have updated the internal code to use the FP version directly 
>>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.01/
>>>>> There are no new regressions in jtreg and jck tests.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>> I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992
>>>>>> to see
>>>>>> what was said there but JBS just went down for 5 hours 
>>>>>> maintenance ..
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> I have run javax/swing/text jtreg and jck tests and did not 
>>>>>>> observe any regressions.
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Prasanta.
>>>>>>>> Please confirm that you run related jck/reg tests.
>>>>>>>>
>>>>>>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review a fix for an issue where it is seen that,
>>>>>>>>>   with a screen resolution higher than 100% and then clicking 
>>>>>>>>> in a JTextArea having setLineWrap(true) set, the caret 
>>>>>>>>> (insertion point) is not aligned with the cursor.
>>>>>>>>>
>>>>>>>>> The issue seems to stem from the fact that caret position 
>>>>>>>>> calculation in DefaultCaret class utilises API that uses 
>>>>>>>>> integer calculation than floating point calculations.
>>>>>>>>> The code flow as seen is
>>>>>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.v
>>>>>>>>> iewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewTo
>>>>>>>>> Model=>Utilities.getTabbedOffset
>>>>>>>>>
>>>>>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which 
>>>>>>>>> uses integer arithmetic to get the caret position.
>>>>>>>>> The same getTabbedOffset uses Font.getStringBounds() which 
>>>>>>>>> uses floating point arithmetic via Rectangle2D.Float.
>>>>>>>>>
>>>>>>>>> Proposed fix is to make sure getTabbedOffset uses floating 
>>>>>>>>> point calculations by using getStringBounds() instead of
>>>>>>>>> charsWidth() so that it calculates the character width(s) of 
>>>>>>>>> text present in JTextArea in floating point to align the 
>>>>>>>>> caret.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>>>>>>> webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>


From prasanta.sadhukhan at oracle.com  Fri Jun 15 08:31:46 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 15 Jun 2018 14:01:46 +0530
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <ad70c1ca-b849-4eef-b71d-887cae08f08c@default>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
 <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>
 <1cdaa1da-9954-f15d-c68a-2d07913c9f87@oracle.com>
 <cd672b2a-e801-8814-0c74-897359d2598b@oracle.com>
 <5B1B01C4.3050806@oracle.com>
 <e50f100f-7aef-71bd-e455-d0ce9ba56d49@oracle.com>
 <5B1DC954.3070908@oracle.com> <ad70c1ca-b849-4eef-b71d-887cae08f08c@default>
Message-ID: <c35cdf4b-310f-abb6-e6a4-df5112b80751@oracle.com>

Hi Jay,


On 6/15/2018 1:51 PM, Jayathirth D V wrote:
> Hello Phil & Prasanta,
>
> Please find my observation:
>
> I went through the history of webrev's to understand what we are trying to do with respect to "round" value.
>
> It looks like the problem we have is : When we have floating point "view location" and "useFPAPI == true" whether to use round value as "true" or "false".
No, the problem is not that. The problem was in using the int version of 
getTabbedTextOffset api. The fix was to use the floating point version 
of getTabbedTextOffset() api instead of the int version.
We are just not sure whether to use round true or false for floating 
point getTabbledTextOffset() value but it does not affect this 
particular usecase/fix.

Regards
Prasanta
> I went through the logic of how round is used in Utilities.getTabbedTextOffset() and I agree with Phil's observation.
>
> So I tried to find different use cases for "round" value:
>
> 1) In javax/swing/text/GlyphPainter1.getBoundedPosition() we call getTabbedTextOffset() with
> 	a) floating values for viewLocation
> 	b) useFPAPI is true
> 	c) But "round" value is false.
>
> 2) In javax/swing/text/PlainView.viewToModel() we call getTabbedTextOffset() with
> 	a) one of viewLocation value is float(so by Widening conversion it will call getTabbedTextOffset(.. , .. , float, float, ....))
> 	b) useFPAPI is true
> 	c) But "round" value is true.
>
> May be the difference in logic between above cases will help us to understand use case of "round" value and help us to decide "round value" in WrappedPlainView.java.
>
> Thanks,
> Jay
>
> -----Original Message-----
> From: Philip Race
> Sent: Monday, June 11, 2018 6:29 AM
> To: Prasanta Sadhukhan
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in multiline text components on Windows with a screen resolution higher than 100%
>
> FWIW I looked at this comment in the getTabbedTextOffset method
>                   // the length of the string measured as a whole may differ from
>                   // the sum of individual character lengths, for example if
>                   // fractional metrics are enabled; and we must guard from this.
>
> I am not really sure what the author was trying to say here.
> Fractional Metrics is NOT the same thing as using floating point to measure width.
> You will need floating point for fractional metrics .. but that makes it a necessary condition, not the same thing.
>
> Also I looked at the rounding code
>
> The logic for round==true seems to be trying to find the offset that is closest to the target position, so it may be less, the same or greater.
>
> For round=false, it is trying to find the largest offset that does not exceed it.
>
> I am not sure who would use the true case, but at least we can be consistent in using false in both cases.
>
> +1
>
> -phil.
> -phil
>
> On 6/10/18, 8:42 AM, Prasanta Sadhukhan wrote:
>>
>> On 6/9/2018 3:53 AM, Philip Race wrote:
>>> The oddity about using round=true at line 845 is the other case seems
>>> to be using round == false ?
>>>
>>> I think round==false was intended for use with fractional metrics but
>>> it is not clear.
>>>
>> Seems logical.
>> Modified webrev
>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.03/
>>
>> Regards
>> Prasanta
>>> -phil
>>>
>>> On 6/7/18, 4:12 AM, Prasanta Sadhukhan wrote:
>>>> Updated webrev (as you pointed) to modify WrappedPlainView to use FP
>>>> version
>>>>
>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.02/
>>>>
>>>> I have used "round" to be true as
>>>> public static final int getTabbedTextOffset(Segment s, FontMetrics
>>>> metrics,
>>>>                                               int x0, int x,
>>>> TabExpander e,
>>>>                                               int startOffset) { uses
>>>> "round" value as true.
>>>> I did not find any other usage of this int version of the API other
>>>> than WrappedPlainView.
>>>>
>>>> static final int getTabbedTextOffset(View view, Segment s,
>>>> FontMetrics metrics,
>>>>                                           int x0, int x, TabExpander e,
>>>>                                           int startOffset,
>>>>                                           int[] justificationData) {}
>>>> is used in GLyphPainter1#viewToModel but it was not needed for this
>>>> particular issue so I have not changed it for now.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 6/7/2018 3:33 AM, Phil Race wrote:
>>>>> This is changing the internals of getTabbedTextOffset and using FP
>>>>> regardless of whether useFPAPI is true. This is not what I said.
>>>>>
>>>>> I wrote that you should call the FP version directly.
>>>>>
>>>>> Look at this
>>>>> ---
>>>>>       * @deprecated replaced by
>>>>>       *     {@link #getTabbedTextOffset(Segment, FontMetrics, float,
>>>>> float,
>>>>>       *                                 TabExpander, int, boolean)}
>>>>>       */
>>>>>      @Deprecated(since = "9")
>>>>>      public static final int getTabbedTextOffset(Segment s,
>>>>> FontMetrics metrics,
>>>>>                                               int x0, int x,
>>>>> TabExpander e,
>>>>>                                               int startOffset) {
>>>>>          return getTabbedTextOffset(s, metrics, x0, x, e,
>>>>> startOffset, true);
>>>>> ----
>>>>> If we had wanted what you proposed in the first webrev and I think
>>>>> this one is effectively same, we'd have altered the behaviour to
>>>>> and not deprecated and added new API
>>>>>
>>>>> So whatever code in our L&F is currently calling
>>>>>
>>>>> getTabbedTextOffset(Segment s,
>>>>>                      FontMetrics metrics,
>>>>>                      int x0, int x, TabExpander e,
>>>>>                      int startOffset)
>>>>>
>>>>> should instead call
>>>>>
>>>>> getTabbedTextOffset(Segment s,
>>>>>                      FontMetrics metrics,
>>>>>                      float x0, float x, TabExpander e,
>>>>>                      int startOffset,
>>>>>                      boolean round)
>>>>>
>>>>> I am not sure if round should be true or false but calling the
>>>>> float version is the key.
>>>>>
>>>>> This (and no other change needed) does the trick for me :
>>>>>
>>>>> ---
>>>>> a/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.
>>>>> java
>>>>>
>>>>> +++
>>>>> b/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.
>>>>> java
>>>>>
>>>>> @@ -360,11 +360,11 @@
>>>>>           int currentWidth = getWidth();
>>>>>           if (wordWrap) {
>>>>>               p = p0 + Utilities.getBreakLocation(segment, metrics,
>>>>> -                                                tabBase, tabBase +
>>>>> currentWidth,
>>>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>>>>                                                   this, p0);
>>>>>           } else {
>>>>>               p = p0 + Utilities.getTabbedTextOffset(segment, metrics,
>>>>> -                                                   tabBase,
>>>>> tabBase + currentWidth,
>>>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>>>>                                                      this, p0, false);
>>>>>           }
>>>>>           SegmentCache.releaseSharedSegment(segment);
>>>>> @@ -847,8 +847,8 @@
>>>>>                           Segment segment =
>>>>> SegmentCache.getSharedSegment();
>>>>>                           loadText(segment, p0, p1);
>>>>>                           int n =
>>>>> Utilities.getTabbedTextOffset(segment, metrics,
>>>>> -                                                   alloc.x, x,
>>>>> - WrappedPlainView.this, p0);
>>>>> + (float)(alloc.x), (float)x,
>>>>> + WrappedPlainView.this, p0, false);
>>>>> SegmentCache.releaseSharedSegment(segment);
>>>>>                           return Math.min(p0 + n, p1 - 1);
>>>>>                       }
>>>>>
>>>>> I may have missed something else but to verify I downloaded and
>>>>> used your test, which BTW has DOS line-endings !
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 06/06/2018 12:04 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>> On 5/9/2018 12:41 AM, Phil Race wrote:
>>>>>>> I am not sure this is the right fix.
>>>>>>> If the intention had been to change all calls to
>>>>>>> getTabbedTextOffset() to use the FP API it would have just been
>>>>>>> changed .. rather than adding a new API that provides the option
>>>>>>> to specify whether to use FP.
>>>>>>>
>>>>>>> So perhaps the problem is that internal code needs to be updated
>>>>>>> to call the FP version directly ..
>>>>>> I have updated the internal code to use the FP version directly
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.01/
>>>>>> There are no new regressions in jtreg and jck tests.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>>> I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992
>>>>>>> to see
>>>>>>> what was said there but JBS just went down for 5 hours
>>>>>>> maintenance ..
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> I have run javax/swing/text jtreg and jck tests and did not
>>>>>>>> observe any regressions.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>>>>>>>> Hi, Prasanta.
>>>>>>>>> Please confirm that you run related jck/reg tests.
>>>>>>>>>
>>>>>>>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review a fix for an issue where it is seen that,
>>>>>>>>>>    with a screen resolution higher than 100% and then clicking
>>>>>>>>>> in a JTextArea having setLineWrap(true) set, the caret
>>>>>>>>>> (insertion point) is not aligned with the cursor.
>>>>>>>>>>
>>>>>>>>>> The issue seems to stem from the fact that caret position
>>>>>>>>>> calculation in DefaultCaret class utilises API that uses
>>>>>>>>>> integer calculation than floating point calculations.
>>>>>>>>>> The code flow as seen is
>>>>>>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.v
>>>>>>>>>> iewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewTo
>>>>>>>>>> Model=>Utilities.getTabbedOffset
>>>>>>>>>>
>>>>>>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which
>>>>>>>>>> uses integer arithmetic to get the caret position.
>>>>>>>>>> The same getTabbedOffset uses Font.getStringBounds() which
>>>>>>>>>> uses floating point arithmetic via Rectangle2D.Float.
>>>>>>>>>>
>>>>>>>>>> Proposed fix is to make sure getTabbedOffset uses floating
>>>>>>>>>> point calculations by using getStringBounds() instead of
>>>>>>>>>> charsWidth() so that it calculates the character width(s) of
>>>>>>>>>> text present in JTextArea in floating point to align the
>>>>>>>>>> caret.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>>>>>>>> webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>



From jayathirth.d.v at oracle.com  Fri Jun 15 08:46:32 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Fri, 15 Jun 2018 01:46:32 -0700 (PDT)
Subject: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in
 multiline text components on Windows with a screen resolution higher than
 100%
In-Reply-To: <c35cdf4b-310f-abb6-e6a4-df5112b80751@oracle.com>
References: <bf7da92d-6370-4b9e-f6de-2d6b672586c4@oracle.com>
 <f7972cca-5499-1e4f-03a5-3a52a742eaca@oracle.com>
 <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com>
 <da0d0b55-12a3-6418-1da3-2d2a333c4fc3@oracle.com>
 <6343c2fc-6e85-441a-199b-afb843079192@oracle.com>
 <1cdaa1da-9954-f15d-c68a-2d07913c9f87@oracle.com>
 <cd672b2a-e801-8814-0c74-897359d2598b@oracle.com>
 <5B1B01C4.3050806@oracle.com>
 <e50f100f-7aef-71bd-e455-d0ce9ba56d49@oracle.com>
 <5B1DC954.3070908@oracle.com> <ad70c1ca-b849-4eef-b71d-887cae08f08c@default>
 <c35cdf4b-310f-abb6-e6a4-df5112b80751@oracle.com>
Message-ID: <13fbd2b4-9319-4226-b65b-8f17f5008900@default>

Hi Prasanta,

I understand that the main problem was to use int/float version of getTabbedTextOffset api and not usage of "round". That is why I mentioned in previous mail : " I went through the history of webrev's to understand what we are trying to do with respect to "round" value."

I don?t have full idea about all the API"S present in swing/text that?s why I went through usage of "round" when we call getTabbedTextOffset() from different places.
If you are sure that usage of "round" doesn?t affect the final fix then the changes are fine.

Thanks,
Jay
 
-----Original Message-----
From: Prasanta Sadhukhan 
Sent: Friday, June 15, 2018 2:02 PM
To: Jayathirth D V; Philip Race
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position in multiline text components on Windows with a screen resolution higher than 100%

Hi Jay,


On 6/15/2018 1:51 PM, Jayathirth D V wrote:
> Hello Phil & Prasanta,
>
> Please find my observation:
>
> I went through the history of webrev's to understand what we are trying to do with respect to "round" value.
>
> It looks like the problem we have is : When we have floating point "view location" and "useFPAPI == true" whether to use round value as "true" or "false".
No, the problem is not that. The problem was in using the int version of getTabbedTextOffset api. The fix was to use the floating point version of getTabbedTextOffset() api instead of the int version.
We are just not sure whether to use round true or false for floating point getTabbledTextOffset() value but it does not affect this particular usecase/fix.

Regards
Prasanta
> I went through the logic of how round is used in Utilities.getTabbedTextOffset() and I agree with Phil's observation.
>
> So I tried to find different use cases for "round" value:
>
> 1) In javax/swing/text/GlyphPainter1.getBoundedPosition() we call getTabbedTextOffset() with
> 	a) floating values for viewLocation
> 	b) useFPAPI is true
> 	c) But "round" value is false.
>
> 2) In javax/swing/text/PlainView.viewToModel() we call getTabbedTextOffset() with
> 	a) one of viewLocation value is float(so by Widening conversion it will call getTabbedTextOffset(.. , .. , float, float, ....))
> 	b) useFPAPI is true
> 	c) But "round" value is true.
>
> May be the difference in logic between above cases will help us to understand use case of "round" value and help us to decide "round value" in WrappedPlainView.java.
>
> Thanks,
> Jay
>
> -----Original Message-----
> From: Philip Race
> Sent: Monday, June 11, 2018 6:29 AM
> To: Prasanta Sadhukhan
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] RFR: JDK-8199441: Wrong caret position 
> in multiline text components on Windows with a screen resolution 
> higher than 100%
>
> FWIW I looked at this comment in the getTabbedTextOffset method
>                   // the length of the string measured as a whole may differ from
>                   // the sum of individual character lengths, for example if
>                   // fractional metrics are enabled; and we must guard from this.
>
> I am not really sure what the author was trying to say here.
> Fractional Metrics is NOT the same thing as using floating point to measure width.
> You will need floating point for fractional metrics .. but that makes it a necessary condition, not the same thing.
>
> Also I looked at the rounding code
>
> The logic for round==true seems to be trying to find the offset that is closest to the target position, so it may be less, the same or greater.
>
> For round=false, it is trying to find the largest offset that does not exceed it.
>
> I am not sure who would use the true case, but at least we can be consistent in using false in both cases.
>
> +1
>
> -phil.
> -phil
>
> On 6/10/18, 8:42 AM, Prasanta Sadhukhan wrote:
>>
>> On 6/9/2018 3:53 AM, Philip Race wrote:
>>> The oddity about using round=true at line 845 is the other case 
>>> seems to be using round == false ?
>>>
>>> I think round==false was intended for use with fractional metrics 
>>> but it is not clear.
>>>
>> Seems logical.
>> Modified webrev
>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.03/
>>
>> Regards
>> Prasanta
>>> -phil
>>>
>>> On 6/7/18, 4:12 AM, Prasanta Sadhukhan wrote:
>>>> Updated webrev (as you pointed) to modify WrappedPlainView to use 
>>>> FP version
>>>>
>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.02/
>>>>
>>>> I have used "round" to be true as
>>>> public static final int getTabbedTextOffset(Segment s, FontMetrics 
>>>> metrics,
>>>>                                               int x0, int x, 
>>>> TabExpander e,
>>>>                                               int startOffset) { 
>>>> uses "round" value as true.
>>>> I did not find any other usage of this int version of the API other 
>>>> than WrappedPlainView.
>>>>
>>>> static final int getTabbedTextOffset(View view, Segment s, 
>>>> FontMetrics metrics,
>>>>                                           int x0, int x, TabExpander e,
>>>>                                           int startOffset,
>>>>                                           int[] justificationData) 
>>>> {} is used in GLyphPainter1#viewToModel but it was not needed for 
>>>> this particular issue so I have not changed it for now.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 6/7/2018 3:33 AM, Phil Race wrote:
>>>>> This is changing the internals of getTabbedTextOffset and using FP 
>>>>> regardless of whether useFPAPI is true. This is not what I said.
>>>>>
>>>>> I wrote that you should call the FP version directly.
>>>>>
>>>>> Look at this
>>>>> ---
>>>>>       * @deprecated replaced by
>>>>>       *     {@link #getTabbedTextOffset(Segment, FontMetrics, float,
>>>>> float,
>>>>>       *                                 TabExpander, int, boolean)}
>>>>>       */
>>>>>      @Deprecated(since = "9")
>>>>>      public static final int getTabbedTextOffset(Segment s, 
>>>>> FontMetrics metrics,
>>>>>                                               int x0, int x, 
>>>>> TabExpander e,
>>>>>                                               int startOffset) {
>>>>>          return getTabbedTextOffset(s, metrics, x0, x, e, 
>>>>> startOffset, true);
>>>>> ----
>>>>> If we had wanted what you proposed in the first webrev and I think 
>>>>> this one is effectively same, we'd have altered the behaviour to 
>>>>> and not deprecated and added new API
>>>>>
>>>>> So whatever code in our L&F is currently calling
>>>>>
>>>>> getTabbedTextOffset(Segment s,
>>>>>                      FontMetrics metrics,
>>>>>                      int x0, int x, TabExpander e,
>>>>>                      int startOffset)
>>>>>
>>>>> should instead call
>>>>>
>>>>> getTabbedTextOffset(Segment s,
>>>>>                      FontMetrics metrics,
>>>>>                      float x0, float x, TabExpander e,
>>>>>                      int startOffset,
>>>>>                      boolean round)
>>>>>
>>>>> I am not sure if round should be true or false but calling the 
>>>>> float version is the key.
>>>>>
>>>>> This (and no other change needed) does the trick for me :
>>>>>
>>>>> ---
>>>>> a/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.
>>>>> java
>>>>>
>>>>> +++
>>>>> b/src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.
>>>>> java
>>>>>
>>>>> @@ -360,11 +360,11 @@
>>>>>           int currentWidth = getWidth();
>>>>>           if (wordWrap) {
>>>>>               p = p0 + Utilities.getBreakLocation(segment, metrics,
>>>>> -                                                tabBase, tabBase +
>>>>> currentWidth,
>>>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>>>>                                                   this, p0);
>>>>>           } else {
>>>>>               p = p0 + Utilities.getTabbedTextOffset(segment, metrics,
>>>>> -                                                   tabBase,
>>>>> tabBase + currentWidth,
>>>>> + (float)tabBase, (float)(tabBase + currentWidth),
>>>>>                                                      this, p0, false);
>>>>>           }
>>>>>           SegmentCache.releaseSharedSegment(segment);
>>>>> @@ -847,8 +847,8 @@
>>>>>                           Segment segment = 
>>>>> SegmentCache.getSharedSegment();
>>>>>                           loadText(segment, p0, p1);
>>>>>                           int n =
>>>>> Utilities.getTabbedTextOffset(segment, metrics,
>>>>> -                                                   alloc.x, x,
>>>>> - WrappedPlainView.this, p0);
>>>>> + (float)(alloc.x), (float)x,
>>>>> + WrappedPlainView.this, p0, false);
>>>>> SegmentCache.releaseSharedSegment(segment);
>>>>>                           return Math.min(p0 + n, p1 - 1);
>>>>>                       }
>>>>>
>>>>> I may have missed something else but to verify I downloaded and 
>>>>> used your test, which BTW has DOS line-endings !
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 06/06/2018 12:04 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>> On 5/9/2018 12:41 AM, Phil Race wrote:
>>>>>>> I am not sure this is the right fix.
>>>>>>> If the intention had been to change all calls to
>>>>>>> getTabbedTextOffset() to use the FP API it would have just been 
>>>>>>> changed .. rather than adding a new API that provides the option 
>>>>>>> to specify whether to use FP.
>>>>>>>
>>>>>>> So perhaps the problem is that internal code needs to be updated 
>>>>>>> to call the FP version directly ..
>>>>>> I have updated the internal code to use the FP version directly 
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.01/
>>>>>> There are no new regressions in jtreg and jck tests.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>>> I'd like to read 
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8168992
>>>>>>> to see
>>>>>>> what was said there but JBS just went down for 5 hours 
>>>>>>> maintenance ..
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote:
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> I have run javax/swing/text jtreg and jck tests and did not 
>>>>>>>> observe any regressions.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 4/28/2018 5:38 AM, Sergey Bylokhov wrote:
>>>>>>>>> Hi, Prasanta.
>>>>>>>>> Please confirm that you run related jck/reg tests.
>>>>>>>>>
>>>>>>>>> On 26/04/2018 23:52, Prasanta Sadhukhan wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review a fix for an issue where it is seen that,
>>>>>>>>>>    with a screen resolution higher than 100% and then 
>>>>>>>>>> clicking in a JTextArea having setLineWrap(true) set, the 
>>>>>>>>>> caret (insertion point) is not aligned with the cursor.
>>>>>>>>>>
>>>>>>>>>> The issue seems to stem from the fact that caret position 
>>>>>>>>>> calculation in DefaultCaret class utilises API that uses 
>>>>>>>>>> integer calculation than floating point calculations.
>>>>>>>>>> The code flow as seen is
>>>>>>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.
>>>>>>>>>> v 
>>>>>>>>>> iewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewT
>>>>>>>>>> o Model=>Utilities.getTabbedOffset
>>>>>>>>>>
>>>>>>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which 
>>>>>>>>>> uses integer arithmetic to get the caret position.
>>>>>>>>>> The same getTabbedOffset uses Font.getStringBounds() which 
>>>>>>>>>> uses floating point arithmetic via Rectangle2D.Float.
>>>>>>>>>>
>>>>>>>>>> Proposed fix is to make sure getTabbedOffset uses floating 
>>>>>>>>>> point calculations by using getStringBounds() instead of
>>>>>>>>>> charsWidth() so that it calculates the character width(s) of 
>>>>>>>>>> text present in JTextArea in floating point to align the 
>>>>>>>>>> caret.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199441
>>>>>>>>>> webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>



From prasanta.sadhukhan at oracle.com  Fri Jun 15 12:42:29 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 15 Jun 2018 18:12:29 +0530
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <a3258e61-bf78-91eb-5bce-bd8b40bd6d70@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
 <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
 <a3258e61-bf78-91eb-5bce-bd8b40bd6d70@oracle.com>
Message-ID: <18ab9791-480a-7c48-6d0e-fc3a471f2197@oracle.com>



On 6/15/2018 1:01 PM, Prasanta Sadhukhan wrote:
> Webrev to add @since 11 to jdk.swing.interop classes (only difference 
> from .14)
>
> http://cr.openjdk.java.net/~psadhukhan/fxswing.15/
>
> I also tried submitting mach5 job from linux but it is failing to 
> download jib (although I candownload from browser and ping 
> java.se.oracle.com)
> ~/Downloads/mach5-1.0.1865-distribution/bin/mach5 --remote-build 
> --email prasanta.sadhukhan at oracle.com
> Mach 5 Health State: green
>
> Creating job description... done
> Creating build ID... 2018-06-15-0626444.prasanta.sadhukhan.open
> Publishing source using JIB... 
> [2018-06-15T06:26:42,870Z][INFO][main][c.o.j.s.c.SparkyClient] 
> Downloading JIB bootstrap script
>
>
> I am trying from windows but Phil told windows build does not probably 
> built docs.
> Are there any easier alternative to verify the doc build?
>
I confirm jdk.unsupported.desktop is not present in doc build.

Regards
Prasanta
> Regards
> Prasanta
> On 6/15/2018 1:56 AM, mandy chung wrote:
>> I reviewed the module-info.java change. @since 12 is missing in 
>> jdk.unsupported.desktop module-info.java
>>
>> Otherwise it's fine.
>>
>> Does the docs build exclude jdk.unsupported.desktop?? You might have 
>> confirmed that that I missed.
>>
>> Mandy
>>
>> On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote:
>>> Hi Phil, All
>>>
>>> Please find modified webrev taking care of streamlining 
>>> SwingInteropUtils class and handling of native window handle in 
>>> LightweightFrameWrapper class by using JNI call in FX
>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/
>>>
>>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175
>>>
>>> Regards
>>> Prasanta
>



From mandy.chung at oracle.com  Fri Jun 15 13:56:38 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 15 Jun 2018 06:56:38 -0700
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <18ab9791-480a-7c48-6d0e-fc3a471f2197@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
 <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
 <a3258e61-bf78-91eb-5bce-bd8b40bd6d70@oracle.com>
 <18ab9791-480a-7c48-6d0e-fc3a471f2197@oracle.com>
Message-ID: <9aa7d562-e51b-0061-895d-d0b7df7a4fa6@oracle.com>

Great!  Thanks Prasanta.

Mandy

On 6/15/18 5:42 AM, Prasanta Sadhukhan wrote:
> I confirm jdk.unsupported.desktop is not present in doc build.
> 
> Regards
> Prasanta


From philip.race at oracle.com  Fri Jun 15 17:26:33 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 15 Jun 2018 10:26:33 -0700
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <a3258e61-bf78-91eb-5bce-bd8b40bd6d70@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
 <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
 <a3258e61-bf78-91eb-5bce-bd8b40bd6d70@oracle.com>
Message-ID: <cc48f42e-c9d7-8e0d-32ca-b538a36ef153@oracle.com>

+1

-phil.

On 06/15/2018 12:31 AM, Prasanta Sadhukhan wrote:
> Webrev to add @since 11 to jdk.swing.interop classes (only difference 
> from .14)
>
> http://cr.openjdk.java.net/~psadhukhan/fxswing.15/
>
> I also tried submitting mach5 job from linux but it is failing to 
> download jib (although I candownload from browser and ping 
> java.se.oracle.com)
> ~/Downloads/mach5-1.0.1865-distribution/bin/mach5 --remote-build 
> --email prasanta.sadhukhan at oracle.com
> Mach 5 Health State: green
>
> Creating job description... done
> Creating build ID... 2018-06-15-0626444.prasanta.sadhukhan.open
> Publishing source using JIB... 
> [2018-06-15T06:26:42,870Z][INFO][main][c.o.j.s.c.SparkyClient] 
> Downloading JIB bootstrap script
> Failed to download 
> https://java.se.oracle.com/artifactory/jdk-virtual/com/oracle/java/jib/jib/3.0-SNAPSHOT/jib-3.0-SNAPSHOT.jib.sh.gz
>
> I am trying from windows but Phil told windows build does not probably 
> built docs.
> Are there any easier alternative to verify the doc build?
>
> Regards
> Prasanta
> On 6/15/2018 1:56 AM, mandy chung wrote:
>> I reviewed the module-info.java change. @since 12 is missing in 
>> jdk.unsupported.desktop module-info.java
>>
>> Otherwise it's fine.
>>
>> Does the docs build exclude jdk.unsupported.desktop?  You might have 
>> confirmed that that I missed.
>>
>> Mandy
>>
>> On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote:
>>> Hi Phil, All
>>>
>>> Please find modified webrev taking care of streamlining 
>>> SwingInteropUtils class and handling of native window handle in 
>>> LightweightFrameWrapper class by using JNI call in FX
>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/
>>>
>>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175
>>>
>>> Regards
>>> Prasanta
>



From mandy.chung at oracle.com  Fri Jun 15 17:44:09 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 15 Jun 2018 10:44:09 -0700
Subject: <Swing Dev> [11] RFR JDK-8202199 : Provide public,
 unsupported API for FX Swing interop
In-Reply-To: <a3258e61-bf78-91eb-5bce-bd8b40bd6d70@oracle.com>
References: <ded53e25-0a86-a8a8-03b9-56c2d5dc9abf@oracle.com>
 <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com>
 <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com>
 <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com>
 <16531321-7d15-00bf-0460-aee6290d626c@oracle.com>
 <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com>
 <d21826c7-0a23-172a-39be-3cc3c893c23c@oracle.com>
 <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com>
 <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com>
 <d615349d-5856-0dbe-da4c-347a4930c7b3@oracle.com>
 <b3714b87-eeae-29ee-0c9a-6a83cc41cead@oracle.com>
 <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com>
 <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com>
 <bc3b6dd5-6ae2-acaa-81f0-7eef168f271d@oracle.com>
 <fe5995d5-d8ed-6492-a1f2-3d242424b06f@oracle.com> <5AF4E8AF.60202@oracle.com>
 <5B0DD789.8000809@oracle.com>
 <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com>
 <f973dbe4-54b7-a9f1-3611-a600f69ee91f@oracle.com>
 <a3258e61-bf78-91eb-5bce-bd8b40bd6d70@oracle.com>
Message-ID: <784b42d4-549d-c512-8a51-8ff0ec17f2bb@oracle.com>



On 6/15/18 12:31 AM, Prasanta Sadhukhan wrote:
> Webrev to add @since 11 to jdk.swing.interop classes (only difference 
> from .14)
> 
> http://cr.openjdk.java.net/~psadhukhan/fxswing.15/

+1

Mandy


From Sergey.Bylokhov at oracle.com  Sat Jun 16 06:31:37 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Jun 2018 23:31:37 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in "Classical"
 label in SwingSet2 demo with Windows L&F at Hidpi
Message-ID: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>

Hello.
Please review the fix for jdk11.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/

Short description:
This fix enhance implementation of JDK-8178025[1] for most of our Swing 
components. The main rule which I tried to follow:
"If layout of the component depends from the font then it should depend 
on the current graphics configuration as well, because FontMetrics 
depends on graphics configuration".

Long description:
The fix for JDK-8178025 added a special property "graphicsConfiguration" 
which: fired when the graphicsConfiguration is changed from one non-null 
value to another non-null value.
Those fix also updated some of the components(to refresh/re-validate its 
states when the "graphicsConfiguration" or "ancestor" were changed).

The usage of "ancestor" was not obvious, so I modify the code to fire 
"graphicsConfiguration" every time, this cover a situation when the 
"GC=null" is changed to "GC=non-null"(previously it was covered by 
"ancestor" property). So after this fix our components will listen only 
"font" and "graphicsConfiguration".

In implementation of JDK-8178025 the "graphicsConfiguration" is fired 
immediately after GC is changed, it caused the issues in some containers 
like JTree. When the container get such notification it usually tries to 
get some information from children, but in this moment children had 
previous graphic config, so the result calculated(and usually cached) in 
the container was wrong. In this fix I changed implementation of this 
property. Now it will fired only when the container and all its children 
are updated.

===
Note that the new test StalePreferredSize.java has a TODO block. Because 
JSpinner does not work properly even after the current fix. The reason 
is that during validation it is unexpectedly change the font from normal 
to bold(I'll fix this in a separate bug)


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

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Sun Jun 17 22:37:00 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 17 Jun 2018 15:37:00 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in
 "Classical" label in SwingSet2 demo with Windows L&F at Hidpi
In-Reply-To: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
References: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
Message-ID: <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>

Unfortunately after additional testing I found a bug in our text related 
components. In the JTextPane the text looks broken if we request some 
change in the component after it is became visible.

For example if we change the font then the text will be overlapping. So 
if I will be applied this fix, which will force text component to 
relayout(because of the change in graphics config), then the text will 
be broken from the beginning.

But before the fix it will be broken only if the application will change 
the pane after it became visible(BTW text rendering during editing is 
broken in both cases).

So I temporary reverted the changes in the text related components:
http://cr.openjdk.java.net/~serb/8201552/webrev.02

Two follow bugs were created:
  - Text components: https://bugs.openjdk.java.net/browse/JDK-8205143
  - JSpinner: https://bugs.openjdk.java.net/browse/JDK-8205144

On 15/06/2018 23:31, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
> Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/
> 
> Short description:
> This fix enhance implementation of JDK-8178025[1] for most of our Swing 
> components. The main rule which I tried to follow:
> "If layout of the component depends from the font then it should depend 
> on the current graphics configuration as well, because FontMetrics 
> depends on graphics configuration".
> 
> Long description:
> The fix for JDK-8178025 added a special property "graphicsConfiguration" 
> which: fired when the graphicsConfiguration is changed from one non-null 
> value to another non-null value.
> Those fix also updated some of the components(to refresh/re-validate its 
> states when the "graphicsConfiguration" or "ancestor" were changed).
> 
> The usage of "ancestor" was not obvious, so I modify the code to fire 
> "graphicsConfiguration" every time, this cover a situation when the 
> "GC=null" is changed to "GC=non-null"(previously it was covered by 
> "ancestor" property). So after this fix our components will listen only 
> "font" and "graphicsConfiguration".
> 
> In implementation of JDK-8178025 the "graphicsConfiguration" is fired 
> immediately after GC is changed, it caused the issues in some containers 
> like JTree. When the container get such notification it usually tries to 
> get some information from children, but in this moment children had 
> previous graphic config, so the result calculated(and usually cached) in 
> the container was wrong. In this fix I changed implementation of this 
> property. Now it will fired only when the container and all its children 
> are updated.
> 
> ===
> Note that the new test StalePreferredSize.java has a TODO block. Because 
> JSpinner does not work properly even after the current fix. The reason 
> is that during validation it is unexpectedly change the font from normal 
> to bold(I'll fix this in a separate bug)
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8178025
> 


-- 
Best regards, Sergey.


From shashidhara.veerabhadraiah at oracle.com  Wed Jun 20 10:12:03 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Wed, 20 Jun 2018 03:12:03 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8153732: Windows remote printer changes do not
 reflect in lookupPrintServices()
Message-ID: <afa12391-489d-4997-b2b8-9925a36cf756@default>

Hi All, Please review this code changes for the below enhancement.

 

Enhancement: https://bugs.openjdk.java.net/browse/JDK-8153732

 

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8153732/webrev.00/

 

Details of the changes: Windows provides *PrinterChangeNotification* functions that provides information about printer status changes of the local printers(subset) but not network printers. 
Alternatively, Windows provides a way thro' which one can get the network printer status changes by using WMI, RegistryKeyChange combination, which is a slightly complex mechanism. 
The Windows WMI offers an async and sync method to read thro' registry via the WQL query. The async method is considered dangerous as it leaves open a channel until we close it. But the async method has the advantage of being notified of a change in registry by calling callback without polling for it. The sync method uses the polling mechanism to notify. 
RegistryValueChange cannot be used in combination with WMI to get registry value change notification because of an error that may be generated because the scope of the query would be too big to handle(at times). 
Hence an alternative mechanism is choosen via the EnumPrinters by polling for the count of printer status changes(add\remove) and based on it update the printers list(both local and remote printers - superset).

 

Thanks and regards,

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

From pankaj.b.bansal at oracle.com  Wed Jun 20 14:52:44 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 20 Jun 2018 07:52:44 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
 <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>
 <42a16319-9b11-45b8-b429-46bc90fb0c5c@default>
 <CAM6ZMz_a=92wmpw9QE1WS0U9d8f1OjjhkidbrvVBGHVVkrTrXg@mail.gmail.com>
 <ffd3977e-5944-4911-8e17-75d3f1ee2900@default>
 <dcb9b0f3-2839-ce12-d43d-3ef9c1823014@oracle.com>
 <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default>
 <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
Message-ID: <caf48671-8e20-4d19-9962-7f58e342408c@default>

Hi Prasanta,

I looked at documentation of KeyStroke.getKeyStroke and InputEvent.ALT_MASK should be used instead of ActionEvent.ALT_MASK. The corresponding InputEvent.ALT_GRAPH_MASK is already present. I used it by mistake last time.
I have made changes for JMenuItem I have changed BasicJMenuItemUI for JMenuItem and updated the test case too. Other changes are same as webrev.02. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.03/


Regards,
Pankaj Bansal

-----Original Message-----
From: Prasanta Sadhukhan 
Sent: Friday, April 20, 2018 5:04 PM
To: Pankaj Bansal
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components

Hi Pankaj,


On 4/20/2018 3:48 PM, Pankaj Bansal wrote:
> Hi Prasanta,
>
> In case of JMenuItem, there are two ways to add key shortcuts
>
> 1.
> JMenuItem newMenuItem = new JMenuItem("New");
>   newMenuItem.setMnemonic(KeyEvent.VK_N);
> In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded.
>
> 2.
> JMenuItem newMenuItem = new JMenuItem("New"); 
> newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N, 
> ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded  in this case.
But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH.

Regards
Prasanta
> Please let me know what do you think about this.
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Thursday, April 19, 2018 12:41 PM
> To: Pankaj Bansal; Andrej Golovnin
> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
> longer work in Swing components
>
> Hi Pankaj,
>
> looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works?
>
> Regards
> Prasanta
> On 4/10/2018 3:15 PM, Pankaj Bansal wrote:
>> Hello Andrej,
>>
>> Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out.
>> Webrev:
>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/
>>
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
>> Sent: Tuesday, April 10, 2018 2:18 PM
>> To: Pankaj Bansal
>> Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
>> longer work in Swing components
>>
>> Hi Pankaj,
>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/
>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>
>> 3540         BOOL altIsDown = ((modifiers &
>> java_awt_event_InputEvent_ALT_DOWN_MASK) ||
>> 3541                             (modifiers &
>> java_awt_event_InputEvent_ALT_DOWN_MASK));
>>
>> Applying '||' on the same value does not make sense. I think the line
>> 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK':
>>
>> 3541                             (modifiers &
>> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK));
>>
>> Best regards,
>> Andrej Golovnin



From Sergey.Bylokhov at oracle.com  Wed Jun 20 23:07:28 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Jun 2018 16:07:28 -0700
Subject: <Swing Dev> [11] Review Request: 8205144 JSpinner may change the
 font after became visible
Message-ID: <0dcb7f5e-33d1-05a6-45bd-f4a6a3223bf8@oracle.com>

Hello.
Please review the fix for jdk11.

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

Our implementation of JSpinner tries to maintain the font which is used 
in the text field inside spinner. There are three cases when the font of 
the text field should be changed to the font of spinner(if the font of 
text field was not set by the user).
  - By default when the spinner is created(fixed in JDK-6421058)
  - When the user change the font of the spinner(fixed in JDK-5036022)

And there is one more case which should be taken into account. It is 
possible that LaF can change the font of text field to the font which is 
used by default by all textfields in this LaF. It is possible to 
reproduce this using:
==========
     /**
      * A simple minded look and feel change: ask each node in the tree
      * to <code>updateUI()</code> -- that is, to initialize its UI property
      * with the current look and feel.
      */
     public static void updateComponentTreeUI(Component c)

==========

This method will iterate over hierarchy of the components and call 
updateUI() for each components, then its children, and so on. This is a 
situation when the bug is reproduced. During updateUI() in JSpinner the 
font of internal text field will be set to the font of the spinner, but 
later when the updateUI() will be called for the text field itself the 
font will be set to default font of of all text fields.

The problem is not reproduced if the application do not change the LaF 
on the fly, because in this case we call updateUI() for spinner after 
updateUI() for internal text field.

The fix will reject all fonts(UIResource) which were not set by the 
user, except the font of the spinner.

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Jun 20 23:23:48 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Jun 2018 16:23:48 -0700
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <caf48671-8e20-4d19-9962-7f58e342408c@default>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
 <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>
 <42a16319-9b11-45b8-b429-46bc90fb0c5c@default>
 <CAM6ZMz_a=92wmpw9QE1WS0U9d8f1OjjhkidbrvVBGHVVkrTrXg@mail.gmail.com>
 <ffd3977e-5944-4911-8e17-75d3f1ee2900@default>
 <dcb9b0f3-2839-ce12-d43d-3ef9c1823014@oracle.com>
 <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default>
 <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
 <caf48671-8e20-4d19-9962-7f58e342408c@default>
Message-ID: <7bd954b3-74c5-573d-595f-711ca8fa8072@oracle.com>

Hi, Pankaj.
Is this bug applicable only to windows? can we make the test non-windows 
specific?

On 20/06/2018 07:52, Pankaj Bansal wrote:
> Hi Prasanta,
> 
> I looked at documentation of KeyStroke.getKeyStroke and InputEvent.ALT_MASK should be used instead of ActionEvent.ALT_MASK. The corresponding InputEvent.ALT_GRAPH_MASK is already present. I used it by mistake last time.
> I have made changes for JMenuItem I have changed BasicJMenuItemUI for JMenuItem and updated the test case too. Other changes are same as webrev.02. Please have a look.
> Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.03/
> 
> 
> Regards,
> Pankaj Bansal
> 
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Friday, April 20, 2018 5:04 PM
> To: Pankaj Bansal
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components
> 
> Hi Pankaj,
> 
> 
> On 4/20/2018 3:48 PM, Pankaj Bansal wrote:
>> Hi Prasanta,
>>
>> In case of JMenuItem, there are two ways to add key shortcuts
>>
>> 1.
>> JMenuItem newMenuItem = new JMenuItem("New");
>>    newMenuItem.setMnemonic(KeyEvent.VK_N);
>> In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded.
>>
>> 2.
>> JMenuItem newMenuItem = new JMenuItem("New");
>> newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N,
>> ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded  in this case.
> But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH.
> 
> Regards
> Prasanta
>> Please let me know what do you think about this.
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Prasanta Sadhukhan
>> Sent: Thursday, April 19, 2018 12:41 PM
>> To: Pankaj Bansal; Andrej Golovnin
>> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>> longer work in Swing components
>>
>> Hi Pankaj,
>>
>> looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works?
>>
>> Regards
>> Prasanta
>> On 4/10/2018 3:15 PM, Pankaj Bansal wrote:
>>> Hello Andrej,
>>>
>>> Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out.
>>> Webrev:
>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/
>>>
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>> -----Original Message-----
>>> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
>>> Sent: Tuesday, April 10, 2018 2:18 PM
>>> To: Pankaj Bansal
>>> Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>>> longer work in Swing components
>>>
>>> Hi Pankaj,
>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/
>>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>
>>> 3540         BOOL altIsDown = ((modifiers &
>>> java_awt_event_InputEvent_ALT_DOWN_MASK) ||
>>> 3541                             (modifiers &
>>> java_awt_event_InputEvent_ALT_DOWN_MASK));
>>>
>>> Applying '||' on the same value does not make sense. I think the line
>>> 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK':
>>>
>>> 3541                             (modifiers &
>>> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK));
>>>
>>> Best regards,
>>> Andrej Golovnin
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Thu Jun 21 00:03:56 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 20 Jun 2018 17:03:56 -0700
Subject: <Swing Dev> [11] JDK-8153732: Windows remote printer changes do
 not reflect in lookupPrintServices()
In-Reply-To: <afa12391-489d-4997-b2b8-9925a36cf756@default>
References: <afa12391-489d-4997-b2b8-9925a36cf756@default>
Message-ID: <5B2AEB6C.5080403@oracle.com>

This is on the wrong lists. Not Swing. Not AWT. Should be 2d.
I'll forward it there and continue there. Consider the AWT+Swing threads 
dead.

-phil.

On 6/20/18, 3:12 AM, Shashidhara Veerabhadraiah wrote:
>
> Hi All, Please review this code changes for the below enhancement.
>
> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8153732
>
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8153732/webrev.00/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8153732/webrev.00/>
>
> Details of the changes: Windows provides *PrinterChangeNotification* 
> functions that provides information about printer status changes of 
> the local printers(subset) but not network printers.
> Alternatively, Windows provides a way thro' which one can get the 
> network printer status changes by using WMI, RegistryKeyChange 
> combination, which is a slightly complex mechanism.
> The Windows WMI offers an async and sync method to read thro' registry 
> via the WQL query. The async method is considered dangerous as it 
> leaves open a channel until we close it. But the async method has the 
> advantage of being notified of a change in registry by calling 
> callback without polling for it. The sync method uses the polling 
> mechanism to notify.
> RegistryValueChange cannot be used in combination with WMI to get 
> registry value change notification because of an error that may be 
> generated because the scope of the query would be too big to handle(at 
> times).
> Hence an alternative mechanism is choosen via the EnumPrinters by 
> polling for the count of printer status changes(add\remove) and based 
> on it update the printers list(both local and remote printers - superset).
>
> Thanks and regards,
>
> Shashi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180620/e5bd95f9/attachment.html>

From prasanta.sadhukhan at oracle.com  Thu Jun 21 06:01:57 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 21 Jun 2018 11:31:57 +0530
Subject: <Swing Dev> [11] Review Request: 8205144 JSpinner may change
 the font after became visible
In-Reply-To: <0dcb7f5e-33d1-05a6-45bd-f4a6a3223bf8@oracle.com>
References: <0dcb7f5e-33d1-05a6-45bd-f4a6a3223bf8@oracle.com>
Message-ID: <09de24d7-b29c-822f-9e1d-8b5700e8a4a3@oracle.com>

Looks good to me.

Regards
Prasanta
On 6/21/2018 4:37 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205144
> Webrev: http://cr.openjdk.java.net/~serb/8205144/webrev.00
>
> Our implementation of JSpinner tries to maintain the font which is 
> used in the text field inside spinner. There are three cases when the 
> font of the text field should be changed to the font of spinner(if the 
> font of text field was not set by the user).
> ?- By default when the spinner is created(fixed in JDK-6421058)
> ?- When the user change the font of the spinner(fixed in JDK-5036022)
>
> And there is one more case which should be taken into account. It is 
> possible that LaF can change the font of text field to the font which 
> is used by default by all textfields in this LaF. It is possible to 
> reproduce this using:
> ==========
> ??? /**
> ???? * A simple minded look and feel change: ask each node in the tree
> ???? * to <code>updateUI()</code> -- that is, to initialize its UI 
> property
> ???? * with the current look and feel.
> ???? */
> ??? public static void updateComponentTreeUI(Component c)
>
> ==========
>
> This method will iterate over hierarchy of the components and call 
> updateUI() for each components, then its children, and so on. This is 
> a situation when the bug is reproduced. During updateUI() in JSpinner 
> the font of internal text field will be set to the font of the 
> spinner, but later when the updateUI() will be called for the text 
> field itself the font will be set to default font of of all text fields.
>
> The problem is not reproduced if the application do not change the LaF 
> on the fly, because in this case we call updateUI() for spinner after 
> updateUI() for internal text field.
>
> The fix will reject all fonts(UIResource) which were not set by the 
> user, except the font of the spinner.
>



From prasanta.sadhukhan at oracle.com  Thu Jun 21 06:28:02 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 21 Jun 2018 11:58:02 +0530
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <caf48671-8e20-4d19-9962-7f58e342408c@default>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
 <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>
 <42a16319-9b11-45b8-b429-46bc90fb0c5c@default>
 <CAM6ZMz_a=92wmpw9QE1WS0U9d8f1OjjhkidbrvVBGHVVkrTrXg@mail.gmail.com>
 <ffd3977e-5944-4911-8e17-75d3f1ee2900@default>
 <dcb9b0f3-2839-ce12-d43d-3ef9c1823014@oracle.com>
 <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default>
 <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
 <caf48671-8e20-4d19-9962-7f58e342408c@default>
Message-ID: <d0b6a082-2f43-9cac-6454-378b1ef8fe4a@oracle.com>

Hi Pankaj,

The test passed for me in windows 10 even without your fix and the test 
frames and dialogs are kept visible even after the test finished. Please 
have a look.

Regards
Prasanta
On 6/20/2018 8:22 PM, Pankaj Bansal wrote:
> Hi Prasanta,
>
> I looked at documentation of KeyStroke.getKeyStroke and InputEvent.ALT_MASK should be used instead of ActionEvent.ALT_MASK. The corresponding InputEvent.ALT_GRAPH_MASK is already present. I used it by mistake last time.
> I have made changes for JMenuItem I have changed BasicJMenuItemUI for JMenuItem and updated the test case too. Other changes are same as webrev.02. Please have a look.
> Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.03/
>
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Friday, April 20, 2018 5:04 PM
> To: Pankaj Bansal
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components
>
> Hi Pankaj,
>
>
> On 4/20/2018 3:48 PM, Pankaj Bansal wrote:
>> Hi Prasanta,
>>
>> In case of JMenuItem, there are two ways to add key shortcuts
>>
>> 1.
>> JMenuItem newMenuItem = new JMenuItem("New");
>>    newMenuItem.setMnemonic(KeyEvent.VK_N);
>> In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded.
>>
>> 2.
>> JMenuItem newMenuItem = new JMenuItem("New");
>> newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N,
>> ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded  in this case.
> But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH.
>
> Regards
> Prasanta
>> Please let me know what do you think about this.
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Prasanta Sadhukhan
>> Sent: Thursday, April 19, 2018 12:41 PM
>> To: Pankaj Bansal; Andrej Golovnin
>> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>> longer work in Swing components
>>
>> Hi Pankaj,
>>
>> looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works?
>>
>> Regards
>> Prasanta
>> On 4/10/2018 3:15 PM, Pankaj Bansal wrote:
>>> Hello Andrej,
>>>
>>> Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out.
>>> Webrev:
>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/
>>>
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>> -----Original Message-----
>>> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
>>> Sent: Tuesday, April 10, 2018 2:18 PM
>>> To: Pankaj Bansal
>>> Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>>> longer work in Swing components
>>>
>>> Hi Pankaj,
>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/
>>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>
>>> 3540         BOOL altIsDown = ((modifiers &
>>> java_awt_event_InputEvent_ALT_DOWN_MASK) ||
>>> 3541                             (modifiers &
>>> java_awt_event_InputEvent_ALT_DOWN_MASK));
>>>
>>> Applying '||' on the same value does not make sense. I think the line
>>> 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK':
>>>
>>> 3541                             (modifiers &
>>> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK));
>>>
>>> Best regards,
>>> Andrej Golovnin



From pankaj.b.bansal at oracle.com  Thu Jun 21 12:25:18 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 21 Jun 2018 05:25:18 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <d0b6a082-2f43-9cac-6454-378b1ef8fe4a@oracle.com>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
 <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>
 <42a16319-9b11-45b8-b429-46bc90fb0c5c@default>
 <CAM6ZMz_a=92wmpw9QE1WS0U9d8f1OjjhkidbrvVBGHVVkrTrXg@mail.gmail.com>
 <ffd3977e-5944-4911-8e17-75d3f1ee2900@default>
 <dcb9b0f3-2839-ce12-d43d-3ef9c1823014@oracle.com>
 <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default>
 <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
 <caf48671-8e20-4d19-9962-7f58e342408c@default>
 <d0b6a082-2f43-9cac-6454-378b1ef8fe4a@oracle.com>
Message-ID: <ef428376-62ba-46b0-bf5b-131ed13e32a0@default>

Hi Prasanta/Sergey

@Prasanta
<< The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
Sorry I think I was testing by printing log on console instead of throwing exceptions and I made webrev with that version. I have corrected it now. The test fails without fix and passes with fix on Windows 10. 

@Sergey
<< Is this bug applicable only to windows? can we make the test non-windows specific?
Yes, I think this bug addresses the regression introduced when the fix was made for https://bugs.openjdk.java.net/browse/JDK-8041928. Both ALT and ALT_GRAPH keys work on Windows. The test added fails on linux and mac both with and without fix. I think the ALT_GRAPH key does not work on these platforms and it is not related to the regression being addressed here. We can file separate bug to investigate that. Please let me know what do you think regarding this.

I have run possible affected jck tests on Windows and all the automated event tests in awt/swing jtreg tests on Windows, Linux  and Mac. The fix is not producing any regression.

webrev:
http://cr.openjdk.java.net/~pbansal/8194873/webrev.04/


Thanks,
Pankj Bansal
-----Original Message-----
From: Prasanta Sadhukhan 
Sent: Thursday, June 21, 2018 11:58 AM
To: Pankaj Bansal
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components

Hi Pankaj,

The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.

Regards
Prasanta
On 6/20/2018 8:22 PM, Pankaj Bansal wrote:
> Hi Prasanta,
>
> I looked at documentation of KeyStroke.getKeyStroke and InputEvent.ALT_MASK should be used instead of ActionEvent.ALT_MASK. The corresponding InputEvent.ALT_GRAPH_MASK is already present. I used it by mistake last time.
> I have made changes for JMenuItem I have changed BasicJMenuItemUI for JMenuItem and updated the test case too. Other changes are same as webrev.02. Please have a look.
> Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.03/
>
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Friday, April 20, 2018 5:04 PM
> To: Pankaj Bansal
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
> longer work in Swing components
>
> Hi Pankaj,
>
>
> On 4/20/2018 3:48 PM, Pankaj Bansal wrote:
>> Hi Prasanta,
>>
>> In case of JMenuItem, there are two ways to add key shortcuts
>>
>> 1.
>> JMenuItem newMenuItem = new JMenuItem("New");
>>    newMenuItem.setMnemonic(KeyEvent.VK_N);
>> In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded.
>>
>> 2.
>> JMenuItem newMenuItem = new JMenuItem("New"); 
>> newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N, 
>> ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded  in this case.
> But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH.
>
> Regards
> Prasanta
>> Please let me know what do you think about this.
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Prasanta Sadhukhan
>> Sent: Thursday, April 19, 2018 12:41 PM
>> To: Pankaj Bansal; Andrej Golovnin
>> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
>> longer work in Swing components
>>
>> Hi Pankaj,
>>
>> looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works?
>>
>> Regards
>> Prasanta
>> On 4/10/2018 3:15 PM, Pankaj Bansal wrote:
>>> Hello Andrej,
>>>
>>> Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out.
>>> Webrev:
>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/
>>>
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>> -----Original Message-----
>>> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
>>> Sent: Tuesday, April 10, 2018 2:18 PM
>>> To: Pankaj Bansal
>>> Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
>>> longer work in Swing components
>>>
>>> Hi Pankaj,
>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/
>>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>
>>> 3540         BOOL altIsDown = ((modifiers &
>>> java_awt_event_InputEvent_ALT_DOWN_MASK) ||
>>> 3541                             (modifiers &
>>> java_awt_event_InputEvent_ALT_DOWN_MASK));
>>>
>>> Applying '||' on the same value does not make sense. I think the 
>>> line
>>> 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK':
>>>
>>> 3541                             (modifiers &
>>> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK));
>>>
>>> Best regards,
>>> Andrej Golovnin



From philip.race at oracle.com  Thu Jun 21 20:53:20 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 21 Jun 2018 13:53:20 -0700
Subject: <Swing Dev> RFR: 8205119: SwingApplet demo should be removed
Message-ID: <fffc9ac6-c4b3-6e2e-7318-2bdcd1dde94a@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8205119
Webrev : http://cr.openjdk.java.net/~prr/8205119/

This demo only demonstrates how to create a Swing Applet, nothing more, but
Applet is now deprecated, and the demo can't be run without 
appletviewer, so remove it.

-phil.


From Sergey.Bylokhov at oracle.com  Thu Jun 21 21:25:56 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Jun 2018 14:25:56 -0700
Subject: <Swing Dev> RFR: 8205119: SwingApplet demo should be removed
In-Reply-To: <fffc9ac6-c4b3-6e2e-7318-2bdcd1dde94a@oracle.com>
References: <fffc9ac6-c4b3-6e2e-7318-2bdcd1dde94a@oracle.com>
Message-ID: <d7808384-e667-5b34-4719-53e346c26de9@oracle.com>

Looks fine.

On 21/06/2018 13:53, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205119
> Webrev : http://cr.openjdk.java.net/~prr/8205119/
> 
> This demo only demonstrates how to create a Swing Applet, nothing more, but
> Applet is now deprecated, and the demo can't be run without 
> appletviewer, so remove it.
> 
> -phil.


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Jun 21 23:42:46 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Jun 2018 16:42:46 -0700
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <ef428376-62ba-46b0-bf5b-131ed13e32a0@default>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
 <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>
 <42a16319-9b11-45b8-b429-46bc90fb0c5c@default>
 <CAM6ZMz_a=92wmpw9QE1WS0U9d8f1OjjhkidbrvVBGHVVkrTrXg@mail.gmail.com>
 <ffd3977e-5944-4911-8e17-75d3f1ee2900@default>
 <dcb9b0f3-2839-ce12-d43d-3ef9c1823014@oracle.com>
 <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default>
 <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
 <caf48671-8e20-4d19-9962-7f58e342408c@default>
 <d0b6a082-2f43-9cac-6454-378b1ef8fe4a@oracle.com>
 <ef428376-62ba-46b0-bf5b-131ed13e32a0@default>
Message-ID: <13ade394-f7f8-1d94-28cd-ea3365bbbf43@oracle.com>

This looks fine to me, the only suggestion is to try to extract the 
common code to some new method in SwingUtil2.

On 21/06/2018 05:25, Pankaj Bansal wrote:
> Hi Prasanta/Sergey
> 
> @Prasanta
> << The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
> Sorry I think I was testing by printing log on console instead of throwing exceptions and I made webrev with that version. I have corrected it now. The test fails without fix and passes with fix on Windows 10.
> 
> @Sergey
> << Is this bug applicable only to windows? can we make the test non-windows specific?
> Yes, I think this bug addresses the regression introduced when the fix was made for https://bugs.openjdk.java.net/browse/JDK-8041928. Both ALT and ALT_GRAPH keys work on Windows. The test added fails on linux and mac both with and without fix. I think the ALT_GRAPH key does not work on these platforms and it is not related to the regression being addressed here. We can file separate bug to investigate that. Please let me know what do you think regarding this.
> 
> I have run possible affected jck tests on Windows and all the automated event tests in awt/swing jtreg tests on Windows, Linux  and Mac. The fix is not producing any regression.
> 
> webrev:
> http://cr.openjdk.java.net/~pbansal/8194873/webrev.04/
> 
> 
> Thanks,
> Pankj Bansal
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Thursday, June 21, 2018 11:58 AM
> To: Pankaj Bansal
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components
> 
> Hi Pankaj,
> 
> The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
> 
> Regards
> Prasanta
> On 6/20/2018 8:22 PM, Pankaj Bansal wrote:
>> Hi Prasanta,
>>
>> I looked at documentation of KeyStroke.getKeyStroke and InputEvent.ALT_MASK should be used instead of ActionEvent.ALT_MASK. The corresponding InputEvent.ALT_GRAPH_MASK is already present. I used it by mistake last time.
>> I have made changes for JMenuItem I have changed BasicJMenuItemUI for JMenuItem and updated the test case too. Other changes are same as webrev.02. Please have a look.
>> Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.03/
>>
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Prasanta Sadhukhan
>> Sent: Friday, April 20, 2018 5:04 PM
>> To: Pankaj Bansal
>> Cc: swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>> longer work in Swing components
>>
>> Hi Pankaj,
>>
>>
>> On 4/20/2018 3:48 PM, Pankaj Bansal wrote:
>>> Hi Prasanta,
>>>
>>> In case of JMenuItem, there are two ways to add key shortcuts
>>>
>>> 1.
>>> JMenuItem newMenuItem = new JMenuItem("New");
>>>     newMenuItem.setMnemonic(KeyEvent.VK_N);
>>> In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded.
>>>
>>> 2.
>>> JMenuItem newMenuItem = new JMenuItem("New");
>>> newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N,
>>> ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded  in this case.
>> But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH.
>>
>> Regards
>> Prasanta
>>> Please let me know what do you think about this.
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>> -----Original Message-----
>>> From: Prasanta Sadhukhan
>>> Sent: Thursday, April 19, 2018 12:41 PM
>>> To: Pankaj Bansal; Andrej Golovnin
>>> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>>> longer work in Swing components
>>>
>>> Hi Pankaj,
>>>
>>> looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works?
>>>
>>> Regards
>>> Prasanta
>>> On 4/10/2018 3:15 PM, Pankaj Bansal wrote:
>>>> Hello Andrej,
>>>>
>>>> Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out.
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/
>>>>
>>>>
>>>> Regards,
>>>> Pankaj Bansal
>>>>
>>>> -----Original Message-----
>>>> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
>>>> Sent: Tuesday, April 10, 2018 2:18 PM
>>>> To: Pankaj Bansal
>>>> Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net
>>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>>>> longer work in Swing components
>>>>
>>>> Hi Pankaj,
>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/
>>>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>>
>>>> 3540         BOOL altIsDown = ((modifiers &
>>>> java_awt_event_InputEvent_ALT_DOWN_MASK) ||
>>>> 3541                             (modifiers &
>>>> java_awt_event_InputEvent_ALT_DOWN_MASK));
>>>>
>>>> Applying '||' on the same value does not make sense. I think the
>>>> line
>>>> 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK':
>>>>
>>>> 3541                             (modifiers &
>>>> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK));
>>>>
>>>> Best regards,
>>>> Andrej Golovnin
> 


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Fri Jun 22 05:25:53 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 22 Jun 2018 10:55:53 +0530
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <ef428376-62ba-46b0-bf5b-131ed13e32a0@default>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
 <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>
 <42a16319-9b11-45b8-b429-46bc90fb0c5c@default>
 <CAM6ZMz_a=92wmpw9QE1WS0U9d8f1OjjhkidbrvVBGHVVkrTrXg@mail.gmail.com>
 <ffd3977e-5944-4911-8e17-75d3f1ee2900@default>
 <dcb9b0f3-2839-ce12-d43d-3ef9c1823014@oracle.com>
 <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default>
 <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
 <caf48671-8e20-4d19-9962-7f58e342408c@default>
 <d0b6a082-2f43-9cac-6454-378b1ef8fe4a@oracle.com>
 <ef428376-62ba-46b0-bf5b-131ed13e32a0@default>
Message-ID: <b6b01155-6d09-755e-67a0-dd7cb46ebbcc@oracle.com>

Can you explain

437 @SuppressWarnings("deprecation") in BasicMenuItemUI

The test still does not cleanup/dispose the frames on exit. Please have 
a look.

Regards
Prasanta
On 6/21/2018 5:55 PM, Pankaj Bansal wrote:
> Hi Prasanta/Sergey
>
> @Prasanta
> << The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
> Sorry I think I was testing by printing log on console instead of throwing exceptions and I made webrev with that version. I have corrected it now. The test fails without fix and passes with fix on Windows 10.
>
> @Sergey
> << Is this bug applicable only to windows? can we make the test non-windows specific?
> Yes, I think this bug addresses the regression introduced when the fix was made for https://bugs.openjdk.java.net/browse/JDK-8041928. Both ALT and ALT_GRAPH keys work on Windows. The test added fails on linux and mac both with and without fix. I think the ALT_GRAPH key does not work on these platforms and it is not related to the regression being addressed here. We can file separate bug to investigate that. Please let me know what do you think regarding this.
>
> I have run possible affected jck tests on Windows and all the automated event tests in awt/swing jtreg tests on Windows, Linux  and Mac. The fix is not producing any regression.
>
> webrev:
> http://cr.openjdk.java.net/~pbansal/8194873/webrev.04/
>
>
> Thanks,
> Pankj Bansal
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Thursday, June 21, 2018 11:58 AM
> To: Pankaj Bansal
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components
>
> Hi Pankaj,
>
> The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
>
> Regards
> Prasanta
> On 6/20/2018 8:22 PM, Pankaj Bansal wrote:
>> Hi Prasanta,
>>
>> I looked at documentation of KeyStroke.getKeyStroke and InputEvent.ALT_MASK should be used instead of ActionEvent.ALT_MASK. The corresponding InputEvent.ALT_GRAPH_MASK is already present. I used it by mistake last time.
>> I have made changes for JMenuItem I have changed BasicJMenuItemUI for JMenuItem and updated the test case too. Other changes are same as webrev.02. Please have a look.
>> Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.03/
>>
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Prasanta Sadhukhan
>> Sent: Friday, April 20, 2018 5:04 PM
>> To: Pankaj Bansal
>> Cc: swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>> longer work in Swing components
>>
>> Hi Pankaj,
>>
>>
>> On 4/20/2018 3:48 PM, Pankaj Bansal wrote:
>>> Hi Prasanta,
>>>
>>> In case of JMenuItem, there are two ways to add key shortcuts
>>>
>>> 1.
>>> JMenuItem newMenuItem = new JMenuItem("New");
>>>     newMenuItem.setMnemonic(KeyEvent.VK_N);
>>> In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded.
>>>
>>> 2.
>>> JMenuItem newMenuItem = new JMenuItem("New");
>>> newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N,
>>> ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded  in this case.
>> But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH.
>>
>> Regards
>> Prasanta
>>> Please let me know what do you think about this.
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>> -----Original Message-----
>>> From: Prasanta Sadhukhan
>>> Sent: Thursday, April 19, 2018 12:41 PM
>>> To: Pankaj Bansal; Andrej Golovnin
>>> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>>> longer work in Swing components
>>>
>>> Hi Pankaj,
>>>
>>> looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works?
>>>
>>> Regards
>>> Prasanta
>>> On 4/10/2018 3:15 PM, Pankaj Bansal wrote:
>>>> Hello Andrej,
>>>>
>>>> Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out.
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/
>>>>
>>>>
>>>> Regards,
>>>> Pankaj Bansal
>>>>
>>>> -----Original Message-----
>>>> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
>>>> Sent: Tuesday, April 10, 2018 2:18 PM
>>>> To: Pankaj Bansal
>>>> Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net
>>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>>>> longer work in Swing components
>>>>
>>>> Hi Pankaj,
>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/
>>>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>>
>>>> 3540         BOOL altIsDown = ((modifiers &
>>>> java_awt_event_InputEvent_ALT_DOWN_MASK) ||
>>>> 3541                             (modifiers &
>>>> java_awt_event_InputEvent_ALT_DOWN_MASK));
>>>>
>>>> Applying '||' on the same value does not make sense. I think the
>>>> line
>>>> 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK':
>>>>
>>>> 3541                             (modifiers &
>>>> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK));
>>>>
>>>> Best regards,
>>>> Andrej Golovnin

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

From pankaj.b.bansal at oracle.com  Fri Jun 22 08:25:26 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 22 Jun 2018 01:25:26 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <b6b01155-6d09-755e-67a0-dd7cb46ebbcc@oracle.com>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
 <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>
 <42a16319-9b11-45b8-b429-46bc90fb0c5c@default>
 <CAM6ZMz_a=92wmpw9QE1WS0U9d8f1OjjhkidbrvVBGHVVkrTrXg@mail.gmail.com>
 <ffd3977e-5944-4911-8e17-75d3f1ee2900@default>
 <dcb9b0f3-2839-ce12-d43d-3ef9c1823014@oracle.com>
 <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default>
 <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
 <caf48671-8e20-4d19-9962-7f58e342408c@default>
 <d0b6a082-2f43-9cac-6454-378b1ef8fe4a@oracle.com>
 <ef428376-62ba-46b0-bf5b-131ed13e32a0@default>
 <b6b01155-6d09-755e-67a0-dd7cb46ebbcc@oracle.com>
Message-ID: <a33911a7-c45b-44ba-a762-193a8f0126a6@default>

Hello Prasanta,

?

<<437???? @SuppressWarnings("deprecation") 
<<in BasicMenuItemUI
?

While setting the modifier in accelerator, there are three possible cases with ALT and ALT_GRAPH modifiers we have to handle

1.????? When both ALT and ALT_GRAPH modifiers were set: We need to add the ALT only modifier keystroke which is used for left ALT key. Unsetting the ALT_GRAPH will do that as ALT is already set

2.????? When only ALT was set: We need to add the ALT+ALT_GRAPH modifier keystroke

3.????? When only ALT_GRAPH was set: We don?t need the ALT_GRAPH only modifier as this will never be the true (Windows gives true for both ALT and ALT_GRAPH when right ALT key is pressed). Add the ALT and ALT+ALT_GRAPH modifiers keystroke which are used for left ALT key and right ALT keys respectively.

?

Now, to unset the ALT_GRAPH, I need to unset both? ALT_GRAPH_MASK and ALT_GRAPH_DOWN_MASK as they are corresponding flags for old and new modifiers. So I need to access the ALT_GRAPH_MASK but it deprecated, so had to suppress warnings. This is used at lot of places for same reason.

Please see KeyEvent-> setNewModifiers, setOldModifiers.

Please let me know if this makes sense.

?

<<The test still does not cleanup/dispose the frames on exit. Please have a look.

Done.

Webrev:

http://cr.openjdk.java.net/~pbansal/8194873/webrev.05/

?

?

From: Prasanta Sadhukhan 
Sent: Friday, June 22, 2018 10:56 AM
To: Pankaj Bansal; Sergey Bylokhov
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components

?

Can you explain 

437???? @SuppressWarnings("deprecation") 
in BasicMenuItemUI

The test still does not cleanup/dispose the frames on exit. Please have a look.

Regards
Prasanta

On 6/21/2018 5:55 PM, Pankaj Bansal wrote:

Hi Prasanta/Sergey
?
@Prasanta
<< The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
Sorry I think I was testing by printing log on console instead of throwing exceptions and I made webrev with that version. I have corrected it now. The test fails without fix and passes with fix on Windows 10. 
?
@Sergey
<< Is this bug applicable only to windows? can we make the test non-windows specific?
Yes, I think this bug addresses the regression introduced when the fix was made for https://bugs.openjdk.java.net/browse/JDK-8041928. Both ALT and ALT_GRAPH keys work on Windows. The test added fails on linux and mac both with and without fix. I think the ALT_GRAPH key does not work on these platforms and it is not related to the regression being addressed here. We can file separate bug to investigate that. Please let me know what do you think regarding this.
?
I have run possible affected jck tests on Windows and all the automated event tests in awt/swing jtreg tests on Windows, Linux? and Mac. The fix is not producing any regression.
?
webrev:
http://cr.openjdk.java.net/~pbansal/8194873/webrev.04/
?
?
Thanks,
Pankj Bansal
-----Original Message-----
From: Prasanta Sadhukhan 
Sent: Thursday, June 21, 2018 11:58 AM
To: Pankaj Bansal
Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components
?
Hi Pankaj,
?
The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
?
Regards
Prasanta
On 6/20/2018 8:22 PM, Pankaj Bansal wrote:

Hi Prasanta,
?
I looked at documentation of KeyStroke.getKeyStroke and InputEvent.ALT_MASK should be used instead of ActionEvent.ALT_MASK. The corresponding InputEvent.ALT_GRAPH_MASK is already present. I used it by mistake last time.
I have made changes for JMenuItem I have changed BasicJMenuItemUI for JMenuItem and updated the test case too. Other changes are same as webrev.02. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.03/
?
?
Regards,
Pankaj Bansal
?
-----Original Message-----
From: Prasanta Sadhukhan
Sent: Friday, April 20, 2018 5:04 PM
To: Pankaj Bansal
Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
longer work in Swing components
?
Hi Pankaj,
?
?
On 4/20/2018 3:48 PM, Pankaj Bansal wrote:

Hi Prasanta,
?
In case of JMenuItem, there are two ways to add key shortcuts
?
1.
JMenuItem newMenuItem = new JMenuItem("New");
?? newMenuItem.setMnemonic(KeyEvent.VK_N);
In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded.
?
2.
JMenuItem newMenuItem = new JMenuItem("New"); 
newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N, 
ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded? in this case.

But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH.
?
Regards
Prasanta

Please let me know what do you think about this.
?
Regards,
Pankaj Bansal
?
-----Original Message-----
From: Prasanta Sadhukhan
Sent: Thursday, April 19, 2018 12:41 PM
To: Pankaj Bansal; Andrej Golovnin
Cc: Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
longer work in Swing components
?
Hi Pankaj,
?
looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works?
?
Regards
Prasanta
On 4/10/2018 3:15 PM, Pankaj Bansal wrote:

Hello Andrej,
?
Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out.
Webrev:
http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/
?
?
Regards,
Pankaj Bansal
?
-----Original Message-----
From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
Sent: Tuesday, April 10, 2018 2:18 PM
To: Pankaj Bansal
Cc: Prasanta Sadhukhan; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
longer work in Swing components
?
Hi Pankaj,
?

Webrev:
?
http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/

src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
?
3540???????? BOOL altIsDown = ((modifiers &
java_awt_event_InputEvent_ALT_DOWN_MASK) ||
3541???????????????????????????? (modifiers &
java_awt_event_InputEvent_ALT_DOWN_MASK));
?
Applying '||' on the same value does not make sense. I think the 
line
3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK':
?
3541???????????????????????????? (modifiers &
java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK));
?
Best regards,
Andrej Golovnin

?

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

From prasanta.sadhukhan at oracle.com  Fri Jun 22 08:39:33 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 22 Jun 2018 14:09:33 +0530
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <a33911a7-c45b-44ba-a762-193a8f0126a6@default>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
 <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>
 <42a16319-9b11-45b8-b429-46bc90fb0c5c@default>
 <CAM6ZMz_a=92wmpw9QE1WS0U9d8f1OjjhkidbrvVBGHVVkrTrXg@mail.gmail.com>
 <ffd3977e-5944-4911-8e17-75d3f1ee2900@default>
 <dcb9b0f3-2839-ce12-d43d-3ef9c1823014@oracle.com>
 <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default>
 <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
 <caf48671-8e20-4d19-9962-7f58e342408c@default>
 <d0b6a082-2f43-9cac-6454-378b1ef8fe4a@oracle.com>
 <ef428376-62ba-46b0-bf5b-131ed13e32a0@default>
 <b6b01155-6d09-755e-67a0-dd7cb46ebbcc@oracle.com>
 <a33911a7-c45b-44ba-a762-193a8f0126a6@default>
Message-ID: <982aeaca-1e0a-a740-1a11-b4dd1465f088@oracle.com>

ok. +1

Regards
Prasanta
On 6/22/2018 1:55 PM, Pankaj Bansal wrote:
>
> Hello Prasanta,
>
> <<437???? @SuppressWarnings("deprecation")
> <<in BasicMenuItemUI
>
> While setting the modifier in accelerator, there are three possible 
> cases with ALT and ALT_GRAPH modifiers we have to handle
>
> 1.When both ALT and ALT_GRAPH modifiers were set: We need to add the 
> ALT only modifier keystroke which is used for left ALT key. Unsetting 
> the ALT_GRAPH will do that as ALT is already set
>
> 2.When only ALT was set: We need to add the ALT+ALT_GRAPH modifier 
> keystroke
>
> 3.When only ALT_GRAPH was set: We don?t need the ALT_GRAPH only 
> modifier as this will never be the true (Windows gives true for both 
> ALT and ALT_GRAPH when right ALT key is pressed). Add the ALT and 
> ALT+ALT_GRAPH modifiers keystroke which are used for left ALT key and 
> right ALT keys respectively.
>
> Now, to unset the ALT_GRAPH, I need to unset both ALT_GRAPH_MASK and 
> ALT_GRAPH_DOWN_MASK as they are corresponding flags for old and new 
> modifiers. So I need to access the ALT_GRAPH_MASK but it deprecated, 
> so had to suppress warnings. This is used at lot of places for same 
> reason.
>
> Please see KeyEvent-> setNewModifiers, setOldModifiers.
>
> Please let me know if this makes sense.
>
> <<The test still does not cleanup/dispose the frames on exit. Please 
> have a look.
>
> Done.
>
> Webrev:
>
> http://cr.openjdk.java.net/~pbansal/8194873/webrev.05/
>
> *From:*Prasanta Sadhukhan
> *Sent:* Friday, June 22, 2018 10:56 AM
> *To:* Pankaj Bansal; Sergey Bylokhov
> *Cc:* swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
> longer work in Swing components
>
> Can you explain
>
> 437???? @SuppressWarnings("deprecation")
> in BasicMenuItemUI
>
> The test still does not cleanup/dispose the frames on exit. Please 
> have a look.
>
> Regards
> Prasanta
>
> On 6/21/2018 5:55 PM, Pankaj Bansal wrote:
>
>     Hi Prasanta/Sergey
>
>     @Prasanta
>
>     << The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
>
>     Sorry I think I was testing by printing log on console instead of throwing exceptions and I made webrev with that version. I have corrected it now. The test fails without fix and passes with fix on Windows 10.
>
>     @Sergey
>
>     << Is this bug applicable only to windows? can we make the test non-windows specific?
>
>     Yes, I think this bug addresses the regression introduced when the fix was made forhttps://bugs.openjdk.java.net/browse/JDK-8041928. Both ALT and ALT_GRAPH keys work on Windows. The test added fails on linux and mac both with and without fix. I think the ALT_GRAPH key does not work on these platforms and it is not related to the regression being addressed here. We can file separate bug to investigate that. Please let me know what do you think regarding this.
>
>     I have run possible affected jck tests on Windows and all the automated event tests in awt/swing jtreg tests on Windows, Linux? and Mac. The fix is not producing any regression.
>
>     webrev:
>
>     http://cr.openjdk.java.net/~pbansal/8194873/webrev.04/
>     <http://cr.openjdk.java.net/%7Epbansal/8194873/webrev.04/>
>
>     Thanks,
>
>     Pankj Bansal
>
>     -----Original Message-----
>
>     From: Prasanta Sadhukhan
>
>     Sent: Thursday, June 21, 2018 11:58 AM
>
>     To: Pankaj Bansal
>
>     Cc:swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>
>     Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components
>
>     Hi Pankaj,
>
>     The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
>
>     Regards
>
>     Prasanta
>
>     On 6/20/2018 8:22 PM, Pankaj Bansal wrote:
>
>         Hi Prasanta,
>
>         I looked at documentation of KeyStroke.getKeyStroke and InputEvent.ALT_MASK should be used instead of ActionEvent.ALT_MASK. The corresponding InputEvent.ALT_GRAPH_MASK is already present. I used it by mistake last time.
>
>         I have made changes for JMenuItem I have changed BasicJMenuItemUI for JMenuItem and updated the test case too. Other changes are same as webrev.02. Please have a look.
>
>         Webrev:http://cr.openjdk.java.net/~pbansal/8194873/webrev.03/
>         <http://cr.openjdk.java.net/%7Epbansal/8194873/webrev.03/>
>
>         Regards,
>
>         Pankaj Bansal
>
>         -----Original Message-----
>
>         From: Prasanta Sadhukhan
>
>         Sent: Friday, April 20, 2018 5:04 PM
>
>         To: Pankaj Bansal
>
>         Cc:swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>
>         Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>
>         longer work in Swing components
>
>         Hi Pankaj,
>
>         On 4/20/2018 3:48 PM, Pankaj Bansal wrote:
>
>             Hi Prasanta,
>
>             In case of JMenuItem, there are two ways to add key shortcuts
>
>             1.
>
>             JMenuItem newMenuItem = new JMenuItem("New");
>
>              ?? newMenuItem.setMnemonic(KeyEvent.VK_N);
>
>             In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded.
>
>             2.
>
>             JMenuItem newMenuItem = new JMenuItem("New");
>
>             newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N,
>
>             ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded? in this case.
>
>         But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH.
>
>         Regards
>
>         Prasanta
>
>             Please let me know what do you think about this.
>
>             Regards,
>
>             Pankaj Bansal
>
>             -----Original Message-----
>
>             From: Prasanta Sadhukhan
>
>             Sent: Thursday, April 19, 2018 12:41 PM
>
>             To: Pankaj Bansal; Andrej Golovnin
>
>             Cc: Sergey Bylokhov;swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>
>             Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>
>             longer work in Swing components
>
>             Hi Pankaj,
>
>             looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works?
>
>             Regards
>
>             Prasanta
>
>             On 4/10/2018 3:15 PM, Pankaj Bansal wrote:
>
>                 Hello Andrej,
>
>                 Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out.
>
>                 Webrev:
>
>                 http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/
>                 <http://cr.openjdk.java.net/%7Epbansal/8194873/webrev.02/>
>
>                 Regards,
>
>                 Pankaj Bansal
>
>                 -----Original Message-----
>
>                 From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
>
>                 Sent: Tuesday, April 10, 2018 2:18 PM
>
>                 To: Pankaj Bansal
>
>                 Cc: Prasanta Sadhukhan; Sergey Bylokhov;swing-dev at openjdk.java.net
>                 <mailto:swing-dev at openjdk.java.net>
>
>                 Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>
>                 longer work in Swing components
>
>                 Hi Pankaj,
>
>                     Webrev:
>
>                     http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/
>                     <http://cr.openjdk.java.net/%7Epbansal/8194873/webrev.01/>
>
>                 src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>
>                 3540???????? BOOL altIsDown = ((modifiers &
>
>                 java_awt_event_InputEvent_ALT_DOWN_MASK) ||
>
>                 3541???????????????????????????? (modifiers &
>
>                 java_awt_event_InputEvent_ALT_DOWN_MASK));
>
>                 Applying '||' on the same value does not make sense. I think the
>
>                 line
>
>                 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK':
>
>                 3541???????????????????????????? (modifiers &
>
>                 java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK));
>
>                 Best regards,
>
>                 Andrej Golovnin
>

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

From takiguc at linux.vnet.ibm.com  Fri Jun 22 12:13:25 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 22 Jun 2018 21:13:25 +0900
Subject: <Swing Dev> Proposal: Reverse attribute remains incorrectly with
	Input Method
Message-ID: <c72de08ffbed6047f38286706a7cb230@linux.vnet.ibm.com>

Hello,
IBM would like to contribute a patch to OpenJDK project.

We'd like to propose a fix of Input Method relating problem.
Can we have a sponsor of the patch?

Problem:
When Input Method's preedit text and text selection were mixed, the 
reverse attribute of selection remained unexpectedly.

Recreate steps:
1. On Japanese locale, start Notepad java demo program
2. Type "123456", and move caret between "4" and "5"
3. Turn on Input Method. type "aiu" (Japanese characters) and keep 
preedit (without committing).
    ("123aiu456" should be displayed)
4. Drag (select) "aiu456" by mouse.
       (If you click out side of preedit text, it will be committed.)
5. Move focus to other window, then move the focus back.
    Preedit text was canceled, and the reverse attribute remained on 
"456".
6. Turn off Input Method, move caret before "1".
    The reverse attribute was cleared.
7. Type "0",  the reverse attribute was still remaining.
(With Input Method, the attribute can delete since preedit string has an 
attribute.)

Candidate fix:
----------
--- 
old/src/java.desktop/share/classes/javax/swing/text/JTextComponent.java  
       2018-06-22 21:01:05.367309169 +0900
+++ 
new/src/java.desktop/share/classes/javax/swing/text/JTextComponent.java  
       2018-06-22 21:01:04.745322344 +0900
@@ -5000,6 +5000,7 @@
              caret.setDot(dot);
          } else if (caret instanceof ComposedTextCaret) {
              dot = caret.getDot();
+            select(dot, dot);
              // Restores original caret
              exchangeCaret(caret, originalCaret);
              caret.setDot(dot);
----------

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.



From krishna.addepalli at oracle.com  Fri Jun 22 13:23:20 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 22 Jun 2018 06:23:20 -0700 (PDT)
Subject: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not
 working properly in multi screen environments
In-Reply-To: <e4c76f73-e5ae-4367-b7db-3d147999bd49@default>
References: <8f3e9dcc-1e44-4713-b8d5-a477d3887ee3@default>
 <e4c76f73-e5ae-4367-b7db-3d147999bd49@default>
Message-ID: <bd076ea0-da57-4d33-9044-0d48f18dc2f1@default>

Hi Sergey,

 

As per your comments, I have modified the patch to use Region.clipScale to do appropriate scaling calculation and adjustment.

Also, while running the testcase, I discovered that the -Dsun.java2d.uiScale=1.25 will uniformly apply the scaling across all the screens, whereas if the underlying monitor is not scaled, the results will be different.

Hence I modified the test to remove the uiScale settings related tests.

 

Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8176359/webrev01/

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, June 13, 2018 6:49 PM
To: swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not working properly in multi screen environments

 

One more question I forgot to ask:

4.       For running the test in different scaling modes, I have been manually changing the scaling values in the OS settings. However, I also have applied the -Dsun.java.uiScale vm parameter to run in different scaling modes. Is this equivalent to running the test in different scaling modes?

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, June 13, 2018 5:47 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not working properly in multi screen environments

 

Hi Sergey,

 

As per our conversation, please review a fix for 

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

Webrev: http://cr.openjdk.java.net/~kaddepalli/8176359/webrev00/

 

The problem is that when the secondary monitor is larger than the primary monitor, and the window needs to maximize onto the secondary screen, it results in wrong window sizes. 

The root cause is in WFramePeer::adjustMaximizedBounds, which tries to compensate the window bounds appropriately, but it is not adequate. It solves another related bug: JDK-6699851, but the requirement is that, for a window to be maximized even on a secondary screen, it still needs to provide the dimensions of the primary screen, and the Window Manager automatically compensates for the difference.

The proposed fix addresses this problem in both cases, but there are some more problems that were discovered on the way:

1.       The window bounds seem random (or atleast seem so), when maximized bounds that are larger than the primary screen bounds, but are smaller than the secondary screen bounds are provided. Unfortunately, there is no clear document/information regarding the way it is adjusted. The best I could get is this: https://blogs.msdn.microsoft.com/oldnewthing/20150501-00/?p=44964

2.       Scaling provides a new dimension of problems, and it seems hard to satisfy all the cases - due to the floating point computations. The proposed fix works for 100, 125, 150 and 175 % scalings, but again, it depends on the resolution of the monitors. 

3.       I have written a test case which tries to display maximized windows on each screen and tests if the bounds are proper. When I set the screen bounds as maximizedBounds, and then query the frame bounds post displaying the screen, they are not the same. However, I found that the contentPane bounds are closer, but still not exactly same. Is there something I'm missing?

 

Thanks,

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

From Sergey.Bylokhov at oracle.com  Fri Jun 22 19:50:28 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 22 Jun 2018 12:50:28 -0700
Subject: <Swing Dev> [11] Review Request: 8205454 &amp;
	is displayed in some Swing docs
Message-ID: <2cd04609-2c0a-db73-8030-985cd056690e@oracle.com>

Hello.
Please review the fix for jdk11.

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

A few typos were fixed.
  - In some cases it was caused by the JDK-8025230(L&amp;amp;F in the 
javadoc in JPanel.java).
  - The bug in javabeans descriptions was caused by the converting these 
lines from the javadoc to the text in annotation JDK-4763438.

-- 
Best regards, Sergey.


From philip.race at oracle.com  Fri Jun 22 20:25:19 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 22 Jun 2018 13:25:19 -0700
Subject: <Swing Dev> [11] Review Request: 8205454 &amp;
 is displayed in some Swing docs
In-Reply-To: <2cd04609-2c0a-db73-8030-985cd056690e@oracle.com>
References: <2cd04609-2c0a-db73-8030-985cd056690e@oracle.com>
Message-ID: <2d78cfc3-8a7a-d730-2a1e-6cd27794d7fe@oracle.com>

+1

-phil.

On 06/22/2018 12:50 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205454
> Webrev: http://cr.openjdk.java.net/~serb/8205454/webrev.00
>
> A few typos were fixed.
>  - In some cases it was caused by the JDK-8025230(L&amp;amp;F in the 
> javadoc in JPanel.java).
>  - The bug in javabeans descriptions was caused by the converting 
> these lines from the javadoc to the text in annotation JDK-4763438.
>



From Sergey.Bylokhov at oracle.com  Fri Jun 22 20:48:49 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 22 Jun 2018 13:48:49 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in
 "Classical" label in SwingSet2 demo with Windows L&F at Hidpi
In-Reply-To: <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>
References: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
 <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>
Message-ID: <59cf2392-2b07-e1a9-1632-271572829835@oracle.com>

Any volunteers for review?
=)

On 17/06/2018 15:37, Sergey Bylokhov wrote:
> Unfortunately after additional testing I found a bug in our text related 
> components. In the JTextPane the text looks broken if we request some 
> change in the component after it is became visible.
> 
> For example if we change the font then the text will be overlapping. So 
> if I will be applied this fix, which will force text component to 
> relayout(because of the change in graphics config), then the text will 
> be broken from the beginning.
> 
> But before the fix it will be broken only if the application will change 
> the pane after it became visible(BTW text rendering during editing is 
> broken in both cases).
> 
> So I temporary reverted the changes in the text related components:
> http://cr.openjdk.java.net/~serb/8201552/webrev.02
> 
> Two follow bugs were created:
>  ?- Text components: https://bugs.openjdk.java.net/browse/JDK-8205143
>  ?- JSpinner: https://bugs.openjdk.java.net/browse/JDK-8205144
> 
> On 15/06/2018 23:31, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk11.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
>> Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/
>>
>> Short description:
>> This fix enhance implementation of JDK-8178025[1] for most of our 
>> Swing components. The main rule which I tried to follow:
>> "If layout of the component depends from the font then it should 
>> depend on the current graphics configuration as well, because 
>> FontMetrics depends on graphics configuration".
>>
>> Long description:
>> The fix for JDK-8178025 added a special property 
>> "graphicsConfiguration" which: fired when the graphicsConfiguration is 
>> changed from one non-null value to another non-null value.
>> Those fix also updated some of the components(to refresh/re-validate 
>> its states when the "graphicsConfiguration" or "ancestor" were changed).
>>
>> The usage of "ancestor" was not obvious, so I modify the code to fire 
>> "graphicsConfiguration" every time, this cover a situation when the 
>> "GC=null" is changed to "GC=non-null"(previously it was covered by 
>> "ancestor" property). So after this fix our components will listen 
>> only "font" and "graphicsConfiguration".
>>
>> In implementation of JDK-8178025 the "graphicsConfiguration" is fired 
>> immediately after GC is changed, it caused the issues in some 
>> containers like JTree. When the container get such notification it 
>> usually tries to get some information from children, but in this 
>> moment children had previous graphic config, so the result 
>> calculated(and usually cached) in the container was wrong. In this fix 
>> I changed implementation of this property. Now it will fired only when 
>> the container and all its children are updated.
>>
>> ===
>> Note that the new test StalePreferredSize.java has a TODO block. 
>> Because JSpinner does not work properly even after the current fix. 
>> The reason is that during validation it is unexpectedly change the 
>> font from normal to bold(I'll fix this in a separate bug)
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8178025
>>
> 
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Fri Jun 22 21:09:27 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 22 Jun 2018 14:09:27 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in
 "Classical" label in SwingSet2 demo with Windows L&F at Hidpi
In-Reply-To: <59cf2392-2b07-e1a9-1632-271572829835@oracle.com>
References: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
 <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>
 <59cf2392-2b07-e1a9-1632-271572829835@oracle.com>
Message-ID: <9fbdf08a-6ff0-59c3-8877-4189e6fd0094@oracle.com>

The bug was seen when switching L&F .. how is that related to 
GraphicsConfiguration ?


-phil.

On 06/22/2018 01:48 PM, Sergey Bylokhov wrote:
> Any volunteers for review?
> =)
>
> On 17/06/2018 15:37, Sergey Bylokhov wrote:
>> Unfortunately after additional testing I found a bug in our text 
>> related components. In the JTextPane the text looks broken if we 
>> request some change in the component after it is became visible.
>>
>> For example if we change the font then the text will be overlapping. 
>> So if I will be applied this fix, which will force text component to 
>> relayout(because of the change in graphics config), then the text 
>> will be broken from the beginning.
>>
>> But before the fix it will be broken only if the application will 
>> change the pane after it became visible(BTW text rendering during 
>> editing is broken in both cases).
>>
>> So I temporary reverted the changes in the text related components:
>> http://cr.openjdk.java.net/~serb/8201552/webrev.02
>>
>> Two follow bugs were created:
>>   - Text components: https://bugs.openjdk.java.net/browse/JDK-8205143
>>   - JSpinner: https://bugs.openjdk.java.net/browse/JDK-8205144
>>
>> On 15/06/2018 23:31, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk11.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
>>> Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/
>>>
>>> Short description:
>>> This fix enhance implementation of JDK-8178025[1] for most of our 
>>> Swing components. The main rule which I tried to follow:
>>> "If layout of the component depends from the font then it should 
>>> depend on the current graphics configuration as well, because 
>>> FontMetrics depends on graphics configuration".
>>>
>>> Long description:
>>> The fix for JDK-8178025 added a special property 
>>> "graphicsConfiguration" which: fired when the graphicsConfiguration 
>>> is changed from one non-null value to another non-null value.
>>> Those fix also updated some of the components(to refresh/re-validate 
>>> its states when the "graphicsConfiguration" or "ancestor" were 
>>> changed).
>>>
>>> The usage of "ancestor" was not obvious, so I modify the code to 
>>> fire "graphicsConfiguration" every time, this cover a situation when 
>>> the "GC=null" is changed to "GC=non-null"(previously it was covered 
>>> by "ancestor" property). So after this fix our components will 
>>> listen only "font" and "graphicsConfiguration".
>>>
>>> In implementation of JDK-8178025 the "graphicsConfiguration" is 
>>> fired immediately after GC is changed, it caused the issues in some 
>>> containers like JTree. When the container get such notification it 
>>> usually tries to get some information from children, but in this 
>>> moment children had previous graphic config, so the result 
>>> calculated(and usually cached) in the container was wrong. In this 
>>> fix I changed implementation of this property. Now it will fired 
>>> only when the container and all its children are updated.
>>>
>>> ===
>>> Note that the new test StalePreferredSize.java has a TODO block. 
>>> Because JSpinner does not work properly even after the current fix. 
>>> The reason is that during validation it is unexpectedly change the 
>>> font from normal to bold(I'll fix this in a separate bug)
>>>
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178025
>>>
>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Fri Jun 22 21:40:10 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 22 Jun 2018 14:40:10 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in
 "Classical" label in SwingSet2 demo with Windows L&F at Hidpi
In-Reply-To: <9fbdf08a-6ff0-59c3-8877-4189e6fd0094@oracle.com>
References: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
 <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>
 <59cf2392-2b07-e1a9-1632-271572829835@oracle.com>
 <9fbdf08a-6ff0-59c3-8877-4189e6fd0094@oracle.com>
Message-ID: <b236a827-cbe7-3328-09f7-c891f28e3e7e@oracle.com>

On 22/06/2018 14:09, Phil Race wrote:
> The bug was seen when switching L&F .. how is that related to 
> GraphicsConfiguration ?

In the SwingSet2 the bug is visible only if the user switches the L&F 
immediately before switching to the tree demo. And is not reproduced if 
the user switches to the tree demo and then change the L&F.

  - If the tree is not visible then it will calculate the size of the 
text based on some default GC, and will not update this size when it 
will be added to the frame(which has another actual GC). So the tree 
will use the size calculated using one GC, and will draw the text using 
another GC. If the user will switch L&F the size will be recalculated 
using correct GraphicsConfiguration.


> 
> 
> -phil.
> 
> On 06/22/2018 01:48 PM, Sergey Bylokhov wrote:
>> Any volunteers for review?
>> =)
>>
>> On 17/06/2018 15:37, Sergey Bylokhov wrote:
>>> Unfortunately after additional testing I found a bug in our text 
>>> related components. In the JTextPane the text looks broken if we 
>>> request some change in the component after it is became visible.
>>>
>>> For example if we change the font then the text will be overlapping. 
>>> So if I will be applied this fix, which will force text component to 
>>> relayout(because of the change in graphics config), then the text 
>>> will be broken from the beginning.
>>>
>>> But before the fix it will be broken only if the application will 
>>> change the pane after it became visible(BTW text rendering during 
>>> editing is broken in both cases).
>>>
>>> So I temporary reverted the changes in the text related components:
>>> http://cr.openjdk.java.net/~serb/8201552/webrev.02
>>>
>>> Two follow bugs were created:
>>> ? - Text components: https://bugs.openjdk.java.net/browse/JDK-8205143
>>> ? - JSpinner: https://bugs.openjdk.java.net/browse/JDK-8205144
>>>
>>> On 15/06/2018 23:31, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk11.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
>>>> Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/
>>>>
>>>> Short description:
>>>> This fix enhance implementation of JDK-8178025[1] for most of our 
>>>> Swing components. The main rule which I tried to follow:
>>>> "If layout of the component depends from the font then it should 
>>>> depend on the current graphics configuration as well, because 
>>>> FontMetrics depends on graphics configuration".
>>>>
>>>> Long description:
>>>> The fix for JDK-8178025 added a special property 
>>>> "graphicsConfiguration" which: fired when the graphicsConfiguration 
>>>> is changed from one non-null value to another non-null value.
>>>> Those fix also updated some of the components(to refresh/re-validate 
>>>> its states when the "graphicsConfiguration" or "ancestor" were 
>>>> changed).
>>>>
>>>> The usage of "ancestor" was not obvious, so I modify the code to 
>>>> fire "graphicsConfiguration" every time, this cover a situation when 
>>>> the "GC=null" is changed to "GC=non-null"(previously it was covered 
>>>> by "ancestor" property). So after this fix our components will 
>>>> listen only "font" and "graphicsConfiguration".
>>>>
>>>> In implementation of JDK-8178025 the "graphicsConfiguration" is 
>>>> fired immediately after GC is changed, it caused the issues in some 
>>>> containers like JTree. When the container get such notification it 
>>>> usually tries to get some information from children, but in this 
>>>> moment children had previous graphic config, so the result 
>>>> calculated(and usually cached) in the container was wrong. In this 
>>>> fix I changed implementation of this property. Now it will fired 
>>>> only when the container and all its children are updated.
>>>>
>>>> ===
>>>> Note that the new test StalePreferredSize.java has a TODO block. 
>>>> Because JSpinner does not work properly even after the current fix. 
>>>> The reason is that during validation it is unexpectedly change the 
>>>> font from normal to bold(I'll fix this in a separate bug)
>>>>
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178025
>>>>
>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Fri Jun 22 23:16:23 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 22 Jun 2018 16:16:23 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in
 "Classical" label in SwingSet2 demo with Windows L&F at Hidpi
In-Reply-To: <b236a827-cbe7-3328-09f7-c891f28e3e7e@oracle.com>
References: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
 <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>
 <59cf2392-2b07-e1a9-1632-271572829835@oracle.com>
 <9fbdf08a-6ff0-59c3-8877-4189e6fd0094@oracle.com>
 <b236a827-cbe7-3328-09f7-c891f28e3e7e@oracle.com>
Message-ID: <213ce865-3293-7008-00d9-99054950af6f@oracle.com>

The place where the current graphicsConfiguration of the component is 
matter:
  - JComponent.getFontMetrics(Font)
  -- SwingUtilities2.getFontMetrics(this, font)
  --- SwingUtilities2.getFRCProperty(JComponent c)

     if (c != null) {
         GraphicsConfiguration gc = c.getGraphicsConfiguration();
         AffineTransform tx = (gc == null) ? null : 
gc.getDefaultTransform();
         Object aaHint = c.getClientProperty(KEY_TEXT_ANTIALIASING);
         return getFRCFromCache(tx, aaHint);
     }

When the bug is reproduced we calculated the size of the tree based on 
one GC and draw it using another GC. The first GC which is used for size 
calculation may be null or it maybe a non-null value pointed to another 
screen, for example if the jtree was shown on one screen and then 
dragged to another.

On 22/06/2018 14:40, Sergey Bylokhov wrote:
> In the SwingSet2 the bug is visible only if the user switches the L&F 
> immediately before switching to the tree demo. And is not reproduced if 
> the user switches to the tree demo and then change the L&F.
> 
>  ?- If the tree is not visible then it will calculate the size of the 
> text based on some default GC, and will not update this size when it 
> will be added to the frame(which has another actual GC). So the tree 
> will use the size calculated using one GC, and will draw the text using 
> another GC. If the user will switch L&F the size will be recalculated 
> using correct GraphicsConfiguration.
> 
> 
>>
>>
>> -phil.
>>
>> On 06/22/2018 01:48 PM, Sergey Bylokhov wrote:
>>> Any volunteers for review?
>>> =)
>>>
>>> On 17/06/2018 15:37, Sergey Bylokhov wrote:
>>>> Unfortunately after additional testing I found a bug in our text 
>>>> related components. In the JTextPane the text looks broken if we 
>>>> request some change in the component after it is became visible.
>>>>
>>>> For example if we change the font then the text will be overlapping. 
>>>> So if I will be applied this fix, which will force text component to 
>>>> relayout(because of the change in graphics config), then the text 
>>>> will be broken from the beginning.
>>>>
>>>> But before the fix it will be broken only if the application will 
>>>> change the pane after it became visible(BTW text rendering during 
>>>> editing is broken in both cases).
>>>>
>>>> So I temporary reverted the changes in the text related components:
>>>> http://cr.openjdk.java.net/~serb/8201552/webrev.02
>>>>
>>>> Two follow bugs were created:
>>>> ? - Text components: https://bugs.openjdk.java.net/browse/JDK-8205143
>>>> ? - JSpinner: https://bugs.openjdk.java.net/browse/JDK-8205144
>>>>
>>>> On 15/06/2018 23:31, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review the fix for jdk11.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
>>>>> Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/
>>>>>
>>>>> Short description:
>>>>> This fix enhance implementation of JDK-8178025[1] for most of our 
>>>>> Swing components. The main rule which I tried to follow:
>>>>> "If layout of the component depends from the font then it should 
>>>>> depend on the current graphics configuration as well, because 
>>>>> FontMetrics depends on graphics configuration".
>>>>>
>>>>> Long description:
>>>>> The fix for JDK-8178025 added a special property 
>>>>> "graphicsConfiguration" which: fired when the graphicsConfiguration 
>>>>> is changed from one non-null value to another non-null value.
>>>>> Those fix also updated some of the components(to 
>>>>> refresh/re-validate its states when the "graphicsConfiguration" or 
>>>>> "ancestor" were changed).
>>>>>
>>>>> The usage of "ancestor" was not obvious, so I modify the code to 
>>>>> fire "graphicsConfiguration" every time, this cover a situation 
>>>>> when the "GC=null" is changed to "GC=non-null"(previously it was 
>>>>> covered by "ancestor" property). So after this fix our components 
>>>>> will listen only "font" and "graphicsConfiguration".
>>>>>
>>>>> In implementation of JDK-8178025 the "graphicsConfiguration" is 
>>>>> fired immediately after GC is changed, it caused the issues in some 
>>>>> containers like JTree. When the container get such notification it 
>>>>> usually tries to get some information from children, but in this 
>>>>> moment children had previous graphic config, so the result 
>>>>> calculated(and usually cached) in the container was wrong. In this 
>>>>> fix I changed implementation of this property. Now it will fired 
>>>>> only when the container and all its children are updated.
>>>>>
>>>>> ===
>>>>> Note that the new test StalePreferredSize.java has a TODO block. 
>>>>> Because JSpinner does not work properly even after the current fix. 
>>>>> The reason is that during validation it is unexpectedly change the 
>>>>> font from normal to bold(I'll fix this in a separate bug)
>>>>>
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178025
>>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Fri Jun 22 23:54:49 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 22 Jun 2018 16:54:49 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in
 "Classical" label in SwingSet2 demo with Windows L&F at Hidpi
In-Reply-To: <213ce865-3293-7008-00d9-99054950af6f@oracle.com>
References: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
 <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>
 <59cf2392-2b07-e1a9-1632-271572829835@oracle.com>
 <9fbdf08a-6ff0-59c3-8877-4189e6fd0094@oracle.com>
 <b236a827-cbe7-3328-09f7-c891f28e3e7e@oracle.com>
 <213ce865-3293-7008-00d9-99054950af6f@oracle.com>
Message-ID: <5B2D8C49.1070607@oracle.com>

It is not really the GC .. there is no GC .. but because of that the
code uses a default FontRenderContext.

I think Swing is conflating GC + FRC but given that, then the logic
to recalculate based on graphicsconfiguration should be fine, although
maybe you can check if we really need to trigger it ..
if the screen we are shown on has no scale (ie uiScale == 1) then
we may be triggering a pointless invalidation with consequent overhead.
Can  you check if we can skip it in some cases ?

-phil.

On 6/22/18, 4:16 PM, Sergey Bylokhov wrote:
> The place where the current graphicsConfiguration of the component is 
> matter:
>  - JComponent.getFontMetrics(Font)
>  -- SwingUtilities2.getFontMetrics(this, font)
>  --- SwingUtilities2.getFRCProperty(JComponent c)
>
>     if (c != null) {
>         GraphicsConfiguration gc = c.getGraphicsConfiguration();
>         AffineTransform tx = (gc == null) ? null : 
> gc.getDefaultTransform();
>         Object aaHint = c.getClientProperty(KEY_TEXT_ANTIALIASING);
>         return getFRCFromCache(tx, aaHint);
>     }
>
> When the bug is reproduced we calculated the size of the tree based on 
> one GC and draw it using another GC. The first GC which is used for 
> size calculation may be null or it maybe a non-null value pointed to 
> another screen, for example if the jtree was shown on one screen and 
> then dragged to another.
>
> On 22/06/2018 14:40, Sergey Bylokhov wrote:
>> In the SwingSet2 the bug is visible only if the user switches the L&F 
>> immediately before switching to the tree demo. And is not reproduced 
>> if the user switches to the tree demo and then change the L&F.
>>
>>   - If the tree is not visible then it will calculate the size of the 
>> text based on some default GC, and will not update this size when it 
>> will be added to the frame(which has another actual GC). So the tree 
>> will use the size calculated using one GC, and will draw the text 
>> using another GC. If the user will switch L&F the size will be 
>> recalculated using correct GraphicsConfiguration.
>>
>>
>>>
>>>
>>> -phil.
>>>
>>> On 06/22/2018 01:48 PM, Sergey Bylokhov wrote:
>>>> Any volunteers for review?
>>>> =)
>>>>
>>>> On 17/06/2018 15:37, Sergey Bylokhov wrote:
>>>>> Unfortunately after additional testing I found a bug in our text 
>>>>> related components. In the JTextPane the text looks broken if we 
>>>>> request some change in the component after it is became visible.
>>>>>
>>>>> For example if we change the font then the text will be 
>>>>> overlapping. So if I will be applied this fix, which will force 
>>>>> text component to relayout(because of the change in graphics 
>>>>> config), then the text will be broken from the beginning.
>>>>>
>>>>> But before the fix it will be broken only if the application will 
>>>>> change the pane after it became visible(BTW text rendering during 
>>>>> editing is broken in both cases).
>>>>>
>>>>> So I temporary reverted the changes in the text related components:
>>>>> http://cr.openjdk.java.net/~serb/8201552/webrev.02
>>>>>
>>>>> Two follow bugs were created:
>>>>>   - Text components: https://bugs.openjdk.java.net/browse/JDK-8205143
>>>>>   - JSpinner: https://bugs.openjdk.java.net/browse/JDK-8205144
>>>>>
>>>>> On 15/06/2018 23:31, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review the fix for jdk11.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/
>>>>>>
>>>>>> Short description:
>>>>>> This fix enhance implementation of JDK-8178025[1] for most of our 
>>>>>> Swing components. The main rule which I tried to follow:
>>>>>> "If layout of the component depends from the font then it should 
>>>>>> depend on the current graphics configuration as well, because 
>>>>>> FontMetrics depends on graphics configuration".
>>>>>>
>>>>>> Long description:
>>>>>> The fix for JDK-8178025 added a special property 
>>>>>> "graphicsConfiguration" which: fired when the 
>>>>>> graphicsConfiguration is changed from one non-null value to 
>>>>>> another non-null value.
>>>>>> Those fix also updated some of the components(to 
>>>>>> refresh/re-validate its states when the "graphicsConfiguration" 
>>>>>> or "ancestor" were changed).
>>>>>>
>>>>>> The usage of "ancestor" was not obvious, so I modify the code to 
>>>>>> fire "graphicsConfiguration" every time, this cover a situation 
>>>>>> when the "GC=null" is changed to "GC=non-null"(previously it was 
>>>>>> covered by "ancestor" property). So after this fix our components 
>>>>>> will listen only "font" and "graphicsConfiguration".
>>>>>>
>>>>>> In implementation of JDK-8178025 the "graphicsConfiguration" is 
>>>>>> fired immediately after GC is changed, it caused the issues in 
>>>>>> some containers like JTree. When the container get such 
>>>>>> notification it usually tries to get some information from 
>>>>>> children, but in this moment children had previous graphic 
>>>>>> config, so the result calculated(and usually cached) in the 
>>>>>> container was wrong. In this fix I changed implementation of this 
>>>>>> property. Now it will fired only when the container and all its 
>>>>>> children are updated.
>>>>>>
>>>>>> ===
>>>>>> Note that the new test StalePreferredSize.java has a TODO block. 
>>>>>> Because JSpinner does not work properly even after the current 
>>>>>> fix. The reason is that during validation it is unexpectedly 
>>>>>> change the font from normal to bold(I'll fix this in a separate bug)
>>>>>>
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178025
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>


From pankaj.b.bansal at oracle.com  Sat Jun 23 16:32:10 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Sat, 23 Jun 2018 09:32:10 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <13ade394-f7f8-1d94-28cd-ea3365bbbf43@oracle.com>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
 <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>
 <42a16319-9b11-45b8-b429-46bc90fb0c5c@default>
 <CAM6ZMz_a=92wmpw9QE1WS0U9d8f1OjjhkidbrvVBGHVVkrTrXg@mail.gmail.com>
 <ffd3977e-5944-4911-8e17-75d3f1ee2900@default>
 <dcb9b0f3-2839-ce12-d43d-3ef9c1823014@oracle.com>
 <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default>
 <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
 <caf48671-8e20-4d19-9962-7f58e342408c@default>
 <d0b6a082-2f43-9cac-6454-378b1ef8fe4a@oracle.com>
 <ef428376-62ba-46b0-bf5b-131ed13e32a0@default>
 <13ade394-f7f8-1d94-28cd-ea3365bbbf43@oracle.com>
Message-ID: <728647c0-cdf7-483c-80e8-56003356cbe0@default>

Hi Sergey,

<< This looks fine to me, the only suggestion is to try to extract the common code to some new method in SwingUtil2.
Please have a look at the following code. I have added a function to set the ALT_GRAPH mask on any modifier passed to it.
Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.06/


Regards
Pankaj Bansal

-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, June 22, 2018 5:13 AM
To: Pankaj Bansal; Prasanta Sadhukhan
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components

This looks fine to me, the only suggestion is to try to extract the common code to some new method in SwingUtil2.

On 21/06/2018 05:25, Pankaj Bansal wrote:
> Hi Prasanta/Sergey
> 
> @Prasanta
> << The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
> Sorry I think I was testing by printing log on console instead of throwing exceptions and I made webrev with that version. I have corrected it now. The test fails without fix and passes with fix on Windows 10.
> 
> @Sergey
> << Is this bug applicable only to windows? can we make the test non-windows specific?
> Yes, I think this bug addresses the regression introduced when the fix was made for https://bugs.openjdk.java.net/browse/JDK-8041928. Both ALT and ALT_GRAPH keys work on Windows. The test added fails on linux and mac both with and without fix. I think the ALT_GRAPH key does not work on these platforms and it is not related to the regression being addressed here. We can file separate bug to investigate that. Please let me know what do you think regarding this.
> 
> I have run possible affected jck tests on Windows and all the automated event tests in awt/swing jtreg tests on Windows, Linux  and Mac. The fix is not producing any regression.
> 
> webrev:
> http://cr.openjdk.java.net/~pbansal/8194873/webrev.04/
> 
> 
> Thanks,
> Pankj Bansal
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Thursday, June 21, 2018 11:58 AM
> To: Pankaj Bansal
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
> longer work in Swing components
> 
> Hi Pankaj,
> 
> The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
> 
> Regards
> Prasanta
> On 6/20/2018 8:22 PM, Pankaj Bansal wrote:
>> Hi Prasanta,
>>
>> I looked at documentation of KeyStroke.getKeyStroke and InputEvent.ALT_MASK should be used instead of ActionEvent.ALT_MASK. The corresponding InputEvent.ALT_GRAPH_MASK is already present. I used it by mistake last time.
>> I have made changes for JMenuItem I have changed BasicJMenuItemUI for JMenuItem and updated the test case too. Other changes are same as webrev.02. Please have a look.
>> Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.03/
>>
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Prasanta Sadhukhan
>> Sent: Friday, April 20, 2018 5:04 PM
>> To: Pankaj Bansal
>> Cc: swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
>> longer work in Swing components
>>
>> Hi Pankaj,
>>
>>
>> On 4/20/2018 3:48 PM, Pankaj Bansal wrote:
>>> Hi Prasanta,
>>>
>>> In case of JMenuItem, there are two ways to add key shortcuts
>>>
>>> 1.
>>> JMenuItem newMenuItem = new JMenuItem("New");
>>>     newMenuItem.setMnemonic(KeyEvent.VK_N);
>>> In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded.
>>>
>>> 2.
>>> JMenuItem newMenuItem = new JMenuItem("New"); 
>>> newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N, 
>>> ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded  in this case.
>> But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH.
>>
>> Regards
>> Prasanta
>>> Please let me know what do you think about this.
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>> -----Original Message-----
>>> From: Prasanta Sadhukhan
>>> Sent: Thursday, April 19, 2018 12:41 PM
>>> To: Pankaj Bansal; Andrej Golovnin
>>> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
>>> longer work in Swing components
>>>
>>> Hi Pankaj,
>>>
>>> looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works?
>>>
>>> Regards
>>> Prasanta
>>> On 4/10/2018 3:15 PM, Pankaj Bansal wrote:
>>>> Hello Andrej,
>>>>
>>>> Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out.
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/
>>>>
>>>>
>>>> Regards,
>>>> Pankaj Bansal
>>>>
>>>> -----Original Message-----
>>>> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
>>>> Sent: Tuesday, April 10, 2018 2:18 PM
>>>> To: Pankaj Bansal
>>>> Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net
>>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no 
>>>> longer work in Swing components
>>>>
>>>> Hi Pankaj,
>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/
>>>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>>
>>>> 3540         BOOL altIsDown = ((modifiers &
>>>> java_awt_event_InputEvent_ALT_DOWN_MASK) ||
>>>> 3541                             (modifiers &
>>>> java_awt_event_InputEvent_ALT_DOWN_MASK));
>>>>
>>>> Applying '||' on the same value does not make sense. I think the 
>>>> line
>>>> 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK':
>>>>
>>>> 3541                             (modifiers &
>>>> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK));
>>>>
>>>> Best regards,
>>>> Andrej Golovnin
> 


--
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Sun Jun 24 23:05:02 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 24 Jun 2018 16:05:02 -0700
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <728647c0-cdf7-483c-80e8-56003356cbe0@default>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
 <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>
 <42a16319-9b11-45b8-b429-46bc90fb0c5c@default>
 <CAM6ZMz_a=92wmpw9QE1WS0U9d8f1OjjhkidbrvVBGHVVkrTrXg@mail.gmail.com>
 <ffd3977e-5944-4911-8e17-75d3f1ee2900@default>
 <dcb9b0f3-2839-ce12-d43d-3ef9c1823014@oracle.com>
 <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default>
 <fab15cf3-86cc-9a3d-6934-bfcc9d074728@oracle.com>
 <caf48671-8e20-4d19-9962-7f58e342408c@default>
 <d0b6a082-2f43-9cac-6454-378b1ef8fe4a@oracle.com>
 <ef428376-62ba-46b0-bf5b-131ed13e32a0@default>
 <13ade394-f7f8-1d94-28cd-ea3365bbbf43@oracle.com>
 <728647c0-cdf7-483c-80e8-56003356cbe0@default>
Message-ID: <ad95659b-6486-208e-bcd3-a91e0855c54c@oracle.com>

Looks fine.

On 23/06/2018 09:32, Pankaj Bansal wrote:
> Hi Sergey,
> 
> << This looks fine to me, the only suggestion is to try to extract the common code to some new method in SwingUtil2.
> Please have a look at the following code. I have added a function to set the ALT_GRAPH mask on any modifier passed to it.
> Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.06/
> 
> 
> Regards
> Pankaj Bansal
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Friday, June 22, 2018 5:13 AM
> To: Pankaj Bansal; Prasanta Sadhukhan
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components
> 
> This looks fine to me, the only suggestion is to try to extract the common code to some new method in SwingUtil2.
> 
> On 21/06/2018 05:25, Pankaj Bansal wrote:
>> Hi Prasanta/Sergey
>>
>> @Prasanta
>> << The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
>> Sorry I think I was testing by printing log on console instead of throwing exceptions and I made webrev with that version. I have corrected it now. The test fails without fix and passes with fix on Windows 10.
>>
>> @Sergey
>> << Is this bug applicable only to windows? can we make the test non-windows specific?
>> Yes, I think this bug addresses the regression introduced when the fix was made for https://bugs.openjdk.java.net/browse/JDK-8041928. Both ALT and ALT_GRAPH keys work on Windows. The test added fails on linux and mac both with and without fix. I think the ALT_GRAPH key does not work on these platforms and it is not related to the regression being addressed here. We can file separate bug to investigate that. Please let me know what do you think regarding this.
>>
>> I have run possible affected jck tests on Windows and all the automated event tests in awt/swing jtreg tests on Windows, Linux  and Mac. The fix is not producing any regression.
>>
>> webrev:
>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.04/
>>
>>
>> Thanks,
>> Pankj Bansal
>> -----Original Message-----
>> From: Prasanta Sadhukhan
>> Sent: Thursday, June 21, 2018 11:58 AM
>> To: Pankaj Bansal
>> Cc: swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>> longer work in Swing components
>>
>> Hi Pankaj,
>>
>> The test passed for me in windows 10 even without your fix and the test frames and dialogs are kept visible even after the test finished. Please have a look.
>>
>> Regards
>> Prasanta
>> On 6/20/2018 8:22 PM, Pankaj Bansal wrote:
>>> Hi Prasanta,
>>>
>>> I looked at documentation of KeyStroke.getKeyStroke and InputEvent.ALT_MASK should be used instead of ActionEvent.ALT_MASK. The corresponding InputEvent.ALT_GRAPH_MASK is already present. I used it by mistake last time.
>>> I have made changes for JMenuItem I have changed BasicJMenuItemUI for JMenuItem and updated the test case too. Other changes are same as webrev.02. Please have a look.
>>> Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.03/
>>>
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>> -----Original Message-----
>>> From: Prasanta Sadhukhan
>>> Sent: Friday, April 20, 2018 5:04 PM
>>> To: Pankaj Bansal
>>> Cc: swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>>> longer work in Swing components
>>>
>>> Hi Pankaj,
>>>
>>>
>>> On 4/20/2018 3:48 PM, Pankaj Bansal wrote:
>>>> Hi Prasanta,
>>>>
>>>> In case of JMenuItem, there are two ways to add key shortcuts
>>>>
>>>> 1.
>>>> JMenuItem newMenuItem = new JMenuItem("New");
>>>>      newMenuItem.setMnemonic(KeyEvent.VK_N);
>>>> In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded.
>>>>
>>>> 2.
>>>> JMenuItem newMenuItem = new JMenuItem("New");
>>>> newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N,
>>>> ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded  in this case.
>>> But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH.
>>>
>>> Regards
>>> Prasanta
>>>> Please let me know what do you think about this.
>>>>
>>>> Regards,
>>>> Pankaj Bansal
>>>>
>>>> -----Original Message-----
>>>> From: Prasanta Sadhukhan
>>>> Sent: Thursday, April 19, 2018 12:41 PM
>>>> To: Pankaj Bansal; Andrej Golovnin
>>>> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net
>>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>>>> longer work in Swing components
>>>>
>>>> Hi Pankaj,
>>>>
>>>> looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works?
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 4/10/2018 3:15 PM, Pankaj Bansal wrote:
>>>>> Hello Andrej,
>>>>>
>>>>> Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out.
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/
>>>>>
>>>>>
>>>>> Regards,
>>>>> Pankaj Bansal
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
>>>>> Sent: Tuesday, April 10, 2018 2:18 PM
>>>>> To: Pankaj Bansal
>>>>> Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net
>>>>> Subject: Re: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no
>>>>> longer work in Swing components
>>>>>
>>>>> Hi Pankaj,
>>>>>
>>>>>> Webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/
>>>>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>>>
>>>>> 3540         BOOL altIsDown = ((modifiers &
>>>>> java_awt_event_InputEvent_ALT_DOWN_MASK) ||
>>>>> 3541                             (modifiers &
>>>>> java_awt_event_InputEvent_ALT_DOWN_MASK));
>>>>>
>>>>> Applying '||' on the same value does not make sense. I think the
>>>>> line
>>>>> 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK':
>>>>>
>>>>> 3541                             (modifiers &
>>>>> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK));
>>>>>
>>>>> Best regards,
>>>>> Andrej Golovnin
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Mon Jun 25 06:01:13 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 25 Jun 2018 11:31:13 +0530
Subject: <Swing Dev> [11] Review Request: 8205454 &amp;
 is displayed in some Swing docs
In-Reply-To: <2cd04609-2c0a-db73-8030-985cd056690e@oracle.com>
References: <2cd04609-2c0a-db73-8030-985cd056690e@oracle.com>
Message-ID: <f2366c8b-cbec-9993-00de-f8c68bef501e@oracle.com>

+1

Regards
Prasanta
On 6/23/2018 1:20 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205454
> Webrev: http://cr.openjdk.java.net/~serb/8205454/webrev.00
>
> A few typos were fixed.
> ?- In some cases it was caused by the JDK-8025230(L&amp;amp;F in the 
> javadoc in JPanel.java).
> ?- The bug in javabeans descriptions was caused by the converting 
> these lines from the javadoc to the text in annotation JDK-4763438.
>



From philip.race at oracle.com  Mon Jun 25 22:26:00 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 25 Jun 2018 15:26:00 -0700
Subject: <Swing Dev> JDK 11 RDP1 and the jdk/client repository
Message-ID: <5B316BF8.7030500@oracle.com>

I want to make sure people understand some of the nuances of RDP1 for 
JDK 11 [1]

- Any fix pushed to jdk/client after 2am PT Tue 26th June will be 
destined for JDK 12. Not JDK 11

- That is because this is the time we start the build for the final JDK 
11 Client PIT
   (PIT == Pre-Integration Testing), since changes need to be in jdk/jdk 
by Wed 27th.

- JDK 11 P1-P3 bugs may still be fixed after that date by pushing 
*directly* to the JDK 11
   stabilisation forest, which will be created after the fork. So if you 
have a fix for JDK 11 that
   misses 2am on the 26th you will need to wait for the stabilisation 
forest to open before pushing it.

- Fixes pushed to the JDK 11 stabilisation forest will be automatically 
synced to JDK 12 for some time,
    so if you want to fix something in 11 during RDP1, you do not need 
push it to jdk/client first,
    in fact you should not, because it is expected to be forward synced.

- Because there is only ONE stabilisation forest for all JDK 11, and NO 
further JDK 11 client PITs,
  it means the onus will be on the fixer to make sure they
    + do not break the build
    + do not introduce any regressions.
    + are fixing only bugs that really need to be in JDK 11 (proper use 
of P1-P3).

-phil.

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001462.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180625/9a9dfbd5/attachment.html>

From javalists at cbfiddle.com  Tue Jun 26 14:58:17 2018
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 26 Jun 2018 07:58:17 -0700
Subject: <Swing Dev> JDesktopPane and menu bars
Message-ID: <20D379CE-1322-4D44-BF20-C2EC3F3EC586@cbfiddle.com>

I gather from recent bug fixes that JDesktopPane is being used, but I don?t have a feel for how it is being used. Can someone explain?

My specific question: if a JInternalFrame is used on macOS and the screen menu bar is enabled for Java, should the frame menu bar be displayed in the frame or should it hook to the screen menu bar?

I have a test program that displays Swing components using a variety of LAFs. In this program, the menu bar is displayed in the frame, which is fine for my purposes.

But, what answer makes the most sense in the context of actual use?

Regards,

  Alan



From Sergey.Bylokhov at oracle.com  Tue Jun 26 22:03:27 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 26 Jun 2018 15:03:27 -0700
Subject: <Swing Dev> JDesktopPane and menu bars
In-Reply-To: <20D379CE-1322-4D44-BF20-C2EC3F3EC586@cbfiddle.com>
References: <20D379CE-1322-4D44-BF20-C2EC3F3EC586@cbfiddle.com>
Message-ID: <59bfc342-154d-61e0-2722-9fe2bcb0851e@oracle.com>

Hi, Alan.
I think this use case is not specified and it was implemented in the 
same way as it works in jdk 6 from Apple.

On 26/06/2018 07:58, Alan Snyder wrote:
> I gather from recent bug fixes that JDesktopPane is being used, but I don?t have a feel for how it is being used. Can someone explain?
> 
> My specific question: if a JInternalFrame is used on macOS and the screen menu bar is enabled for Java, should the frame menu bar be displayed in the frame or should it hook to the screen menu bar?
> 
> I have a test program that displays Swing components using a variety of LAFs. In this program, the menu bar is displayed in the frame, which is fine for my purposes.
> 
> But, what answer makes the most sense in the context of actual use?
> 
> Regards,
> 
>    Alan
> 


-- 
Best regards, Sergey.


From krishna.addepalli at oracle.com  Thu Jun 28 09:36:23 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 28 Jun 2018 02:36:23 -0700 (PDT)
Subject: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not
 working properly in multi screen environments
In-Reply-To: <bd076ea0-da57-4d33-9044-0d48f18dc2f1@default>
References: <8f3e9dcc-1e44-4713-b8d5-a477d3887ee3@default>
 <e4c76f73-e5ae-4367-b7db-3d147999bd49@default>
 <bd076ea0-da57-4d33-9044-0d48f18dc2f1@default>
Message-ID: <532cd16e-592b-456e-8c5f-afa1ee0051c8@default>

Hi Sergey,

 

Could you approve this webrev as per our conversation?

 

@All,

 

I need one more review for pushing.

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Friday, June 22, 2018 6:53 PM
To: swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not working properly in multi screen environments

 

Hi Sergey,

 

As per your comments, I have modified the patch to use Region.clipScale to do appropriate scaling calculation and adjustment.

Also, while running the testcase, I discovered that the -Dsun.java2d.uiScale=1.25 will uniformly apply the scaling across all the screens, whereas if the underlying monitor is not scaled, the results will be different.

Hence I modified the test to remove the uiScale settings related tests.

 

Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8176359/webrev01/

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, June 13, 2018 6:49 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not working properly in multi screen environments

 

One more question I forgot to ask:

4.       For running the test in different scaling modes, I have been manually changing the scaling values in the OS settings. However, I also have applied the -Dsun.java.uiScale vm parameter to run in different scaling modes. Is this equivalent to running the test in different scaling modes?

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, June 13, 2018 5:47 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not working properly in multi screen environments

 

Hi Sergey,

 

As per our conversation, please review a fix for 

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

Webrev: http://cr.openjdk.java.net/~kaddepalli/8176359/webrev00/

 

The problem is that when the secondary monitor is larger than the primary monitor, and the window needs to maximize onto the secondary screen, it results in wrong window sizes. 

The root cause is in WFramePeer::adjustMaximizedBounds, which tries to compensate the window bounds appropriately, but it is not adequate. It solves another related bug: JDK-6699851, but the requirement is that, for a window to be maximized even on a secondary screen, it still needs to provide the dimensions of the primary screen, and the Window Manager automatically compensates for the difference.

The proposed fix addresses this problem in both cases, but there are some more problems that were discovered on the way:

1.       The window bounds seem random (or atleast seem so), when maximized bounds that are larger than the primary screen bounds, but are smaller than the secondary screen bounds are provided. Unfortunately, there is no clear document/information regarding the way it is adjusted. The best I could get is this: https://blogs.msdn.microsoft.com/oldnewthing/20150501-00/?p=44964

2.       Scaling provides a new dimension of problems, and it seems hard to satisfy all the cases - due to the floating point computations. The proposed fix works for 100, 125, 150 and 175 % scalings, but again, it depends on the resolution of the monitors. 

3.       I have written a test case which tries to display maximized windows on each screen and tests if the bounds are proper. When I set the screen bounds as maximizedBounds, and then query the frame bounds post displaying the screen, they are not the same. However, I found that the contentPane bounds are closer, but still not exactly same. Is there something I'm missing?

 

Thanks,

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

From Sergey.Bylokhov at oracle.com  Thu Jun 28 20:54:23 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 28 Jun 2018 13:54:23 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in
 "Classical" label in SwingSet2 demo with Windows L&F at Hidpi
In-Reply-To: <5B2D8C49.1070607@oracle.com>
References: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
 <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>
 <59cf2392-2b07-e1a9-1632-271572829835@oracle.com>
 <9fbdf08a-6ff0-59c3-8877-4189e6fd0094@oracle.com>
 <b236a827-cbe7-3328-09f7-c891f28e3e7e@oracle.com>
 <213ce865-3293-7008-00d9-99054950af6f@oracle.com>
 <5B2D8C49.1070607@oracle.com>
Message-ID: <8bd9ccd2-3c76-ffa6-6028-e17ea5c117ec@oracle.com>

Hi, Phil.
The new webrev:
http://cr.openjdk.java.net/~serb/8201552/webrev.03/

I have checked why validation of the component is necessary, when the 
"ancestor" is changed (I removed it, but the new validation on GC change 
null->non-null is equivalent).

Such validation is used as a last chance to update the state of the 
component before show it to the user. In theory it is not necessary but 
some components skips validation on font change(like jtree) and maybe 
other properties. I have files a separate bug for that: 
https://bugs.openjdk.java.net/browse/JDK-8206024

  - In the fix I have moved these checks to SwingU2.
  - TODO block for JSpinner: is removed because this bug was fixed
https://bugs.openjdk.java.net/browse/JDK-8205144

On 22/06/2018 16:54, Philip Race wrote:
> It is not really the GC .. there is no GC .. but because of that the
> code uses a default FontRenderContext.
> 
> I think Swing is conflating GC + FRC but given that, then the logic
> to recalculate based on graphicsconfiguration should be fine, although
> maybe you can check if we really need to trigger it ..
> if the screen we are shown on has no scale (ie uiScale == 1) then
> we may be triggering a pointless invalidation with consequent overhead.
> Can? you check if we can skip it in some cases ?
> 
> -phil.
> 
> On 6/22/18, 4:16 PM, Sergey Bylokhov wrote:
>> The place where the current graphicsConfiguration of the component is 
>> matter:
>> ?- JComponent.getFontMetrics(Font)
>> ?-- SwingUtilities2.getFontMetrics(this, font)
>> ?--- SwingUtilities2.getFRCProperty(JComponent c)
>>
>> ??? if (c != null) {
>> ??????? GraphicsConfiguration gc = c.getGraphicsConfiguration();
>> ??????? AffineTransform tx = (gc == null) ? null : 
>> gc.getDefaultTransform();
>> ??????? Object aaHint = c.getClientProperty(KEY_TEXT_ANTIALIASING);
>> ??????? return getFRCFromCache(tx, aaHint);
>> ??? }
>>
>> When the bug is reproduced we calculated the size of the tree based on 
>> one GC and draw it using another GC. The first GC which is used for 
>> size calculation may be null or it maybe a non-null value pointed to 
>> another screen, for example if the jtree was shown on one screen and 
>> then dragged to another.
>>
>> On 22/06/2018 14:40, Sergey Bylokhov wrote:
>>> In the SwingSet2 the bug is visible only if the user switches the L&F 
>>> immediately before switching to the tree demo. And is not reproduced 
>>> if the user switches to the tree demo and then change the L&F.
>>>
>>> ? - If the tree is not visible then it will calculate the size of the 
>>> text based on some default GC, and will not update this size when it 
>>> will be added to the frame(which has another actual GC). So the tree 
>>> will use the size calculated using one GC, and will draw the text 
>>> using another GC. If the user will switch L&F the size will be 
>>> recalculated using correct GraphicsConfiguration.
>>>
>>>
>>>>
>>>>
>>>> -phil.
>>>>
>>>> On 06/22/2018 01:48 PM, Sergey Bylokhov wrote:
>>>>> Any volunteers for review?
>>>>> =)
>>>>>
>>>>> On 17/06/2018 15:37, Sergey Bylokhov wrote:
>>>>>> Unfortunately after additional testing I found a bug in our text 
>>>>>> related components. In the JTextPane the text looks broken if we 
>>>>>> request some change in the component after it is became visible.
>>>>>>
>>>>>> For example if we change the font then the text will be 
>>>>>> overlapping. So if I will be applied this fix, which will force 
>>>>>> text component to relayout(because of the change in graphics 
>>>>>> config), then the text will be broken from the beginning.
>>>>>>
>>>>>> But before the fix it will be broken only if the application will 
>>>>>> change the pane after it became visible(BTW text rendering during 
>>>>>> editing is broken in both cases).
>>>>>>
>>>>>> So I temporary reverted the changes in the text related components:
>>>>>> http://cr.openjdk.java.net/~serb/8201552/webrev.02
>>>>>>
>>>>>> Two follow bugs were created:
>>>>>> ? - Text components: https://bugs.openjdk.java.net/browse/JDK-8205143
>>>>>> ? - JSpinner: https://bugs.openjdk.java.net/browse/JDK-8205144
>>>>>>
>>>>>> On 15/06/2018 23:31, Sergey Bylokhov wrote:
>>>>>>> Hello.
>>>>>>> Please review the fix for jdk11.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
>>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/
>>>>>>>
>>>>>>> Short description:
>>>>>>> This fix enhance implementation of JDK-8178025[1] for most of our 
>>>>>>> Swing components. The main rule which I tried to follow:
>>>>>>> "If layout of the component depends from the font then it should 
>>>>>>> depend on the current graphics configuration as well, because 
>>>>>>> FontMetrics depends on graphics configuration".
>>>>>>>
>>>>>>> Long description:
>>>>>>> The fix for JDK-8178025 added a special property 
>>>>>>> "graphicsConfiguration" which: fired when the 
>>>>>>> graphicsConfiguration is changed from one non-null value to 
>>>>>>> another non-null value.
>>>>>>> Those fix also updated some of the components(to 
>>>>>>> refresh/re-validate its states when the "graphicsConfiguration" 
>>>>>>> or "ancestor" were changed).
>>>>>>>
>>>>>>> The usage of "ancestor" was not obvious, so I modify the code to 
>>>>>>> fire "graphicsConfiguration" every time, this cover a situation 
>>>>>>> when the "GC=null" is changed to "GC=non-null"(previously it was 
>>>>>>> covered by "ancestor" property). So after this fix our components 
>>>>>>> will listen only "font" and "graphicsConfiguration".
>>>>>>>
>>>>>>> In implementation of JDK-8178025 the "graphicsConfiguration" is 
>>>>>>> fired immediately after GC is changed, it caused the issues in 
>>>>>>> some containers like JTree. When the container get such 
>>>>>>> notification it usually tries to get some information from 
>>>>>>> children, but in this moment children had previous graphic 
>>>>>>> config, so the result calculated(and usually cached) in the 
>>>>>>> container was wrong. In this fix I changed implementation of this 
>>>>>>> property. Now it will fired only when the container and all its 
>>>>>>> children are updated.
>>>>>>>
>>>>>>> ===
>>>>>>> Note that the new test StalePreferredSize.java has a TODO block. 
>>>>>>> Because JSpinner does not work properly even after the current 
>>>>>>> fix. The reason is that during validation it is unexpectedly 
>>>>>>> change the font from normal to bold(I'll fix this in a separate bug)
>>>>>>>
>>>>>>>
>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178025
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Thu Jun 28 21:20:32 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 28 Jun 2018 14:20:32 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in
 "Classical" label in SwingSet2 demo with Windows L&F at Hidpi
In-Reply-To: <8bd9ccd2-3c76-ffa6-6028-e17ea5c117ec@oracle.com>
References: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
 <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>
 <59cf2392-2b07-e1a9-1632-271572829835@oracle.com>
 <9fbdf08a-6ff0-59c3-8877-4189e6fd0094@oracle.com>
 <b236a827-cbe7-3328-09f7-c891f28e3e7e@oracle.com>
 <213ce865-3293-7008-00d9-99054950af6f@oracle.com>
 <5B2D8C49.1070607@oracle.com>
 <8bd9ccd2-3c76-ffa6-6028-e17ea5c117ec@oracle.com>
Message-ID: <68806332-80b3-d212-e14e-9a9d5b362873@oracle.com>

2336 var newGC = (GraphicsConfiguration) oldValue; 2337 var oldGC = 
(GraphicsConfiguration) newValue; 2338 var newTx = newGC != null ? 
newGC.getDefaultTransform() : null;
2339 var oldTx = oldGC != null ? oldGC.getDefaultTransform() : null;
2340 return !Objects.equals(newTx, oldTx); var ?? I suppose it I can 
infer what the type of newTx and oldTx is because I know the API, but 
for someone else this makes it less readable. I suppose your comments 
below are discussing the effect of line 2340 We generally consider a 
null TX to mean identity and so consider them equal but this would do 
the opposite .. and you say this is what Swing wants ? -phil.



On 6/28/2018 1:54 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> The new webrev:
> http://cr.openjdk.java.net/~serb/8201552/webrev.03/
>
> I have checked why validation of the component is necessary, when the 
> "ancestor" is changed (I removed it, but the new validation on GC 
> change null->non-null is equivalent).
>
> Such validation is used as a last chance to update the state of the 
> component before show it to the user. In theory it is not necessary 
> but some components skips validation on font change(like jtree) and 
> maybe other properties. I have files a separate bug for that: 
> https://bugs.openjdk.java.net/browse/JDK-8206024
>
> ?- In the fix I have moved these checks to SwingU2.
> ?- TODO block for JSpinner: is removed because this bug was fixed
> https://bugs.openjdk.java.net/browse/JDK-8205144
>
> On 22/06/2018 16:54, Philip Race wrote:
>> It is not really the GC .. there is no GC .. but because of that the
>> code uses a default FontRenderContext.
>>
>> I think Swing is conflating GC + FRC but given that, then the logic
>> to recalculate based on graphicsconfiguration should be fine, although
>> maybe you can check if we really need to trigger it ..
>> if the screen we are shown on has no scale (ie uiScale == 1) then
>> we may be triggering a pointless invalidation with consequent overhead.
>> Can? you check if we can skip it in some cases ?
>>
>> -phil.
>>
>> On 6/22/18, 4:16 PM, Sergey Bylokhov wrote:
>>> The place where the current graphicsConfiguration of the component 
>>> is matter:
>>> ?- JComponent.getFontMetrics(Font)
>>> ?-- SwingUtilities2.getFontMetrics(this, font)
>>> ?--- SwingUtilities2.getFRCProperty(JComponent c)
>>>
>>> ??? if (c != null) {
>>> ??????? GraphicsConfiguration gc = c.getGraphicsConfiguration();
>>> ??????? AffineTransform tx = (gc == null) ? null : 
>>> gc.getDefaultTransform();
>>> ??????? Object aaHint = c.getClientProperty(KEY_TEXT_ANTIALIASING);
>>> ??????? return getFRCFromCache(tx, aaHint);
>>> ??? }
>>>
>>> When the bug is reproduced we calculated the size of the tree based 
>>> on one GC and draw it using another GC. The first GC which is used 
>>> for size calculation may be null or it maybe a non-null value 
>>> pointed to another screen, for example if the jtree was shown on one 
>>> screen and then dragged to another.
>>>
>>> On 22/06/2018 14:40, Sergey Bylokhov wrote:
>>>> In the SwingSet2 the bug is visible only if the user switches the 
>>>> L&F immediately before switching to the tree demo. And is not 
>>>> reproduced if the user switches to the tree demo and then change 
>>>> the L&F.
>>>>
>>>> ? - If the tree is not visible then it will calculate the size of 
>>>> the text based on some default GC, and will not update this size 
>>>> when it will be added to the frame(which has another actual GC). So 
>>>> the tree will use the size calculated using one GC, and will draw 
>>>> the text using another GC. If the user will switch L&F the size 
>>>> will be recalculated using correct GraphicsConfiguration.
>>>>
>>>>
>>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 06/22/2018 01:48 PM, Sergey Bylokhov wrote:
>>>>>> Any volunteers for review?
>>>>>> =)
>>>>>>
>>>>>> On 17/06/2018 15:37, Sergey Bylokhov wrote:
>>>>>>> Unfortunately after additional testing I found a bug in our text 
>>>>>>> related components. In the JTextPane the text looks broken if we 
>>>>>>> request some change in the component after it is became visible.
>>>>>>>
>>>>>>> For example if we change the font then the text will be 
>>>>>>> overlapping. So if I will be applied this fix, which will force 
>>>>>>> text component to relayout(because of the change in graphics 
>>>>>>> config), then the text will be broken from the beginning.
>>>>>>>
>>>>>>> But before the fix it will be broken only if the application 
>>>>>>> will change the pane after it became visible(BTW text rendering 
>>>>>>> during editing is broken in both cases).
>>>>>>>
>>>>>>> So I temporary reverted the changes in the text related components:
>>>>>>> http://cr.openjdk.java.net/~serb/8201552/webrev.02
>>>>>>>
>>>>>>> Two follow bugs were created:
>>>>>>> ? - Text components: 
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8205143
>>>>>>> ? - JSpinner: https://bugs.openjdk.java.net/browse/JDK-8205144
>>>>>>>
>>>>>>> On 15/06/2018 23:31, Sergey Bylokhov wrote:
>>>>>>>> Hello.
>>>>>>>> Please review the fix for jdk11.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
>>>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/
>>>>>>>>
>>>>>>>> Short description:
>>>>>>>> This fix enhance implementation of JDK-8178025[1] for most of 
>>>>>>>> our Swing components. The main rule which I tried to follow:
>>>>>>>> "If layout of the component depends from the font then it 
>>>>>>>> should depend on the current graphics configuration as well, 
>>>>>>>> because FontMetrics depends on graphics configuration".
>>>>>>>>
>>>>>>>> Long description:
>>>>>>>> The fix for JDK-8178025 added a special property 
>>>>>>>> "graphicsConfiguration" which: fired when the 
>>>>>>>> graphicsConfiguration is changed from one non-null value to 
>>>>>>>> another non-null value.
>>>>>>>> Those fix also updated some of the components(to 
>>>>>>>> refresh/re-validate its states when the "graphicsConfiguration" 
>>>>>>>> or "ancestor" were changed).
>>>>>>>>
>>>>>>>> The usage of "ancestor" was not obvious, so I modify the code 
>>>>>>>> to fire "graphicsConfiguration" every time, this cover a 
>>>>>>>> situation when the "GC=null" is changed to 
>>>>>>>> "GC=non-null"(previously it was covered by "ancestor" 
>>>>>>>> property). So after this fix our components will listen only 
>>>>>>>> "font" and "graphicsConfiguration".
>>>>>>>>
>>>>>>>> In implementation of JDK-8178025 the "graphicsConfiguration" is 
>>>>>>>> fired immediately after GC is changed, it caused the issues in 
>>>>>>>> some containers like JTree. When the container get such 
>>>>>>>> notification it usually tries to get some information from 
>>>>>>>> children, but in this moment children had previous graphic 
>>>>>>>> config, so the result calculated(and usually cached) in the 
>>>>>>>> container was wrong. In this fix I changed implementation of 
>>>>>>>> this property. Now it will fired only when the container and 
>>>>>>>> all its children are updated.
>>>>>>>>
>>>>>>>> ===
>>>>>>>> Note that the new test StalePreferredSize.java has a TODO 
>>>>>>>> block. Because JSpinner does not work properly even after the 
>>>>>>>> current fix. The reason is that during validation it is 
>>>>>>>> unexpectedly change the font from normal to bold(I'll fix this 
>>>>>>>> in a separate bug)
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178025
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>
>



From Sergey.Bylokhov at oracle.com  Thu Jun 28 22:14:00 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 28 Jun 2018 15:14:00 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in
 "Classical" label in SwingSet2 demo with Windows L&F at Hidpi
In-Reply-To: <68806332-80b3-d212-e14e-9a9d5b362873@oracle.com>
References: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
 <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>
 <59cf2392-2b07-e1a9-1632-271572829835@oracle.com>
 <9fbdf08a-6ff0-59c3-8877-4189e6fd0094@oracle.com>
 <b236a827-cbe7-3328-09f7-c891f28e3e7e@oracle.com>
 <213ce865-3293-7008-00d9-99054950af6f@oracle.com>
 <5B2D8C49.1070607@oracle.com>
 <8bd9ccd2-3c76-ffa6-6028-e17ea5c117ec@oracle.com>
 <68806332-80b3-d212-e14e-9a9d5b362873@oracle.com>
Message-ID: <4f18085a-97ee-24fb-d933-9996aa52a09a@oracle.com>

On 28/06/2018 14:20, Phil Race wrote:
> 2336 var newGC = (GraphicsConfiguration) oldValue; 2337 var oldGC = 
> (GraphicsConfiguration) newValue; 2338 var newTx = newGC != null ? 
> newGC.getDefaultTransform() : null;
> 2339 var oldTx = oldGC != null ? oldGC.getDefaultTransform() : null;
> 2340 return !Objects.equals(newTx, oldTx); var ?? I suppose it I can 
> infer what the type of newTx and oldTx is because I know the API, but 
> for someone else this makes it less readable.

The type of "newGC/oldGC" is on the right where we apply the cast:
var newGC = (GraphicsConfiguration) oldValue;

The type of newTx/oldTx is not so important since we only check they are 
equivalent ?r not. It will works even if the type will be Object instead 
of var.

> I suppose your comments 
> below are discussing the effect of line 2340 We generally consider a 
> null TX to mean identity and so consider them equal but this would do 
> the opposite .. and you say this is what Swing wants ? -phil.

In theory Swing wants to consider null as a identity TX, but in practice 
if we skip such validation we will expose other bugs like JDK-8206024. 
The change of "GC=null" to "GC=non-null" is occurred when the component 
id added to the parent and is used as a last chance to update the state 
of the component before show it to the user.

For example:
1 Jtree tree;
2 Dimension before = component.getPreferredSize();
3 tree.setFont(new Font());
.... some other initialization....
4 Dimension after = component.getPreferredSize();
5 frame.add(tree);

In line 3 the components should be revalidated because the font which 
affects the size was changed. But this validation can be skipped because 
of the some bugs. And it is not visible to the user just because we do 
validation at step 5(when the GC=null will be replaced by the 
GC=non-null). Before my fix it it was done using "ancestor" property(in 
some cases)

> 
> 
> 
> On 6/28/2018 1:54 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> The new webrev:
>> http://cr.openjdk.java.net/~serb/8201552/webrev.03/
>>
>> I have checked why validation of the component is necessary, when the 
>> "ancestor" is changed (I removed it, but the new validation on GC 
>> change null->non-null is equivalent).
>>
>> Such validation is used as a last chance to update the state of the 
>> component before show it to the user. In theory it is not necessary 
>> but some components skips validation on font change(like jtree) and 
>> maybe other properties. I have files a separate bug for that: 
>> https://bugs.openjdk.java.net/browse/JDK-8206024
>>
>> ?- In the fix I have moved these checks to SwingU2.
>> ?- TODO block for JSpinner: is removed because this bug was fixed
>> https://bugs.openjdk.java.net/browse/JDK-8205144
>>
>> On 22/06/2018 16:54, Philip Race wrote:
>>> It is not really the GC .. there is no GC .. but because of that the
>>> code uses a default FontRenderContext.
>>>
>>> I think Swing is conflating GC + FRC but given that, then the logic
>>> to recalculate based on graphicsconfiguration should be fine, although
>>> maybe you can check if we really need to trigger it ..
>>> if the screen we are shown on has no scale (ie uiScale == 1) then
>>> we may be triggering a pointless invalidation with consequent overhead.
>>> Can? you check if we can skip it in some cases ?
>>>
>>> -phil.
>>>
>>> On 6/22/18, 4:16 PM, Sergey Bylokhov wrote:
>>>> The place where the current graphicsConfiguration of the component 
>>>> is matter:
>>>> ?- JComponent.getFontMetrics(Font)
>>>> ?-- SwingUtilities2.getFontMetrics(this, font)
>>>> ?--- SwingUtilities2.getFRCProperty(JComponent c)
>>>>
>>>> ??? if (c != null) {
>>>> ??????? GraphicsConfiguration gc = c.getGraphicsConfiguration();
>>>> ??????? AffineTransform tx = (gc == null) ? null : 
>>>> gc.getDefaultTransform();
>>>> ??????? Object aaHint = c.getClientProperty(KEY_TEXT_ANTIALIASING);
>>>> ??????? return getFRCFromCache(tx, aaHint);
>>>> ??? }
>>>>
>>>> When the bug is reproduced we calculated the size of the tree based 
>>>> on one GC and draw it using another GC. The first GC which is used 
>>>> for size calculation may be null or it maybe a non-null value 
>>>> pointed to another screen, for example if the jtree was shown on one 
>>>> screen and then dragged to another.
>>>>
>>>> On 22/06/2018 14:40, Sergey Bylokhov wrote:
>>>>> In the SwingSet2 the bug is visible only if the user switches the 
>>>>> L&F immediately before switching to the tree demo. And is not 
>>>>> reproduced if the user switches to the tree demo and then change 
>>>>> the L&F.
>>>>>
>>>>> ? - If the tree is not visible then it will calculate the size of 
>>>>> the text based on some default GC, and will not update this size 
>>>>> when it will be added to the frame(which has another actual GC). So 
>>>>> the tree will use the size calculated using one GC, and will draw 
>>>>> the text using another GC. If the user will switch L&F the size 
>>>>> will be recalculated using correct GraphicsConfiguration.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 06/22/2018 01:48 PM, Sergey Bylokhov wrote:
>>>>>>> Any volunteers for review?
>>>>>>> =)
>>>>>>>
>>>>>>> On 17/06/2018 15:37, Sergey Bylokhov wrote:
>>>>>>>> Unfortunately after additional testing I found a bug in our text 
>>>>>>>> related components. In the JTextPane the text looks broken if we 
>>>>>>>> request some change in the component after it is became visible.
>>>>>>>>
>>>>>>>> For example if we change the font then the text will be 
>>>>>>>> overlapping. So if I will be applied this fix, which will force 
>>>>>>>> text component to relayout(because of the change in graphics 
>>>>>>>> config), then the text will be broken from the beginning.
>>>>>>>>
>>>>>>>> But before the fix it will be broken only if the application 
>>>>>>>> will change the pane after it became visible(BTW text rendering 
>>>>>>>> during editing is broken in both cases).
>>>>>>>>
>>>>>>>> So I temporary reverted the changes in the text related components:
>>>>>>>> http://cr.openjdk.java.net/~serb/8201552/webrev.02
>>>>>>>>
>>>>>>>> Two follow bugs were created:
>>>>>>>> ? - Text components: 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8205143
>>>>>>>> ? - JSpinner: https://bugs.openjdk.java.net/browse/JDK-8205144
>>>>>>>>
>>>>>>>> On 15/06/2018 23:31, Sergey Bylokhov wrote:
>>>>>>>>> Hello.
>>>>>>>>> Please review the fix for jdk11.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/
>>>>>>>>>
>>>>>>>>> Short description:
>>>>>>>>> This fix enhance implementation of JDK-8178025[1] for most of 
>>>>>>>>> our Swing components. The main rule which I tried to follow:
>>>>>>>>> "If layout of the component depends from the font then it 
>>>>>>>>> should depend on the current graphics configuration as well, 
>>>>>>>>> because FontMetrics depends on graphics configuration".
>>>>>>>>>
>>>>>>>>> Long description:
>>>>>>>>> The fix for JDK-8178025 added a special property 
>>>>>>>>> "graphicsConfiguration" which: fired when the 
>>>>>>>>> graphicsConfiguration is changed from one non-null value to 
>>>>>>>>> another non-null value.
>>>>>>>>> Those fix also updated some of the components(to 
>>>>>>>>> refresh/re-validate its states when the "graphicsConfiguration" 
>>>>>>>>> or "ancestor" were changed).
>>>>>>>>>
>>>>>>>>> The usage of "ancestor" was not obvious, so I modify the code 
>>>>>>>>> to fire "graphicsConfiguration" every time, this cover a 
>>>>>>>>> situation when the "GC=null" is changed to 
>>>>>>>>> "GC=non-null"(previously it was covered by "ancestor" 
>>>>>>>>> property). So after this fix our components will listen only 
>>>>>>>>> "font" and "graphicsConfiguration".
>>>>>>>>>
>>>>>>>>> In implementation of JDK-8178025 the "graphicsConfiguration" is 
>>>>>>>>> fired immediately after GC is changed, it caused the issues in 
>>>>>>>>> some containers like JTree. When the container get such 
>>>>>>>>> notification it usually tries to get some information from 
>>>>>>>>> children, but in this moment children had previous graphic 
>>>>>>>>> config, so the result calculated(and usually cached) in the 
>>>>>>>>> container was wrong. In this fix I changed implementation of 
>>>>>>>>> this property. Now it will fired only when the container and 
>>>>>>>>> all its children are updated.
>>>>>>>>>
>>>>>>>>> ===
>>>>>>>>> Note that the new test StalePreferredSize.java has a TODO 
>>>>>>>>> block. Because JSpinner does not work properly even after the 
>>>>>>>>> current fix. The reason is that during validation it is 
>>>>>>>>> unexpectedly change the font from normal to bold(I'll fix this 
>>>>>>>>> in a separate bug)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178025
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Thu Jun 28 22:34:55 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 28 Jun 2018 15:34:55 -0700
Subject: <Swing Dev> [11] Review Request: 8201552 Ellipsis in
 "Classical" label in SwingSet2 demo with Windows L&F at Hidpi
In-Reply-To: <4f18085a-97ee-24fb-d933-9996aa52a09a@oracle.com>
References: <ba6de670-db9a-4a27-51fc-f877cdeacede@oracle.com>
 <2690425d-a399-4510-91fb-ef747c8e5862@oracle.com>
 <59cf2392-2b07-e1a9-1632-271572829835@oracle.com>
 <9fbdf08a-6ff0-59c3-8877-4189e6fd0094@oracle.com>
 <b236a827-cbe7-3328-09f7-c891f28e3e7e@oracle.com>
 <213ce865-3293-7008-00d9-99054950af6f@oracle.com>
 <5B2D8C49.1070607@oracle.com>
 <8bd9ccd2-3c76-ffa6-6028-e17ea5c117ec@oracle.com>
 <68806332-80b3-d212-e14e-9a9d5b362873@oracle.com>
 <4f18085a-97ee-24fb-d933-9996aa52a09a@oracle.com>
Message-ID: <6ad351da-7f0e-2c86-bf16-285578b7655a@oracle.com>

On 6/28/2018 3:14 PM, Sergey Bylokhov wrote:
> On 28/06/2018 14:20, Phil Race wrote:
>> 2336 var newGC = (GraphicsConfiguration) oldValue; 2337 var oldGC = 
>> (GraphicsConfiguration) newValue; 2338 var newTx = newGC != null ? 
>> newGC.getDefaultTransform() : null;
>> 2339 var oldTx = oldGC != null ? oldGC.getDefaultTransform() : null;
>> 2340 return !Objects.equals(newTx, oldTx); var ?? I suppose it I can 
>> infer what the type of newTx and oldTx is because I know the API, but 
>> for someone else this makes it less readable.
>
> The type of "newGC/oldGC" is on the right where we apply the cast:
> var newGC = (GraphicsConfiguration) oldValue;

and I wasn't questioning that one for that reason ..
>
> The type of newTx/oldTx is not so important since we only check they 
> are equivalent ?r not. It will works even if the type will be Object 
> instead of var.
>
That's the one I am questioning. I can't tell by reading the code what 
type is, so
I think this is a borderline use of var.

>> I suppose your comments below are discussing the effect of line 2340 
>> We generally consider a null TX to mean identity and so consider them 
>> equal but this would do the opposite .. and you say this is what 
>> Swing wants ? -phil.
>
> In theory Swing wants to consider null as a identity TX, but in 
> practice if we skip such validation we will expose other bugs like 
> JDK-8206024. The change of "GC=null" to "GC=non-null" is occurred when 
> the component id added to the parent and is used as a last chance to 
> update the state of the component before show it to the user.
>
> For example:
> 1 Jtree tree;
> 2 Dimension before = component.getPreferredSize();
> 3 tree.setFont(new Font());
> .... some other initialization....
> 4 Dimension after = component.getPreferredSize();
> 5 frame.add(tree);
>
> In line 3 the components should be revalidated because the font which 
> affects the size was changed. But this validation can be skipped 
> because of the some bugs. And it is not visible to the user just 
> because we do validation at step 5(when the GC=null will be replaced 
> by the GC=non-null). Before my fix it it was done using "ancestor" 
> property(in some cases)

You are confirming what I thought you were saying.
Perhaps all such bugs could be fixed, and then we could fix the logic 
but that is
something that is beyond the scope of this fix.

Approved.

-phil.

>
>>
>>
>>
>> On 6/28/2018 1:54 PM, Sergey Bylokhov wrote:
>>> Hi, Phil.
>>> The new webrev:
>>> http://cr.openjdk.java.net/~serb/8201552/webrev.03/
>>>
>>> I have checked why validation of the component is necessary, when 
>>> the "ancestor" is changed (I removed it, but the new validation on 
>>> GC change null->non-null is equivalent).
>>>
>>> Such validation is used as a last chance to update the state of the 
>>> component before show it to the user. In theory it is not necessary 
>>> but some components skips validation on font change(like jtree) and 
>>> maybe other properties. I have files a separate bug for that: 
>>> https://bugs.openjdk.java.net/browse/JDK-8206024
>>>
>>> ?- In the fix I have moved these checks to SwingU2.
>>> ?- TODO block for JSpinner: is removed because this bug was fixed
>>> https://bugs.openjdk.java.net/browse/JDK-8205144
>>>
>>> On 22/06/2018 16:54, Philip Race wrote:
>>>> It is not really the GC .. there is no GC .. but because of that the
>>>> code uses a default FontRenderContext.
>>>>
>>>> I think Swing is conflating GC + FRC but given that, then the logic
>>>> to recalculate based on graphicsconfiguration should be fine, although
>>>> maybe you can check if we really need to trigger it ..
>>>> if the screen we are shown on has no scale (ie uiScale == 1) then
>>>> we may be triggering a pointless invalidation with consequent 
>>>> overhead.
>>>> Can? you check if we can skip it in some cases ?
>>>>
>>>> -phil.
>>>>
>>>> On 6/22/18, 4:16 PM, Sergey Bylokhov wrote:
>>>>> The place where the current graphicsConfiguration of the component 
>>>>> is matter:
>>>>> ?- JComponent.getFontMetrics(Font)
>>>>> ?-- SwingUtilities2.getFontMetrics(this, font)
>>>>> ?--- SwingUtilities2.getFRCProperty(JComponent c)
>>>>>
>>>>> ??? if (c != null) {
>>>>> ??????? GraphicsConfiguration gc = c.getGraphicsConfiguration();
>>>>> ??????? AffineTransform tx = (gc == null) ? null : 
>>>>> gc.getDefaultTransform();
>>>>> ??????? Object aaHint = c.getClientProperty(KEY_TEXT_ANTIALIASING);
>>>>> ??????? return getFRCFromCache(tx, aaHint);
>>>>> ??? }
>>>>>
>>>>> When the bug is reproduced we calculated the size of the tree 
>>>>> based on one GC and draw it using another GC. The first GC which 
>>>>> is used for size calculation may be null or it maybe a non-null 
>>>>> value pointed to another screen, for example if the jtree was 
>>>>> shown on one screen and then dragged to another.
>>>>>
>>>>> On 22/06/2018 14:40, Sergey Bylokhov wrote:
>>>>>> In the SwingSet2 the bug is visible only if the user switches the 
>>>>>> L&F immediately before switching to the tree demo. And is not 
>>>>>> reproduced if the user switches to the tree demo and then change 
>>>>>> the L&F.
>>>>>>
>>>>>> ? - If the tree is not visible then it will calculate the size of 
>>>>>> the text based on some default GC, and will not update this size 
>>>>>> when it will be added to the frame(which has another actual GC). 
>>>>>> So the tree will use the size calculated using one GC, and will 
>>>>>> draw the text using another GC. If the user will switch L&F the 
>>>>>> size will be recalculated using correct GraphicsConfiguration.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 06/22/2018 01:48 PM, Sergey Bylokhov wrote:
>>>>>>>> Any volunteers for review?
>>>>>>>> =)
>>>>>>>>
>>>>>>>> On 17/06/2018 15:37, Sergey Bylokhov wrote:
>>>>>>>>> Unfortunately after additional testing I found a bug in our 
>>>>>>>>> text related components. In the JTextPane the text looks 
>>>>>>>>> broken if we request some change in the component after it is 
>>>>>>>>> became visible.
>>>>>>>>>
>>>>>>>>> For example if we change the font then the text will be 
>>>>>>>>> overlapping. So if I will be applied this fix, which will 
>>>>>>>>> force text component to relayout(because of the change in 
>>>>>>>>> graphics config), then the text will be broken from the 
>>>>>>>>> beginning.
>>>>>>>>>
>>>>>>>>> But before the fix it will be broken only if the application 
>>>>>>>>> will change the pane after it became visible(BTW text 
>>>>>>>>> rendering during editing is broken in both cases).
>>>>>>>>>
>>>>>>>>> So I temporary reverted the changes in the text related 
>>>>>>>>> components:
>>>>>>>>> http://cr.openjdk.java.net/~serb/8201552/webrev.02
>>>>>>>>>
>>>>>>>>> Two follow bugs were created:
>>>>>>>>> ? - Text components: 
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8205143
>>>>>>>>> ? - JSpinner: https://bugs.openjdk.java.net/browse/JDK-8205144
>>>>>>>>>
>>>>>>>>> On 15/06/2018 23:31, Sergey Bylokhov wrote:
>>>>>>>>>> Hello.
>>>>>>>>>> Please review the fix for jdk11.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201552
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8201552/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Short description:
>>>>>>>>>> This fix enhance implementation of JDK-8178025[1] for most of 
>>>>>>>>>> our Swing components. The main rule which I tried to follow:
>>>>>>>>>> "If layout of the component depends from the font then it 
>>>>>>>>>> should depend on the current graphics configuration as well, 
>>>>>>>>>> because FontMetrics depends on graphics configuration".
>>>>>>>>>>
>>>>>>>>>> Long description:
>>>>>>>>>> The fix for JDK-8178025 added a special property 
>>>>>>>>>> "graphicsConfiguration" which: fired when the 
>>>>>>>>>> graphicsConfiguration is changed from one non-null value to 
>>>>>>>>>> another non-null value.
>>>>>>>>>> Those fix also updated some of the components(to 
>>>>>>>>>> refresh/re-validate its states when the 
>>>>>>>>>> "graphicsConfiguration" or "ancestor" were changed).
>>>>>>>>>>
>>>>>>>>>> The usage of "ancestor" was not obvious, so I modify the code 
>>>>>>>>>> to fire "graphicsConfiguration" every time, this cover a 
>>>>>>>>>> situation when the "GC=null" is changed to 
>>>>>>>>>> "GC=non-null"(previously it was covered by "ancestor" 
>>>>>>>>>> property). So after this fix our components will listen only 
>>>>>>>>>> "font" and "graphicsConfiguration".
>>>>>>>>>>
>>>>>>>>>> In implementation of JDK-8178025 the "graphicsConfiguration" 
>>>>>>>>>> is fired immediately after GC is changed, it caused the 
>>>>>>>>>> issues in some containers like JTree. When the container get 
>>>>>>>>>> such notification it usually tries to get some information 
>>>>>>>>>> from children, but in this moment children had previous 
>>>>>>>>>> graphic config, so the result calculated(and usually cached) 
>>>>>>>>>> in the container was wrong. In this fix I changed 
>>>>>>>>>> implementation of this property. Now it will fired only when 
>>>>>>>>>> the container and all its children are updated.
>>>>>>>>>>
>>>>>>>>>> ===
>>>>>>>>>> Note that the new test StalePreferredSize.java has a TODO 
>>>>>>>>>> block. Because JSpinner does not work properly even after the 
>>>>>>>>>> current fix. The reason is that during validation it is 
>>>>>>>>>> unexpectedly change the font from normal to bold(I'll fix 
>>>>>>>>>> this in a separate bug)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178025
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Fri Jun 29 20:09:42 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 29 Jun 2018 13:09:42 -0700
Subject: <Swing Dev> [11] RFR:JDK-8176359: Frame#setMaximizedbounds not
 working properly in multi screen environments
In-Reply-To: <bd076ea0-da57-4d33-9044-0d48f18dc2f1@default>
References: <8f3e9dcc-1e44-4713-b8d5-a477d3887ee3@default>
 <e4c76f73-e5ae-4367-b7db-3d147999bd49@default>
 <bd076ea0-da57-4d33-9044-0d48f18dc2f1@default>
Message-ID: <6a432ac5-68d6-fb04-29cc-5bf173dcf3f6@oracle.com>

Hi, Krishna.
> Also, while running the testcase, I discovered that the 
> -Dsun.java2d.uiScale=1.25 will uniformly apply the scaling across all 
> the screens, whereas if the underlying monitor is not scaled, the 
> results will be different.
> 
> Hence I modified the test to remove the uiScale settings related tests.

I suggest to add it back. The case when the bug can be reproduced 
depends from the real screen resolution. If such resolution is set then 
the bug should not depend from the scales of the screens, because 
internally we will convert the scaled coordinates to the real pixels and 
it does not matter what scale is used in java.

There some questionable places in the fix:
  - 106 b = scaleBounds(b, currScaleX, currScaleY); Why the scale of the 
current screen is used? I guess we need to find on which screen this "b" 
is located and then use its scale. Check implementation of 
WWindowPeer.setBounds()

  - Is it intentional to assign to "b" a values from "primaryDevBounds", 
which was not scaled? So in some cases the "b" will have scaled values 
and in some cases not.
     125                 b.width = primaryDevBounds.width;
     130                 b.height = primaryDevBounds.height;
     134                 b.x = primaryDevBounds.x;
     138                 b.y = primaryDevBounds.y;


-- 
Best regards, Sergey.