From Sergey.Bylokhov at oracle.com  Sun Sep  3 00:58:06 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 2 Sep 2017 17:58:06 -0700
Subject: <AWT Dev> [10] Review Request: 8184219 Fix accessibility of tables
 in the java.desktop module
Message-ID: <7b7b2012-af3a-714b-97a8-225cecd4f7aa@oracle.com>

Hello,
Please review the fix for jdk10.

This is the first step to cleanup these warnings:
http://cr.openjdk.java.net/~jjg/doc-report/jdk-by-module/java.desktop/report.html

Bug: https://bugs.openjdk.java.net/browse/JDK-8184219
Webrev can be found at: http://cr.openjdk.java.net/~serb/8184219/webrev.00
Specdiff:http://cr.openjdk.java.net/~serb/8184219/specdiff.00/java.desktop-summary.html

In this fix most of the "striped" tables in the javadoc of java.desktop 
module are updated:
  - New attribute scope="col/"row" was added to all headers.
  - Optional tags like </td>, </tr> were removed.
  - Most of custom table styles like "style=text-align:center" were 
removed, so all tables now unified.
  - In a few places the "&quot;" was replaced by ", because " is widely 
used in our docs anyway.

Some unchanged tables will be updated later(html files inside doc-files 
folder, and some tables which are used for layout).

More information about a reason for these changes is in the review 
request for java.base module:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-July/048519.html

-- 
Best regards, Sergey.

From alexander.zvegintsev at oracle.com  Mon Sep  4 04:50:55 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 4 Sep 2017 10:20:55 +0530
Subject: <AWT Dev> [10] Review Request: 8186617 The
 "com.sun.awt.AWTUtilities" class can be dropped in favour of public API
In-Reply-To: <2002d410-26a0-4160-9d4f-8c67d1902293@default>
References: <2002d410-26a0-4160-9d4f-8c67d1902293@default>
Message-ID: <10e918a8-f1cb-aeb8-6d9c-8bae6d31bdc6@oracle.com>

Looks fine.

Thanks,
Alexander.

On 23/08/2017 03:09, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8186617
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8186617/webrev.00
>
>
> The client code has a "com.sun.awt.AWTUtilities" class which at some point(jdk6u10) in the past was used as a kind of "public" API.
>
> In jdk9 this class is inaccessible and all its functionality was already provided by the public API, so this class can be removed.
>
> AWTUtilities.isTranslucencySupported()/AWTUtilities.isWindowShapingSupported()
>      -> GraphicsDevice.isWindowTranslucencySupported()
>
> AWTUtilities.setWindowOpacity()/AWTUtilities.getWindowOpacity()
>      -> Window.setOpacity/getOpacity
>
> AWTUtilities.getWindowShape()/AWTUtilities.setWindowShape()
>      -> Window.setShape()/getShape()
>
> AWTUtilities.setWindowOpaque/AWTUtilities.isWindowOpaque
>      -> setBackground()/isOpaque()
>
> AWTUtilities.isTranslucencyCapable
>      -> GraphicsConfiguration.isTranslucencyCapable()
>
> AWTUtilities.setComponentMixingCutoutShape
>      -> Component.setMixingCutoutShape()
>
> CSR will be created after technical review.


From philip.race at oracle.com  Tue Sep  5 16:25:00 2017
From: philip.race at oracle.com (Phil Race)
Date: Tue, 5 Sep 2017 09:25:00 -0700
Subject: <AWT Dev> jdk10/client forest is FROZEN until JDK 10 repos are
	consolidated.
In-Reply-To: <5952E8F9.7010405@oracle.com>
References: <5952E8F9.7010405@oracle.com>
Message-ID: <4f45d0d1-4c94-fd65-9620-cfe78857887e@oracle.com>


The JDK 10 repo consolidation [1] is about to begin.
All the JDK forests need to be frozen to make this happen .. as per this
excerpt from the email below

//>/We're aiming to have the final pre-consolidation integrations of the />/hs and client forests into JDK 10 master the week of August 28 or />/shortly thereafter. Any work urgently needed to JDK 10 in areas that />/push directly to master should also be pushed the week of August 28. />//>/On or about the week of September 4, JDK 10 master will be marked as />/read-only and after it is marked read-only,/

So it is now 5th September and you should consider the client forest FROZEN
(and it may actually be read-only already since a request has been sent
to ops to make it so). If you do manage to push something there likely it
will be lost anyway and you would need to re-push at  later date in
the new consolidated forest.

It will re-open once the consolidation is completed some time next week.
In theory it should take only a day or so but there are implications for 
"boundary"
systems which will take a little longer.

Of course you will need to throw away all existing copies and re-clone
since the forests will be different.

-phil.


[1] 
http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000455.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170905/3a354fd0/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Sep  5 17:15:20 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Sep 2017 10:15:20 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch
 keyboard is not shown for text components on a screen touch
In-Reply-To: <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
 <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
Message-ID: <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>

Hi, Anton.
The fix looks good.
  - But can you please recheck that is is not necessary to use 
additional synchronization in showOrHideTouchKeyboard() if a few EDT 
will be used.
  - I suggest to invert the awt.touchKeyboardAutoShowIsEnabled and use 
true as default value, we will have more coverage and feedback in this 
case. This property will be used as a workaround if some bugs will be 
found.

On 8/30/17 11:51, Anton Litvinov wrote:
> Hello dear reviewers,
> 
> Could anybody please look at this review request?
> 
> Thank you,
> Anton
> 
> On 17/08/2017 13:20, Anton Litvinov wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166772
>> Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00
>>
>> The bug is the fact that, when a user touches any Swing or AWT text 
>> component, for example "JTextField", "JTextArea", "TextField", 
>> "TextArea", by means of a touch screen on a host with MS Windows 
>> 10/8.1/8 OS, the system touch keyboard is not shown automatically. 
>> Please find a detailed description of the bug, screenshots depicting 
>> the touch keyboard and a compilable test case with Swing/AWT text 
>> components in JBS bug record. Also a summary of the done research of 
>> the issue with a description of identified approaches for its 
>> resolution are reported in my last comment in the bug record.
>>
>> THE FIX:
>> On a very abstract level the fix functioning can be presented by the 
>> next 3 stages:
>>
>> Stage 1.
>> The fix adds support of "WM_TOUCH" system window messages to AWT 
>> native peer windows through C++ class "AwtComponent". It "processes" 
>> "WM_TOUCH" message and marks "java.awt.event.MouseEvent", which is 
>> created as a result of handling of the further coming 
>> "WM_LBUTTONDOWN", "WM_LBUTTONUP" messages sent by the system in 
>> substitution for this "WM_TOUCH" message, by the new private field 
>> flag "MouseEvent.causedByTouchEvent".
>>
>> Stage 2.
>> Then on Java level the fix handles "MouseEvent", "FocusEvent" received 
>> only by the instances of "java.awt.TextComponent", 
>> "javax.swing.text.TextComponent" in 
>> "WToolkit.showOrHideTouchKeyboard()" called from 
>> "Component.dispatchEventImpl()" and shows or hides the touch keyboard 
>> on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" events by 
>> calling corresponding native methods of "WToolkit" class.
>>
>> Stage 3.
>> Showing of the touch keyboard is implemented in C++ class "AwtToolkit" 
>> and is done by launching the system application "TabTip.exe" which 
>> implements the system touch keyboard. This approach is described in 
>> the bug record.
>>
>> FEATURES OF THE FIX:
>> 1. By default all native and Java parts of the fix do not function at 
>> all - the fix is disabled. To enable the fix the application should be 
>> run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" option. Handling 
>> of this new property is implemented in "sun.awt.SunToolkit" class.
>>
>> 2. Native parts of the fix functions only on MS Window 8 or later.
>>
>> 3. The fix implements automatic showing of the touch keyboard for the 
>> following 2 use cases:
>> ??? a.? The user touches the text components using the touch screen.
>> ??? b.? The user does mouse clicks on the text components, while no 
>> any keyboard is attached to the host.
>>
>> FIX LOGICAL STRUCTURE BY SOURCE CODE:
>> 1. Core of the fix:
>> ??? Native code:? awt_Toolkit.[h/cpp], awt_Component.[h/cpp], 
>> awt_MouseEvent.[h/cpp], awt.h
>> ??? Java:? SunToolkit.java, WToolkit.java, Component.java, 
>> MouseEvent.java, AWTAccessor.java
>>
>> 2. Changes in all remaining Java files are connected with retaining of 
>> the flag value "MouseEvent.causedByTouchEvent" during creation of the 
>> new instances of "MouseEvent" class based on the original "MouseEvent" 
>> instances.
>>
>> Work of the fix was verified both in the environment with the real 
>> touch screen device and in the environment with the emulated touch 
>> screen.
>>
>> Thank you,
>> Anton
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Sep  5 22:08:08 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Sep 2017 15:08:08 -0700
Subject: <AWT Dev> [10] Review Request: 8186617 The
 "com.sun.awt.AWTUtilities" class can be dropped in favour of public API
In-Reply-To: <10e918a8-f1cb-aeb8-6d9c-8bae6d31bdc6@oracle.com>
References: <2002d410-26a0-4160-9d4f-8c67d1902293@default>
 <10e918a8-f1cb-aeb8-6d9c-8bae6d31bdc6@oracle.com>
Message-ID: <c5fb14ac-f8f4-2d67-65dd-cae15b4fa8ed@oracle.com>

Thank you.
The CSR was created:
https://bugs.openjdk.java.net/browse/JDK-8187253

On 9/3/17 21:50, Alexander Zvegintsev wrote:
> Looks fine.
> 
> Thanks,
> Alexander.
> 
> On 23/08/2017 03:09, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk10.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8186617
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8186617/webrev.00
>>
>>
>> The client code has a "com.sun.awt.AWTUtilities" class which at some 
>> point(jdk6u10) in the past was used as a kind of "public" API.
>>
>> In jdk9 this class is inaccessible and all its functionality was 
>> already provided by the public API, so this class can be removed.
>>
>> AWTUtilities.isTranslucencySupported()/AWTUtilities.isWindowShapingSupported() 
>>
>> ???? -> GraphicsDevice.isWindowTranslucencySupported()
>>
>> AWTUtilities.setWindowOpacity()/AWTUtilities.getWindowOpacity()
>> ???? -> Window.setOpacity/getOpacity
>>
>> AWTUtilities.getWindowShape()/AWTUtilities.setWindowShape()
>> ???? -> Window.setShape()/getShape()
>>
>> AWTUtilities.setWindowOpaque/AWTUtilities.isWindowOpaque
>> ???? -> setBackground()/isOpaque()
>>
>> AWTUtilities.isTranslucencyCapable
>> ???? -> GraphicsConfiguration.isTranslucencyCapable()
>>
>> AWTUtilities.setComponentMixingCutoutShape
>> ???? -> Component.setMixingCutoutShape()
>>
>> CSR will be created after technical review.
> 


-- 
Best regards, Sergey.

From pankaj.b.bansal at oracle.com  Wed Sep  6 10:39:27 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 6 Sep 2017 03:39:27 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: JDK-8154468 : [TEST_BUG]
 java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java
Message-ID: <7e4d42af-d299-4e7a-93b5-0de96113910c@default>

Hi All,

 

Please review the fix for test program java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java for JDK 10.

 

Bug:

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

 

Webrev:

http://cr.openjdk.java.net/~aghaisas/pankaj/8154468/webrev.0/

 

Issue:

java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java test fails due to insufficient robot delay.

 

Fix:

Increased the delay for robot before calling robot.getPixelColor to account for rendering delay.

 

Note:

The test passes on Windows and Linux with the given fix. However, it fails on MacOS due to some other bug in the Robot.getPixelColor functionality. It returns wrong color value for any pixel. The bug ID for the issue is https://bugs.openjdk.java.net/browse/JDK-8181305

 

Regards,

Pankaj Bansal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170906/be153543/attachment.html>

From semyon.sadetsky at oracle.com  Wed Sep  6 15:16:50 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 6 Sep 2017 08:16:50 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8154468 : [TEST_BUG]
 java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java
In-Reply-To: <7e4d42af-d299-4e7a-93b5-0de96113910c@default>
References: <7e4d42af-d299-4e7a-93b5-0de96113910c@default>
Message-ID: <513bcbab-88d4-43b3-6eea-d2d6a7c75106@oracle.com>

+1

--Semyon


On 09/06/2017 03:39 AM, Pankaj Bansal wrote:
>
> Hi All,
>
> Please review the fix for test program 
> java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java for JDK 10.
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8154468
>
> Webrev:
>
> http://cr.openjdk.java.net/~aghaisas/pankaj/8154468/webrev.0/ 
> <http://cr.openjdk.java.net/%7Eaghaisas/pankaj/8154468/webrev.0/>
>
> Issue:
>
> java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java test fails 
> due to insufficient robot delay.
>
> Fix:
>
> Increased the delay for robot before calling robot.getPixelColor to 
> account for rendering delay.
>
> Note:
>
> The test passes on Windows and Linux with the given fix. However, it 
> fails on MacOS due to some other bug in the Robot.getPixelColor 
> functionality. It returns wrong color value for any pixel. The bug ID 
> for the issue is https://bugs.openjdk.java.net/browse/JDK-8181305
>
> Regards,
>
> Pankaj Bansal
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170906/a4fbe82b/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Sep  6 15:24:22 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 6 Sep 2017 08:24:22 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8154468 : [TEST_BUG]
 java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java
In-Reply-To: <7e4d42af-d299-4e7a-93b5-0de96113910c@default>
References: <7e4d42af-d299-4e7a-93b5-0de96113910c@default>
Message-ID: <3e82bcbe-2931-1e80-9fad-70e3eaf32fc1@oracle.com>

Hi, Pankaj.

The description of the https://bugs.openjdk.java.net/browse/JDK-8181305 
mentioned that non "Generic RGB profile" is used, but our tests expect 
to be run on "Generic RGB profile" only. Please confirm that an updated 
fix in this bug will pass on osx if ""Generic RGB" is used.

On 9/6/17 03:39, Pankaj Bansal wrote:
> Hi All,
> 
> Please review the fix for test program 
> java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java for JDK 10.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8154468
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~aghaisas/pankaj/8154468/webrev.0/
> 
> Issue:
> 
> java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java test fails due 
> to insufficient robot delay.
> 
> Fix:
> 
> Increased the delay for robot before calling robot.getPixelColor to 
> account for rendering delay.
> 
> Note:
> 
> The test passes on Windows and Linux with the given fix. However, it 
> fails on MacOS due to some other bug in the Robot.getPixelColor 
> functionality. It returns wrong color value for any pixel. The bug ID 
> for the issue is https://bugs.openjdk.java.net/browse/JDK-8181305
> 
> Regards,
> 
> Pankaj Bansal
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Thu Sep  7 02:31:27 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 6 Sep 2017 19:31:27 -0700
Subject: <AWT Dev> [10] Review request for 8148619: Select the closest
 resolution variant in BaseMultiResolutionImage
Message-ID: <211edcae-ae77-d758-fdd2-2bced2382d9f@oracle.com>

Hello,

Please review fix for JDK10:

bug: https://bugs.openjdk.java.net/browse/JDK-8148619

webrev: http://cr.openjdk.java.net/~ssadetsky/8148619/webrev.00/

The algorithm selecting the best resolution variant of the 
BaseMultiResolutionImage was updated to be insensitive to the order of 
image variants in the initially provided array.

The BaseMultiResolutionImage specification was updated correspondingly.

--Semyon


From pankaj.b.bansal at oracle.com  Thu Sep  7 05:55:07 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 6 Sep 2017 22:55:07 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: JDK-8154468 : [TEST_BUG]
 java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java
In-Reply-To: <3e82bcbe-2931-1e80-9fad-70e3eaf32fc1@oracle.com>
References: <7e4d42af-d299-4e7a-93b5-0de96113910c@default>
 <3e82bcbe-2931-1e80-9fad-70e3eaf32fc1@oracle.com>
Message-ID: <2e579595-1b6b-47af-b5ff-43146b63bc24@default>

Hi Sergey,

Yes, I have verified this thing. The test passes for "Generic RGB profile" and fails for other profiles with the proposed fix. 

Regards,
Pankaj Bansal

-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, September 6, 2017 8:54 PM
To: Pankaj Bansal; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] Review Request: JDK-8154468 : [TEST_BUG] java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java

Hi, Pankaj.

The description of the https://bugs.openjdk.java.net/browse/JDK-8181305
mentioned that non "Generic RGB profile" is used, but our tests expect to be run on "Generic RGB profile" only. Please confirm that an updated fix in this bug will pass on osx if ""Generic RGB" is used.

On 9/6/17 03:39, Pankaj Bansal wrote:
> Hi All,
> 
> Please review the fix for test program 
> java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java for JDK 10.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8154468
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~aghaisas/pankaj/8154468/webrev.0/
> 
> Issue:
> 
> java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java test fails 
> due to insufficient robot delay.
> 
> Fix:
> 
> Increased the delay for robot before calling robot.getPixelColor to 
> account for rendering delay.
> 
> Note:
> 
> The test passes on Windows and Linux with the given fix. However, it 
> fails on MacOS due to some other bug in the Robot.getPixelColor 
> functionality. It returns wrong color value for any pixel. The bug ID 
> for the issue is https://bugs.openjdk.java.net/browse/JDK-8181305
> 
> Regards,
> 
> Pankaj Bansal
> 


--
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep  7 19:15:17 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 7 Sep 2017 12:15:17 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8154468 : [TEST_BUG]
 java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java
In-Reply-To: <2e579595-1b6b-47af-b5ff-43146b63bc24@default>
References: <7e4d42af-d299-4e7a-93b5-0de96113910c@default>
 <3e82bcbe-2931-1e80-9fad-70e3eaf32fc1@oracle.com>
 <2e579595-1b6b-47af-b5ff-43146b63bc24@default>
Message-ID: <47bcae08-a667-95a5-d2a5-14a558ae0972@oracle.com>

Thank you for clarification.
The fix looks fine.

On 9/6/17 22:55, Pankaj Bansal wrote:
> Hi Sergey,
> 
> Yes, I have verified this thing. The test passes for "Generic RGB profile" and fails for other profiles with the proposed fix.
> 
> Regards,
> Pankaj Bansal
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Wednesday, September 6, 2017 8:54 PM
> To: Pankaj Bansal; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] Review Request: JDK-8154468 : [TEST_BUG] java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java
> 
> Hi, Pankaj.
> 
> The description of the https://bugs.openjdk.java.net/browse/JDK-8181305
> mentioned that non "Generic RGB profile" is used, but our tests expect to be run on "Generic RGB profile" only. Please confirm that an updated fix in this bug will pass on osx if ""Generic RGB" is used.
> 
> On 9/6/17 03:39, Pankaj Bansal wrote:
>> Hi All,
>>
>> Please review the fix for test program
>> java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java for JDK 10.
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8154468
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~aghaisas/pankaj/8154468/webrev.0/
>>
>> Issue:
>>
>> java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java test fails
>> due to insufficient robot delay.
>>
>> Fix:
>>
>> Increased the delay for robot before calling robot.getPixelColor to
>> account for rendering delay.
>>
>> Note:
>>
>> The test passes on Windows and Linux with the given fix. However, it
>> fails on MacOS due to some other bug in the Robot.getPixelColor
>> functionality. It returns wrong color value for any pixel. The bug ID
>> for the issue is https://bugs.openjdk.java.net/browse/JDK-8181305
>>
>> Regards,
>>
>> Pankaj Bansal
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep  7 20:41:41 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 7 Sep 2017 13:41:41 -0700
Subject: <AWT Dev> [10] Review request for 8148619: Select the closest
 resolution variant in BaseMultiResolutionImage
In-Reply-To: <211edcae-ae77-d758-fdd2-2bced2382d9f@oracle.com>
References: <211edcae-ae77-d758-fdd2-2bced2382d9f@oracle.com>
Message-ID: <b8ca351d-0d9e-d642-55da-241a52d45b39@oracle.com>

Hi, Semyon.

The responsibility for sorting of an array was intentionally moved to 
the user, because the getResolutionVariant method () is called in each 
draw of the image. For this purpose in documentation for a class and in 
a documentation for constructors it was specified that the array shall 
be sorted. It is the reason why the bug of JDK-8147849 was closed.

RFE which you try to fix cover another use-case:
If the user will use the sorted array  [@1 , at 20] then we should select 
@1 if "-Dsun.java2d.uiScale=2" is used but not @20

On 9/6/17 19:31, Semyon Sadetsky wrote:
> Hello,
> 
> Please review fix for JDK10:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8148619
> 
> webrev: http://cr.openjdk.java.net/~ssadetsky/8148619/webrev.00/
> 
> The algorithm selecting the best resolution variant of the 
> BaseMultiResolutionImage was updated to be insensitive to the order of 
> image variants in the initially provided array.
> 
> The BaseMultiResolutionImage specification was updated correspondingly.
> 
> --Semyon
> 


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Fri Sep  8 09:50:30 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Fri, 8 Sep 2017 02:50:30 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default>
References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default>
Message-ID: <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default>

Hi, I have updated the Webrev to accommodate the comments and here is the new Webrev:

?

http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

?

I have separated the Unicode keys input via java robot as a new set of public api?s (this is in similar fashion as how the platform offers the Unicode keys input into the system) and this has been tested on all the platforms using the test file similar to the attached file in the bug. A more proper test file would be put for review in the subsequent reviews.

?

Thanks and regards,

Shashi

?

From: Sergey Bylokhov 
Sent: Wednesday, August 30, 2017 2:33 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

?

Hi, Shashi.

This is part of this fix, to figure out how it will work for external applications. As you said this functionally can be useful for an onscreen keyboards, which virtually can have any possible keys, but we should check how the applications will react on such keys:
?- Will the application get some kind of keyPress/Release?
?- Will the application get some keyCode for such event?
?- Is it possible to get autorepeat for such keys?(between press/release)

Depending from the answers above we can enhance existed robot API or provide a new one:
like Robot.keyType(char)/etc

----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: 
> 

> 

> 

Hi Sergey, I was only able to add short cut keys in the Microsoft word but not as a system wide short cut key. There was no mechanism that I could find to add a short cut key for a Unicode char!! Can you please tell me the steps to do the same if you are aware of?

?

Thanks and regards,

shashi

?

> 

From: Sergey Bylokhov 
> Sent: Tuesday, August 22, 2017 8:34 PM
> To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
> Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

?

Hi, Shashi.
> Can you check how this Robot API will work when the application will have a shortcut for such key? Will such shortcuts will work after this fix? 
> 
> ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: 
> > 

> 

> 

Hi All, Please review fix for the enhancement wherein the robot key press of non-ascii were interpreted as question marks.

?

Issue: The robot key press events was handling only the ascii inputs and ignored the other Unicode inputs. Either it was throwing illegal argument exception in windows or does nothing on the mac for those Unicode inputs.

?

Solution and fix: The platform specific api?s was unable handle the non-ascii inputs. I have modified the api?s to accept the non-ascii inputs and correspondingly send the message to the window to print the non-ascii characters as well. Below is the picture of how the non-ascii inputs are considered and printed onto the window.



The solution spans across windows and mac platform and still in search of a solution for the Linux platform. The solution implements key scanning only upon existing valid ascii key was not found and assumes it as Unicode key and sends the event to event queue to be processed as Unicode keys. Different formats are being used by different platform implementation of Unicode. For ex., per the below Unicode list, in the case of windows and mac, the key input can take decimal values whereas on Linux it can only take the Code values.

On Linux, I was able to get the KeySym of Unicode keys but was unable to fake the key event as there was no mechanism available for the same(which sends the key event to window). Please let me know if there is any such mechanism available to simulate Unicode key events on Linux platform. Hence I think to raise a bug for the Linux platform and close this JDK-8148344 bug.



?

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

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

?

Thanks and regards,

Shashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170908/921c9401/attachment.html>

From semyon.sadetsky at oracle.com  Fri Sep  8 18:06:25 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 8 Sep 2017 11:06:25 -0700
Subject: <AWT Dev> [10] Review request for 8148619: Select the closest
 resolution variant in BaseMultiResolutionImage
In-Reply-To: <b8ca351d-0d9e-d642-55da-241a52d45b39@oracle.com>
References: <211edcae-ae77-d758-fdd2-2bced2382d9f@oracle.com>
 <b8ca351d-0d9e-d642-55da-241a52d45b39@oracle.com>
Message-ID: <7a8d587d-033e-4e41-50d5-7a58796dd09d@oracle.com>

Hi Sergey,

On 09/07/2017 01:41 PM, Sergey Bylokhov wrote:
> Hi, Semyon.
>
> The responsibility for sorting of an array was intentionally moved to 
> the user, because the getResolutionVariant method () is called in each 
> draw of the image. For this purpose in documentation for a class and 
> in a documentation for constructors it was specified that the array 
> shall be sorted. It is the reason why the bug of JDK-8147849 was closed.
This seems to me a mistake in the API design which this update is trying 
to fix. Since we opened this API for everybody's use the base 
implementation of the MultiResolutionImage  should  be covering its most 
frequent and general usage. And in this general usage the appropriate 
resolution among the provided image variants should be chosen at the 
time the MR image is drawn. This is the logic we use internally in JDK 
to draw icons and other UI stuff on the HiDPI display and it is in 
demand for user applications in most cases.
When a predefined order of the image variant selection is required then 
getResolutionVariant() may be overridden to achieve that. But obviously 
this is a rare case and it shouldn't be a basic implementation.

--Semyon
>
> RFE which you try to fix cover another use-case:
> If the user will use the sorted array  [@1 , at 20] then we should select 
> @1 if "-Dsun.java2d.uiScale=2" is used but not @20
>
> On 9/6/17 19:31, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK10:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8148619
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8148619/webrev.00/
>>
>> The algorithm selecting the best resolution variant of the 
>> BaseMultiResolutionImage was updated to be insensitive to the order 
>> of image variants in the initially provided array.
>>
>> The BaseMultiResolutionImage specification was updated correspondingly.
>>
>> --Semyon
>>
>
>


From Sergey.Bylokhov at oracle.com  Fri Sep  8 18:29:23 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 8 Sep 2017 11:29:23 -0700
Subject: <AWT Dev> [10] Review request for 8148619: Select the closest
 resolution variant in BaseMultiResolutionImage
In-Reply-To: <7a8d587d-033e-4e41-50d5-7a58796dd09d@oracle.com>
References: <211edcae-ae77-d758-fdd2-2bced2382d9f@oracle.com>
 <b8ca351d-0d9e-d642-55da-241a52d45b39@oracle.com>
 <7a8d587d-033e-4e41-50d5-7a58796dd09d@oracle.com>
Message-ID: <b67c3e89-f364-ad2d-460f-ba464c218524@oracle.com>

This is not a mistake, it was done intentionally because this is a 
small/basic/simple/fast implementation.

On 9/8/17 11:06, Semyon Sadetsky wrote:
> On 09/07/2017 01:41 PM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>>
>> The responsibility for sorting of an array was intentionally moved to 
>> the user, because the getResolutionVariant method () is called in each 
>> draw of the image. For this purpose in documentation for a class and 
>> in a documentation for constructors it was specified that the array 
>> shall be sorted. It is the reason why the bug of JDK-8147849 was closed.
> This seems to me a mistake in the API design which this update is trying 
> to fix. Since we opened this API for everybody's use the base 
> implementation of the MultiResolutionImage? should? be covering its most 
> frequent and general usage. And in this general usage the appropriate 
> resolution among the provided image variants should be chosen at the 
> time the MR image is drawn. This is the logic we use internally in JDK 
> to draw icons and other UI stuff on the HiDPI display and it is in 
> demand for user applications in most cases.
> When a predefined order of the image variant selection is required then 
> getResolutionVariant() may be overridden to achieve that. But obviously 
> this is a rare case and it shouldn't be a basic implementation.
> 
> --Semyon
>>
>> RFE which you try to fix cover another use-case:
>> If the user will use the sorted array? [@1 , at 20] then we should select 
>> @1 if "-Dsun.java2d.uiScale=2" is used but not @20
>>
>> On 9/6/17 19:31, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK10:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8148619
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8148619/webrev.00/
>>>
>>> The algorithm selecting the best resolution variant of the 
>>> BaseMultiResolutionImage was updated to be insensitive to the order 
>>> of image variants in the initially provided array.
>>>
>>> The BaseMultiResolutionImage specification was updated correspondingly.
>>>
>>> --Semyon
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep  8 18:48:53 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 8 Sep 2017 11:48:53 -0700
Subject: <AWT Dev> [10] Review request for 8148619: Select the closest
 resolution variant in BaseMultiResolutionImage
In-Reply-To: <b67c3e89-f364-ad2d-460f-ba464c218524@oracle.com>
References: <211edcae-ae77-d758-fdd2-2bced2382d9f@oracle.com>
 <b8ca351d-0d9e-d642-55da-241a52d45b39@oracle.com>
 <7a8d587d-033e-4e41-50d5-7a58796dd09d@oracle.com>
 <b67c3e89-f364-ad2d-460f-ba464c218524@oracle.com>
Message-ID: <c3ee1d6e-5c9f-76df-b631-acbdcebf16f2@oracle.com>

On 09/08/2017 11:29 AM, Sergey Bylokhov wrote:

> This is not a mistake, it was done intentionally because this is a 
> small/basic/simple/fast implementation.
This is important criteria but it is not enough for public API. In 
internal classes the internal implementation logic could be shared 
between the provider class and its client, but this obviously violates 
the encapsulation concept.  But this is not suitable for a public API. 
Look at the way how this API is designed: To have 
BaseMultiResolutionImage woking correctly the client must provide 
BaseMultiResolutionImage internal data structure prepared by a certain 
rule in constructor argument. This API design looks inappropriate to 
common standard without any significant reason.

--Semyon
>
> On 9/8/17 11:06, Semyon Sadetsky wrote:
>> On 09/07/2017 01:41 PM, Sergey Bylokhov wrote:
>>> Hi, Semyon.
>>>
>>> The responsibility for sorting of an array was intentionally moved 
>>> to the user, because the getResolutionVariant method () is called in 
>>> each draw of the image. For this purpose in documentation for a 
>>> class and in a documentation for constructors it was specified that 
>>> the array shall be sorted. It is the reason why the bug of 
>>> JDK-8147849 was closed.
>> This seems to me a mistake in the API design which this update is 
>> trying to fix. Since we opened this API for everybody's use the base 
>> implementation of the MultiResolutionImage  should  be covering its 
>> most frequent and general usage. And in this general usage the 
>> appropriate resolution among the provided image variants should be 
>> chosen at the time the MR image is drawn. This is the logic we use 
>> internally in JDK to draw icons and other UI stuff on the HiDPI 
>> display and it is in demand for user applications in most cases.
>> When a predefined order of the image variant selection is required 
>> then getResolutionVariant() may be overridden to achieve that. But 
>> obviously this is a rare case and it shouldn't be a basic 
>> implementation.
>>
>> --Semyon
>>>
>>> RFE which you try to fix cover another use-case:
>>> If the user will use the sorted array  [@1 , at 20] then we should 
>>> select @1 if "-Dsun.java2d.uiScale=2" is used but not @20
>>>
>>> On 9/6/17 19:31, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK10:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8148619
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8148619/webrev.00/
>>>>
>>>> The algorithm selecting the best resolution variant of the 
>>>> BaseMultiResolutionImage was updated to be insensitive to the order 
>>>> of image variants in the initially provided array.
>>>>
>>>> The BaseMultiResolutionImage specification was updated 
>>>> correspondingly.
>>>>
>>>> --Semyon
>>>>
>>>
>>>
>>
>
>


From semyon.sadetsky at oracle.com  Sat Sep  9 03:00:11 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 8 Sep 2017 20:00:11 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE tests
 fail after frame dispose() on Linux
Message-ID: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>

Hello,

Please review fix for JDK10:

bug: https://bugs.openjdk.java.net/browse/JDK-8186495

webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/

After toolkit window is destroyed methods invocations on the window 
component may cause exceptions because of wrong native xwindow ID. The 
fix introduces checks in the X* peers to ensure that window ID is actual 
otherwise do nothing.

--Semyon


From Sergey.Bylokhov at oracle.com  Mon Sep 11 22:20:30 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 11 Sep 2017 15:20:30 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
Message-ID: <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>

Hi, Semyon.
Did you check why the bug is not reproduced on jdk8?
I guess that it is still possible to get a situations below because of 
absent synchronization on all paths of usage "window",isDispose() and 
dispose() method:
  - check isDispose().
  - dispose the peer
  - use the long value which was disposed step above


On 9/8/17 20:00, Semyon Sadetsky wrote:
> Hello,
> 
> Please review fix for JDK10:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
> 
> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
> 
> After toolkit window is destroyed methods invocations on the window 
> component may cause exceptions because of wrong native xwindow ID. The 
> fix introduces checks in the X* peers to ensure that window ID is actual 
> otherwise do nothing.
> 
> --Semyon
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Sep 12 23:51:39 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Sep 2017 16:51:39 -0700
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default>
References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default>
 <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default>
Message-ID: <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com>

Hi, Shashi.
One initial question:
What is an int parameter of these methods means, is it a "Unicode code 
point"? What encoding utf8/utf16 should be used?

On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:
> Hi, I have updated the Webrev to accommodate the comments and here is 
> the new Webrev:
> 
> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/
> 
> I have separated the /_Unicode_/ keys input via java robot as a new set 
> of /_public_/ api?s (this is in similar fashion as how the platform 
> offers the Unicode keys input into the system) and this has been tested 
> on all the platforms using the test file similar to the attached file in 
> the bug. A more proper test file would be put for review in the 
> subsequent reviews.
> 
> Thanks and regards,
> 
> Shashi
> 
> *From:* Sergey Bylokhov
> *Sent:* Wednesday, August 30, 2017 2:33 AM
> *To:* Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
> *Cc:* awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be 
> able to use extended key code characters as ? ? ?.
> 
> Hi, Shashi.
> 
> This is part of this fix, to figure out how it will work for external 
> applications. As you said this functionally can be useful for an 
> onscreen keyboards, which virtually can have any possible keys, but we 
> should check how the applications will react on such keys:
>  ?- Will the application get some kind of keyPress/Release?
>  ?- Will the application get some keyCode for such event?
>  ?- Is it possible to get autorepeat for such keys?(between press/release)
> 
> Depending from the answers above we can enhance existed robot API or 
> provide a new one:
> like Robot.keyType(char)/etc
> 
> ----- shashidhara.veerabhadraiah at oracle.com 
> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:
>> 
> 
>> 
> 
>> 
> 
> Hi Sergey, I was only able to add short cut keys in the Microsoft word 
> but not as a system wide short cut key. There was no mechanism that I 
> could find to add a short cut key for a Unicode char!! Can you please 
> tell me the steps to do the same if you are aware of?
> 
> Thanks and regards,
> 
> shashi
> 
>> 
> 
> *From:*Sergey Bylokhov
>> *Sent:* Tuesday, August 22, 2017 8:34 PM
>> *To:* Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com 
> <mailto:shashidhara.veerabhadraiah at oracle.com>>
>> *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be 
> able to use extended key code characters as ? ? ?.
> 
> Hi, Shashi.
>> Can you check how this Robot API will work when the application will have a shortcut for such key? Will such shortcuts will work after this fix? 
>> 
>> ----- shashidhara.veerabhadraiah at oracle.com 
> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:
>> > 
> 
>> 
> 
>> 
> 
> Hi All, Please review fix for the /_enhancement_/ wherein the robot key 
> press of non-ascii were interpreted as question marks.
> 
> Issue: The robot key press events was handling only the ascii inputs and 
> ignored the other Unicode inputs. Either it was throwing illegal 
> argument exception in windows or does nothing on the mac for those 
> Unicode inputs.
> 
> Solution and fix: The platform specific api?s was unable handle the 
> non-ascii inputs. I have modified the api?s to accept the non-ascii 
> inputs and correspondingly send the message to the window to print the 
> non-ascii characters as well. Below is the picture of how the non-ascii 
> inputs are considered and printed onto the window.
> 
> The solution spans across windows and mac platform and still in search 
> of a solution for the Linux platform. The solution implements key 
> scanning only upon existing valid ascii key was /_not_/ found and 
> assumes it as Unicode key and sends the event to event queue to be 
> processed as Unicode keys. Different formats are being used by different 
> platform implementation of Unicode. For ex., per the below Unicode list, 
> in the case of windows and mac, the key input can take decimal values 
> whereas on Linux it can only take the Code values.
> 
> On Linux, I was able to get the KeySym of Unicode keys but was unable to 
> fake the key event as there was no mechanism available for the 
> same(which sends the key event to window). Please let me know if there 
> is any such mechanism available to simulate Unicode key events on Linux 
> platform. Hence I think to raise a bug for the Linux platform and close 
> this JDK-8148344 bug.
> 
> Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344
> 
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/
> 
> Thanks and regards,
> 
> Shashi
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Sep 13 10:11:17 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 13 Sep 2017 15:41:17 +0530
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
In-Reply-To: <bc568398-c4e4-41de-be9a-b2f3c57832fb@default>
References: <bc568398-c4e4-41de-be9a-b2f3c57832fb@default>
Message-ID: <dc2d8bd8-9c61-ab13-1405-1338920f9fca@oracle.com>

Hi Sergey,

I have modified the fix to not use SecondaryLoop and not to create one 
thread per dispatch
http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/

Regards
Prasanta
On 8/30/2017 11:41 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> Can you please provide some description on how the SecondaryLoop will work when it will run on Appkit thread? Is it possible to get a deadlock here, since appkit will be blocked?
>
>> sequence, ie if the event is not first in sequence, then it will made
>> to
>> wait till it is the first event or till it is disposed.
> Note that the new code (unlike lines 139-150) also waits 1 second, so we can get a situation when only one event will be dispatched per second, which is not we want to do.
> I am not sure how often we create SequencedEvent but creating one thread per dispatch look inefficient.
>
>
>> Modified webrev
>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/
>>
>> Regards
>> Prasanta
>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>>
>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
>>>> Now, since here FX App thread itself is the dispatch thread, we can
>>>> be sure the events are dispatched in sequence and dispose is
>> checked
>>>> below after EDT.
>>> Why we can sure about this? If the SequencedEvents were created in
>> one
>>> order but dispatch() for each were called in other order then the
>>> sequenced will not be preserved?
>>>
>>>> I have tested with couple of singleThread testcase without any
>> issue.
>>>> Regards
>>>> Prasanta
>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta, Kevin.
>>>>>
>>>>> I have two notes.
>>>>>  ? - Does this option is really supported? If it is supported we
>>>>> should evaluate all usage of EventDispatchThread because in this
>>>>> mode the dispatch thread is not EDT. For example I am not sure
>> that
>>>>> we can skip the code which expects EventDispatchThread.
>>>>>  ? - We have the similar pattern: "EventQueue.isDispatchThread() ->
>>>>> cast(EventDispatchThread)" in some other places like in
>>>>> DefaultKeyboardFocusManager.
>>>>>
>>>>> -----prasanta.sadhukhan at oracle.com? wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Please review this fix
>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>>>>>> for an fx issue
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>>>>>
>>>>>> More info in JBS.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>


From semyon.sadetsky at oracle.com  Wed Sep 13 18:01:41 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 13 Sep 2017 11:01:41 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access to
 Windows Large Icons
Message-ID: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>

Hello,

Please review fix for JDK10 (the changes involve AWT and Swing):

bug: https://bugs.openjdk.java.net/browse/JDK-8182043

webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/

The fix  opens the part of the ShellFolder API for getting system icons 
which was decided to be left closed during the 8081722 enhancement 
review in 9.

Also the fix extends the API by adding possibility to query file icons 
of arbitrary size and implements this extension for Windows platform.

--Semyon


From semyon.sadetsky at oracle.com  Wed Sep 13 18:49:09 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 13 Sep 2017 11:49:09 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
 <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
Message-ID: <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>

Hi Sergey,

The tests passes after the fix for me. Which situations do you mean? Can 
you provide examples?

--Semyon


On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:
> Hi, Semyon.
> Did you check why the bug is not reproduced on jdk8?
> I guess that it is still possible to get a situations below because of 
> absent synchronization on all paths of usage "window",isDispose() and 
> dispose() method:
>  - check isDispose().
>  - dispose the peer
>  - use the long value which was disposed step above
>
>
> On 9/8/17 20:00, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK10:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
>>
>> After toolkit window is destroyed methods invocations on the window 
>> component may cause exceptions because of wrong native xwindow ID. 
>> The fix introduces checks in the X* peers to ensure that window ID is 
>> actual otherwise do nothing.
>>
>> --Semyon
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Sep 13 18:55:33 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Sep 2017 11:55:33 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
 <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
 <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>
Message-ID: <4d3ae69d-7683-9945-a031-35825068f3b3@oracle.com>

On 9/13/17 11:49, Semyon Sadetsky wrote:
> The tests passes after the fix for me. Which situations do you mean? Can 
> you provide examples?

For example in XFramePeer.setVisible() it is possible that the peer 
became disposed after the new check.

> 
> --Semyon
> 
> 
> On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>> Did you check why the bug is not reproduced on jdk8?
>> I guess that it is still possible to get a situations below because of 
>> absent synchronization on all paths of usage "window",isDispose() and 
>> dispose() method:
>> ?- check isDispose().
>> ?- dispose the peer
>> ?- use the long value which was disposed step above
>>
>>
>> On 9/8/17 20:00, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK10:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
>>>
>>> After toolkit window is destroyed methods invocations on the window 
>>> component may cause exceptions because of wrong native xwindow ID. 
>>> The fix introduces checks in the X* peers to ensure that window ID is 
>>> actual otherwise do nothing.
>>>
>>> --Semyon
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Wed Sep 13 19:19:03 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 13 Sep 2017 12:19:03 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <4d3ae69d-7683-9945-a031-35825068f3b3@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
 <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
 <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>
 <4d3ae69d-7683-9945-a031-35825068f3b3@oracle.com>
Message-ID: <0d43afe4-2815-4f56-1d77-c51407fa76f1@oracle.com>

If you mean invoking setVisisble() and dispose() on different threads in 
parallel then this occasionally may cause similar issue. But this is not 
the standard way  to call the API.

Obviously those peers was not developed with the multi-threaded access 
kept in mind.

--Semyon


On 09/13/2017 11:55 AM, Sergey Bylokhov wrote:
> On 9/13/17 11:49, Semyon Sadetsky wrote:
>> The tests passes after the fix for me. Which situations do you mean? 
>> Can you provide examples?
>
> For example in XFramePeer.setVisible() it is possible that the peer 
> became disposed after the new check.
>
>>
>> --Semyon
>>
>>
>> On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:
>>> Hi, Semyon.
>>> Did you check why the bug is not reproduced on jdk8?
>>> I guess that it is still possible to get a situations below because 
>>> of absent synchronization on all paths of usage "window",isDispose() 
>>> and dispose() method:
>>>  - check isDispose().
>>>  - dispose the peer
>>>  - use the long value which was disposed step above
>>>
>>>
>>> On 9/8/17 20:00, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK10:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
>>>>
>>>> After toolkit window is destroyed methods invocations on the window 
>>>> component may cause exceptions because of wrong native xwindow ID. 
>>>> The fix introduces checks in the X* peers to ensure that window ID 
>>>> is actual otherwise do nothing.
>>>>
>>>> --Semyon
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Sep 13 19:30:35 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Sep 2017 12:30:35 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <0d43afe4-2815-4f56-1d77-c51407fa76f1@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
 <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
 <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>
 <4d3ae69d-7683-9945-a031-35825068f3b3@oracle.com>
 <0d43afe4-2815-4f56-1d77-c51407fa76f1@oracle.com>
Message-ID: <3f47f95c-de47-c219-5c8f-a04074197923@oracle.com>

On 9/13/17 12:19, Semyon Sadetsky wrote:
> Obviously those peers was not developed with the multi-threaded access 
> kept in mind.

It is not obviously since it should be thread safe, and it is already 
used minimum from 3 threads main/edt/toolkit.

> 
> --Semyon
> 
> 
> On 09/13/2017 11:55 AM, Sergey Bylokhov wrote:
>> On 9/13/17 11:49, Semyon Sadetsky wrote:
>>> The tests passes after the fix for me. Which situations do you mean? 
>>> Can you provide examples?
>>
>> For example in XFramePeer.setVisible() it is possible that the peer 
>> became disposed after the new check.
>>
>>>
>>> --Semyon
>>>
>>>
>>> On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:
>>>> Hi, Semyon.
>>>> Did you check why the bug is not reproduced on jdk8?
>>>> I guess that it is still possible to get a situations below because 
>>>> of absent synchronization on all paths of usage "window",isDispose() 
>>>> and dispose() method:
>>>> ?- check isDispose().
>>>> ?- dispose the peer
>>>> ?- use the long value which was disposed step above
>>>>
>>>>
>>>> On 9/8/17 20:00, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK10:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
>>>>>
>>>>> After toolkit window is destroyed methods invocations on the window 
>>>>> component may cause exceptions because of wrong native xwindow ID. 
>>>>> The fix introduces checks in the X* peers to ensure that window ID 
>>>>> is actual otherwise do nothing.
>>>>>
>>>>> --Semyon
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Wed Sep 13 20:19:10 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 13 Sep 2017 13:19:10 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <3f47f95c-de47-c219-5c8f-a04074197923@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
 <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
 <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>
 <4d3ae69d-7683-9945-a031-35825068f3b3@oracle.com>
 <0d43afe4-2815-4f56-1d77-c51407fa76f1@oracle.com>
 <3f47f95c-de47-c219-5c8f-a04074197923@oracle.com>
Message-ID: <bdcaa9ce-9781-105d-64e8-1f67ce38f316@oracle.com>

On 09/13/2017 12:30 PM, Sergey Bylokhov wrote:

> On 9/13/17 12:19, Semyon Sadetsky wrote:
>> Obviously those peers was not developed with the multi-threaded 
>> access kept in mind.
>
> It is not obviously since it should be thread safe, and it is already 
> used minimum from 3 threads main/edt/toolkit.
Can you provide examples where dispose() and setVisible() is called 
simultaneously from different threads in JDK code?
Making Linux peers thread-safe would be too big change that may 
introduce deadlocks. We don't need to make situation even worse than it 
is now.

--Semyon
>
>>
>> --Semyon
>>
>>
>> On 09/13/2017 11:55 AM, Sergey Bylokhov wrote:
>>> On 9/13/17 11:49, Semyon Sadetsky wrote:
>>>> The tests passes after the fix for me. Which situations do you 
>>>> mean? Can you provide examples?
>>>
>>> For example in XFramePeer.setVisible() it is possible that the peer 
>>> became disposed after the new check.
>>>
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:
>>>>> Hi, Semyon.
>>>>> Did you check why the bug is not reproduced on jdk8?
>>>>> I guess that it is still possible to get a situations below 
>>>>> because of absent synchronization on all paths of usage 
>>>>> "window",isDispose() and dispose() method:
>>>>>  - check isDispose().
>>>>>  - dispose the peer
>>>>>  - use the long value which was disposed step above
>>>>>
>>>>>
>>>>> On 9/8/17 20:00, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK10:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
>>>>>>
>>>>>> After toolkit window is destroyed methods invocations on the 
>>>>>> window component may cause exceptions because of wrong native 
>>>>>> xwindow ID. The fix introduces checks in the X* peers to ensure 
>>>>>> that window ID is actual otherwise do nothing.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Sep 13 22:08:57 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Sep 2017 15:08:57 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <bdcaa9ce-9781-105d-64e8-1f67ce38f316@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
 <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
 <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>
 <4d3ae69d-7683-9945-a031-35825068f3b3@oracle.com>
 <0d43afe4-2815-4f56-1d77-c51407fa76f1@oracle.com>
 <3f47f95c-de47-c219-5c8f-a04074197923@oracle.com>
 <bdcaa9ce-9781-105d-64e8-1f67ce38f316@oracle.com>
Message-ID: <28e93e42-2993-2394-0669-cd54747d5925@oracle.com>

On 9/13/17 13:19, Semyon Sadetsky wrote:
>> It is not obviously since it should be thread safe, and it is already 
>> used minimum from 3 threads main/edt/toolkit.
> Can you provide examples where dispose() and setVisible() is called 
> simultaneously from different threads in JDK code?
> Making Linux peers thread-safe would be too big change that may 
> introduce deadlocks. We don't need to make situation even worse than it 
> is now.

It should be already thread safe, there were even your fixes when the 
synchronization in the peers was reworked:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/500fb73e193f
The problem in the fix is that the new checks do not try to be thread safe.

> 
> --Semyon
>>
>>>
>>> --Semyon
>>>
>>>
>>> On 09/13/2017 11:55 AM, Sergey Bylokhov wrote:
>>>> On 9/13/17 11:49, Semyon Sadetsky wrote:
>>>>> The tests passes after the fix for me. Which situations do you 
>>>>> mean? Can you provide examples?
>>>>
>>>> For example in XFramePeer.setVisible() it is possible that the peer 
>>>> became disposed after the new check.
>>>>
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:
>>>>>> Hi, Semyon.
>>>>>> Did you check why the bug is not reproduced on jdk8?
>>>>>> I guess that it is still possible to get a situations below 
>>>>>> because of absent synchronization on all paths of usage 
>>>>>> "window",isDispose() and dispose() method:
>>>>>> ?- check isDispose().
>>>>>> ?- dispose the peer
>>>>>> ?- use the long value which was disposed step above
>>>>>>
>>>>>>
>>>>>> On 9/8/17 20:00, Semyon Sadetsky wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review fix for JDK10:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
>>>>>>>
>>>>>>> After toolkit window is destroyed methods invocations on the 
>>>>>>> window component may cause exceptions because of wrong native 
>>>>>>> xwindow ID. The fix introduces checks in the X* peers to ensure 
>>>>>>> that window ID is actual otherwise do nothing.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Wed Sep 13 22:36:43 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 13 Sep 2017 15:36:43 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <28e93e42-2993-2394-0669-cd54747d5925@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
 <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
 <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>
 <4d3ae69d-7683-9945-a031-35825068f3b3@oracle.com>
 <0d43afe4-2815-4f56-1d77-c51407fa76f1@oracle.com>
 <3f47f95c-de47-c219-5c8f-a04074197923@oracle.com>
 <bdcaa9ce-9781-105d-64e8-1f67ce38f316@oracle.com>
 <28e93e42-2993-2394-0669-cd54747d5925@oracle.com>
Message-ID: <59B9B2FB.7050503@oracle.com>

On 9/13/2017 3:08 PM, Sergey Bylokhov wrote:
> On 9/13/17 13:19, Semyon Sadetsky wrote:
>>> It is not obviously since it should be thread safe, and it is 
>>> already used minimum from 3 threads main/edt/toolkit.
>> Can you provide examples where dispose() and setVisible() is called 
>> simultaneously from different threads in JDK code?
>> Making Linux peers thread-safe would be too big change that may 
>> introduce deadlocks. We don't need to make situation even worse than 
>> it is now.
>
> It should be already thread safe, there were even your fixes when the 
> synchronization in the peers was reworked:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/500fb73e193f
This fix improves synchronization for window dimensions stability and 
that was done after the frame extents algorithm was rewritten. The 
latter caused a lot of regressions because there are many scenarios 
which are not covered by tests.  Anyway this didn't far solve all 
mulithreading issues in linux peers. It would require total redesign.
Adding volatile modifier to all fields will not make those classes 
totally safe in multithreaded use.

> The problem in the fix is that the new checks do not try to be thread 
> safe.
So, what do you propose? Add a volatile field "disposing" and do noop if 
it is true?

>
>>
>> --Semyon
>>>
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 09/13/2017 11:55 AM, Sergey Bylokhov wrote:
>>>>> On 9/13/17 11:49, Semyon Sadetsky wrote:
>>>>>> The tests passes after the fix for me. Which situations do you 
>>>>>> mean? Can you provide examples?
>>>>>
>>>>> For example in XFramePeer.setVisible() it is possible that the 
>>>>> peer became disposed after the new check.
>>>>>
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:
>>>>>>> Hi, Semyon.
>>>>>>> Did you check why the bug is not reproduced on jdk8?
>>>>>>> I guess that it is still possible to get a situations below 
>>>>>>> because of absent synchronization on all paths of usage 
>>>>>>> "window",isDispose() and dispose() method:
>>>>>>>  - check isDispose().
>>>>>>>  - dispose the peer
>>>>>>>  - use the long value which was disposed step above
>>>>>>>
>>>>>>>
>>>>>>> On 9/8/17 20:00, Semyon Sadetsky wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review fix for JDK10:
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
>>>>>>>>
>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
>>>>>>>>
>>>>>>>> After toolkit window is destroyed methods invocations on the 
>>>>>>>> window component may cause exceptions because of wrong native 
>>>>>>>> xwindow ID. The fix introduces checks in the X* peers to ensure 
>>>>>>>> that window ID is actual otherwise do nothing.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Sep 13 22:42:33 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Sep 2017 15:42:33 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <59B9B2FB.7050503@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
 <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
 <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>
 <4d3ae69d-7683-9945-a031-35825068f3b3@oracle.com>
 <0d43afe4-2815-4f56-1d77-c51407fa76f1@oracle.com>
 <3f47f95c-de47-c219-5c8f-a04074197923@oracle.com>
 <bdcaa9ce-9781-105d-64e8-1f67ce38f316@oracle.com>
 <28e93e42-2993-2394-0669-cd54747d5925@oracle.com>
 <59B9B2FB.7050503@oracle.com>
Message-ID: <5613bc79-21d8-620b-a864-9685dcc805cd@oracle.com>

On 9/13/17 15:36, Semyon Sadetsky wrote:
>> The problem in the fix is that the new checks do not try to be thread 
>> safe.
> So, what do you propose? Add a volatile field "disposing" and do noop if 
> it is true?

I have added a links to the bug which contain an examples, of how it was 
implemented in other cases.

> 
>>
>>>
>>> --Semyon
>>>>
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 09/13/2017 11:55 AM, Sergey Bylokhov wrote:
>>>>>> On 9/13/17 11:49, Semyon Sadetsky wrote:
>>>>>>> The tests passes after the fix for me. Which situations do you 
>>>>>>> mean? Can you provide examples?
>>>>>>
>>>>>> For example in XFramePeer.setVisible() it is possible that the 
>>>>>> peer became disposed after the new check.
>>>>>>
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>>
>>>>>>> On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Semyon.
>>>>>>>> Did you check why the bug is not reproduced on jdk8?
>>>>>>>> I guess that it is still possible to get a situations below 
>>>>>>>> because of absent synchronization on all paths of usage 
>>>>>>>> "window",isDispose() and dispose() method:
>>>>>>>> ?- check isDispose().
>>>>>>>> ?- dispose the peer
>>>>>>>> ?- use the long value which was disposed step above
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/8/17 20:00, Semyon Sadetsky wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review fix for JDK10:
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
>>>>>>>>>
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
>>>>>>>>>
>>>>>>>>> After toolkit window is destroyed methods invocations on the 
>>>>>>>>> window component may cause exceptions because of wrong native 
>>>>>>>>> xwindow ID. The fix introduces checks in the X* peers to ensure 
>>>>>>>>> that window ID is actual otherwise do nothing.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Thu Sep 14 09:55:39 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 14 Sep 2017 09:55:39 +0000 (UTC)
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch
 keyboard is not shown for text components on a screen touch
In-Reply-To: <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
 <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
 <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
Message-ID: <2a1527c5-938c-418c-83aa-8d70afe16999@default>

Hi Anton, I have a question to ask for. I was working on another bug and found that the WM_TOUCH has been deprecated and instead we should be using the WM_POINTER? Here is some info on that: https://stackoverflow.com/questions/23790602/wm-touch-vs-wm-pointer

Typically, the WM_POINTER types can handle following type of pointers:
typedef enum tagPOINTER_INPUT_TYPE { 
  PT_POINTER   = 0x00000001,
  PT_TOUCH     = 0x00000002,
  PT_PEN       = 0x00000003,
  PT_MOUSE     = 0x00000004,
  PT_TOUCHPAD  = 0x00000005
} POINTER_INPUT_TYPE;

Hope this is useful for your fix.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, September 5, 2017 10:45 PM
To: Anton Litvinov <anton.litvinov at oracle.com>; awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

Hi, Anton.
The fix looks good.
  - But can you please recheck that is is not necessary to use additional synchronization in showOrHideTouchKeyboard() if a few EDT will be used.
  - I suggest to invert the awt.touchKeyboardAutoShowIsEnabled and use true as default value, we will have more coverage and feedback in this case. This property will be used as a workaround if some bugs will be found.

On 8/30/17 11:51, Anton Litvinov wrote:
> Hello dear reviewers,
> 
> Could anybody please look at this review request?
> 
> Thank you,
> Anton
> 
> On 17/08/2017 13:20, Anton Litvinov wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166772
>> Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00
>>
>> The bug is the fact that, when a user touches any Swing or AWT text 
>> component, for example "JTextField", "JTextArea", "TextField", 
>> "TextArea", by means of a touch screen on a host with MS Windows
>> 10/8.1/8 OS, the system touch keyboard is not shown automatically. 
>> Please find a detailed description of the bug, screenshots depicting 
>> the touch keyboard and a compilable test case with Swing/AWT text 
>> components in JBS bug record. Also a summary of the done research of 
>> the issue with a description of identified approaches for its 
>> resolution are reported in my last comment in the bug record.
>>
>> THE FIX:
>> On a very abstract level the fix functioning can be presented by the 
>> next 3 stages:
>>
>> Stage 1.
>> The fix adds support of "WM_TOUCH" system window messages to AWT 
>> native peer windows through C++ class "AwtComponent". It "processes"
>> "WM_TOUCH" message and marks "java.awt.event.MouseEvent", which is 
>> created as a result of handling of the further coming 
>> "WM_LBUTTONDOWN", "WM_LBUTTONUP" messages sent by the system in 
>> substitution for this "WM_TOUCH" message, by the new private field 
>> flag "MouseEvent.causedByTouchEvent".
>>
>> Stage 2.
>> Then on Java level the fix handles "MouseEvent", "FocusEvent" 
>> received only by the instances of "java.awt.TextComponent", 
>> "javax.swing.text.TextComponent" in 
>> "WToolkit.showOrHideTouchKeyboard()" called from 
>> "Component.dispatchEventImpl()" and shows or hides the touch keyboard 
>> on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" events by 
>> calling corresponding native methods of "WToolkit" class.
>>
>> Stage 3.
>> Showing of the touch keyboard is implemented in C++ class "AwtToolkit" 
>> and is done by launching the system application "TabTip.exe" which 
>> implements the system touch keyboard. This approach is described in 
>> the bug record.
>>
>> FEATURES OF THE FIX:
>> 1. By default all native and Java parts of the fix do not function at 
>> all - the fix is disabled. To enable the fix the application should 
>> be run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" option. 
>> Handling of this new property is implemented in "sun.awt.SunToolkit" class.
>>
>> 2. Native parts of the fix functions only on MS Window 8 or later.
>>
>> 3. The fix implements automatic showing of the touch keyboard for the 
>> following 2 use cases:
>> ??? a.? The user touches the text components using the touch screen.
>> ??? b.? The user does mouse clicks on the text components, while no 
>> any keyboard is attached to the host.
>>
>> FIX LOGICAL STRUCTURE BY SOURCE CODE:
>> 1. Core of the fix:
>> ??? Native code:? awt_Toolkit.[h/cpp], awt_Component.[h/cpp], 
>> awt_MouseEvent.[h/cpp], awt.h
>> ??? Java:? SunToolkit.java, WToolkit.java, Component.java, 
>> MouseEvent.java, AWTAccessor.java
>>
>> 2. Changes in all remaining Java files are connected with retaining 
>> of the flag value "MouseEvent.causedByTouchEvent" during creation of 
>> the new instances of "MouseEvent" class based on the original "MouseEvent"
>> instances.
>>
>> Work of the fix was verified both in the environment with the real 
>> touch screen device and in the environment with the emulated touch 
>> screen.
>>
>> Thank you,
>> Anton
> 


--
Best regards, Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170914/d60fce4d/attachment-0001.html>

From pankaj.b.bansal at oracle.com  Thu Sep 14 10:25:59 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 14 Sep 2017 10:25:59 +0000 (UTC)
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
Message-ID: <c6231728-9548-4e13-b46b-f3c6309b9701@default>

Hi All,

 

Please review the fix for test program test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.

 

Bug:

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

 

Webrev:

http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/

 

Issue:

The test java/awt/ComponentOrientation/WindowTest.java uses depreciated function  applyResourceBundle. So the test should be updated to use applyComponentOrientation function. 

 

Fix:

Made changes in java/awt/ComponentOrientation/WindowTest.java to use applyComponentOrientation function and did corresponding changes. Along with that, the test is also using java.applet.Applet which is also deprecated, so changed the test to use Frame instead.

 

 

Regards,

Pankaj Bansal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170914/25b15b65/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Thu Sep 14 10:56:48 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 14 Sep 2017 10:56:48 +0000 (UTC)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com>
References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default>
 <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default>
 <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com>
Message-ID: <992a8202-6ac9-4c16-9fe5-c316e314bed5@default>

Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, September 13, 2017 5:22 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

Hi, Shashi.
One initial question:
What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?

On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:
> Hi, I have updated the Webrev to accommodate the comments and here is 
> the new Webrev:
> 
> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/
> 
> I have separated the /_Unicode_/ keys input via java robot as a new 
> set of /_public_/ api?s (this is in similar fashion as how the 
> platform offers the Unicode keys input into the system) and this has 
> been tested on all the platforms using the test file similar to the 
> attached file in the bug. A more proper test file would be put for 
> review in the subsequent reviews.
> 
> Thanks and regards,
> 
> Shashi
> 
> *From:* Sergey Bylokhov
> *Sent:* Wednesday, August 30, 2017 2:33 AM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>
> *Cc:* awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should 
> be able to use extended key code characters as ? ? ?.
> 
> Hi, Shashi.
> 
> This is part of this fix, to figure out how it will work for external 
> applications. As you said this functionally can be useful for an 
> onscreen keyboards, which virtually can have any possible keys, but we 
> should check how the applications will react on such keys:
>  ?- Will the application get some kind of keyPress/Release?
>  ?- Will the application get some keyCode for such event?
>  ?- Is it possible to get autorepeat for such keys?(between 
> press/release)
> 
> Depending from the answers above we can enhance existed robot API or 
> provide a new one:
> like Robot.keyType(char)/etc
> 
> ----- shashidhara.veerabhadraiah at oracle.com
> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:
>> 
> 
>> 
> 
>> 
> 
> Hi Sergey, I was only able to add short cut keys in the Microsoft word 
> but not as a system wide short cut key. There was no mechanism that I 
> could find to add a short cut key for a Unicode char!! Can you please 
> tell me the steps to do the same if you are aware of?
> 
> Thanks and regards,
> 
> shashi
> 
>> 
> 
> *From:*Sergey Bylokhov
>> *Sent:* Tuesday, August 22, 2017 8:34 PM
>> *To:* Shashidhara Veerabhadraiah 
>> <shashidhara.veerabhadraiah at oracle.com
> <mailto:shashidhara.veerabhadraiah at oracle.com>>
>> *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should 
>> be
> able to use extended key code characters as ? ? ?.
> 
> Hi, Shashi.
>> Can you check how this Robot API will work when the application will have a shortcut for such key? Will such shortcuts will work after this fix? 
>> 
>> ----- shashidhara.veerabhadraiah at oracle.com
> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:
>> > 
> 
>> 
> 
>> 
> 
> Hi All, Please review fix for the /_enhancement_/ wherein the robot 
> key press of non-ascii were interpreted as question marks.
> 
> Issue: The robot key press events was handling only the ascii inputs 
> and ignored the other Unicode inputs. Either it was throwing illegal 
> argument exception in windows or does nothing on the mac for those 
> Unicode inputs.
> 
> Solution and fix: The platform specific api?s was unable handle the 
> non-ascii inputs. I have modified the api?s to accept the non-ascii 
> inputs and correspondingly send the message to the window to print the 
> non-ascii characters as well. Below is the picture of how the 
> non-ascii inputs are considered and printed onto the window.
> 
> The solution spans across windows and mac platform and still in search 
> of a solution for the Linux platform. The solution implements key 
> scanning only upon existing valid ascii key was /_not_/ found and 
> assumes it as Unicode key and sends the event to event queue to be 
> processed as Unicode keys. Different formats are being used by 
> different platform implementation of Unicode. For ex., per the below 
> Unicode list, in the case of windows and mac, the key input can take 
> decimal values whereas on Linux it can only take the Code values.
> 
> On Linux, I was able to get the KeySym of Unicode keys but was unable 
> to fake the key event as there was no mechanism available for the 
> same(which sends the key event to window). Please let me know if there 
> is any such mechanism available to simulate Unicode key events on 
> Linux platform. Hence I think to raise a bug for the Linux platform 
> and close this JDK-8148344 bug.
> 
> Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344
> 
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/
> 
> Thanks and regards,
> 
> Shashi
> 


--
Best regards, Sergey.

From anton.litvinov at oracle.com  Thu Sep 14 12:20:55 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Thu, 14 Sep 2017 13:20:55 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch
 keyboard is not shown for text components on a screen touch
In-Reply-To: <2a1527c5-938c-418c-83aa-8d70afe16999@default>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
 <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
 <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
 <2a1527c5-938c-418c-83aa-8d70afe16999@default>
Message-ID: <918997f8-5ced-d9c9-455e-a2931135c70d@oracle.com>

Hello Shashi,

Thank you for attention to my review request. Win32 API provides 
different API sets dedicated to handling various types of user's touch 
input in different degree of deepness. For example:
1.  Windows Touch Input (WM_TOUCH messages)
2.  Windows Touch Gestures (WM_GESTURE messages)
     Official information about 2 API sets ab: 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd562100(v=vs.85).aspx
3.  Touch Hit Testing - 
https://msdn.microsoft.com/en-us/library/windows/desktop/hh437255(v=vs.85).aspx

WM_POINTER may be yet another approach.

I chose to exploit API related to "WM_TOUCH" message, because this API, 
as I understand, provides more opportunities to control the touch input 
then other 2 APIs specified above, and it allows to handle multiple 
touch points, what may become necessary in future.

RESPONSE TO YOUR REMARK:
I cannot agree that "WM_TOUCH" is officially deprecated. In the official 
Win32 API specification there is no information that functions from this 
API are deprecated or obsolete. For example:
1.  RegisterTouchWindow - 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317326(v=vs.85).aspx
2.  GetTouchInputInfo - 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd371582(v=vs.85).aspx
3.  TOUCHINPUT - 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317334(v=vs.85).aspx
4.  WM_TOUCH - 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317341(v=vs.85).aspx
     (There is some community comment, but community comments are 
written by anybody, deprecation is not announced in community comments. 
For example, the really deprecated function is "GetVersion" - 
(https://msdn.microsoft.com/en-us/library/windows/desktop/ms724439(v=vs.85).aspx)).

The web page, whose reference you provided is just a forum, is not Win32 
API specification or official announcement from Microsoft. So I would 
not rely on this information.

Additionally approach based on "WM_TOUCH" showed itself in my test 
environment reliably, WM_TOUCH are generated stably in MS Windows 10 OS, 
also I was able to successfully port the fix to JDK 8 and verify that it 
works. Currently I am working on addressing remarks from Sergey and do 
not plan to refuse from currently developed real basement of the whole 
fix, which uses WM_TOUCH.

Thank you,
Anton

On 14/09/2017 10:55, Shashidhara Veerabhadraiah wrote:
> RE: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch 
> keyboard is not shown for text components on a screen touch
>
> Hi Anton, I have a question to ask for. I was working on another bug 
> and found that the WM_TOUCHhas been deprecated and instead we should 
> be using the WM_POINTER? Here is some info on 
> that:_https://stackoverflow.com/questions/23790602/wm-touch-vs-wm-pointer_
>
> Typically, the WM_POINTER types can handle following type of/_pointers_/:
>
> typedef enum tagPOINTER_INPUT_TYPE {
>
> PT_POINTER   = 0x00000001,
>
> PT_TOUCH     = 0x00000002,
>
> PT_PEN       = 0x00000003,
>
> PT_MOUSE     = 0x00000004,
>
> PT_TOUCHPAD  = 0x00000005
>
> }POINTER_INPUT_TYPE;
>
> Hope this is useful foryourfix.
>
> Thanks and regards,
>
> Shashi
>
> -----Original Message-----
> From:Sergey Bylokhov
> Sent:Tuesday, September 5, 2017 10:45 PM
> To:Anton Litvinov <anton.litvinov at oracle.com>; 
> awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
> Subject:Re: <AWT Dev> <Swing Dev> [10] Review request for 8166772: 
> Touch keyboard is not shown for text components on a screen touch
>
> Hi, Anton.
>
> The fix looks good.
>
>   - But can you please recheck that is is not necessary to use 
> additional synchronization in showOrHideTouchKeyboard() if a few EDT 
> will be used.
>
>   - I suggest to invert the awt.touchKeyboardAutoShowIsEnabled and use 
> true as default value, we will have more coverage and feedback in this 
> case. This property will be used as a workaround if some bugs will be 
> found.
>
> On 8/30/17 11:51, Anton Litvinov wrote:
>
> > Hello dear reviewers,
>
> > 
>
> > Could anybody please look at this review request?
>
> > 
>
> > Thank you,
>
> > Anton
>
> > 
>
> > On 17/08/2017 13:20, Anton Litvinov wrote:
>
> >> Hello,
>
> >>
>
> >> Could you please review the following fix for the bug.
>
> >>
>
> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8166772
>
> >> Webrev:http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00<http://cr.openjdk.java.net/%7Ealitvinov/8166772/jdk10/webrev.00>
>
> >>
>
> >> The bug is the fact that, when a user touches any Swing or AWT text
>
> >> component, for example "JTextField", "JTextArea", "TextField",
>
> >> "TextArea", by means of a touch screen on a host with MS Windows
>
> >> 10/8.1/8 OS, the system touch keyboard is not shown automatically.
>
> >> Please find a detailed description of the bug, screenshots depicting
>
> >> the touch keyboard and a compilable test case with Swing/AWT text
>
> >> components in JBS bug record. Also a summary of the done research of
>
> >> the issue with a description of identified approaches for its
>
> >> resolution are reported in my last comment in the bug record.
>
> >>
>
> >> THE FIX:
>
> >> On a very abstract level the fix functioning can be presented by the
>
> >> next 3 stages:
>
> >>
>
> >> Stage 1.
>
> >> The fix adds support of "WM_TOUCH" system window messages to AWT
>
> >> native peer windows through C++ class "AwtComponent". It "processes"
>
> >> "WM_TOUCH" message and marks "java.awt.event.MouseEvent", which is
>
> >> created as a result of handling of the further coming
>
> >> "WM_LBUTTONDOWN", "WM_LBUTTONUP" messages sent by the system in
>
> >> substitution for this "WM_TOUCH" message, by the new private field
>
> >> flag "MouseEvent.causedByTouchEvent".
>
> >>
>
> >> Stage 2.
>
> >> Then on Java level the fix handles "MouseEvent", "FocusEvent"
>
> >> received only by the instances of "java.awt.TextComponent",
>
> >> "javax.swing.text.TextComponent" in
>
> >> "WToolkit.showOrHideTouchKeyboard()" called from
>
> >> "Component.dispatchEventImpl()" and shows or hidesthe touch keyboard
>
> >> on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" events by
>
> >> calling corresponding native methods of "WToolkit" class.
>
> >>
>
> >> Stage 3.
>
> >> Showing of the touch keyboard is implemented in C++ class "AwtToolkit"
>
> >> and is done by launching the system application "TabTip.exe" which
>
> >> implements the system touch keyboard. This approach is described in
>
> >> the bug record.
>
> >>
>
> >> FEATURES OF THE FIX:
>
> >> 1. By default all native and Java parts of the fix do not function at
>
> >> all - the fix is disabled. To enable the fix the application should
>
> >> be run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" option.
>
> >> Handling of this new property is implemented in "sun.awt.SunToolkit" 
> class.
>
> >>
>
> >> 2. Native parts of the fix functions only on MS Window 8 or later.
>
> >>
>
> >> 3. The fix implements automatic showing of the touch keyboard for the
>
> >> following 2 use cases:
>
> >> ??? a.? The user touches the text components using the touch screen.
>
> >> ??? b.? The user does mouse clicks on the text components, while no
>
> >> any keyboard is attached to the host.
>
> >>
>
> >> FIX LOGICAL STRUCTURE BY SOURCE CODE:
>
> >> 1. Core of the fix:
>
> >> ??? Native code:? awt_Toolkit.[h/cpp], awt_Component.[h/cpp],
>
> >> awt_MouseEvent.[h/cpp], awt.h
>
> >> ??? Java:? SunToolkit.java, WToolkit.java, Component.java,
>
> >> MouseEvent.java, AWTAccessor.java
>
> >>
>
> >> 2. Changes in all remaining Java files are connected with retaining
>
> >> of the flag value "MouseEvent.causedByTouchEvent" during creation of
>
> >> the new instances of "MouseEvent" class based on the original "MouseEvent"
>
> >> instances.
>
> >>
>
> >> Work of the fix was verified both in the environment with the real
>
> >> touch screen device and in the environment with the emulated touch
>
> >> screen.
>
> >>
>
> >> Thank you,
>
> >> Anton
>
> > 
>
>
> --
>
> Best regards, Sergey.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170914/30ba989f/attachment-0001.html>

From semyon.sadetsky at oracle.com  Thu Sep 14 14:58:19 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 14 Sep 2017 07:58:19 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
Message-ID: <59BA990B.6070207@oracle.com>

+1

--Semyon

On 9/14/2017 3:25 AM, Pankaj Bansal wrote:
>
> Hi All,
>
> Please review the fix for test program 
> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8081311
>
> Webrev:
>
> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/ 
> <http://cr.openjdk.java.net/%7Eaghaisas/pankaj/8081311/webrev.0/>
>
> Issue:
>
> The test java/awt/ComponentOrientation/WindowTest.java uses 
> depreciated function  applyResourceBundle. So the test should be 
> updated to use applyComponentOrientation function.
>
> Fix:
>
> Made changes in java/awt/ComponentOrientation/WindowTest.java to use 
> applyComponentOrientation function and did corresponding changes. 
> Along with that, the test is also using java.applet.Applet which is 
> also deprecated, so changed the test to use Frame instead.
>
> Regards,
>
> Pankaj Bansal
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170914/afdc2d63/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Sep 14 17:59:49 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Sep 2017 10:59:49 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
Message-ID: <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>

Hi, Pankaj.
Can you please clarify why this test fails on jdk9? This method is 
deprecated but it was not removed, so it should work.
Probably at some point of jdk9 development it was broken?

On 9/14/17 03:25, Pankaj Bansal wrote:
> Hi All,
> 
> Please review the fix for test program 
> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8081311
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
> 
> Issue:
> 
> The test java/awt/ComponentOrientation/WindowTest.java uses depreciated 
> function ?applyResourceBundle. So the test should be updated to use 
> applyComponentOrientation function.
> 
> Fix:
> 
> Made changes in java/awt/ComponentOrientation/WindowTest.java to use 
> applyComponentOrientation function and did corresponding changes. Along 
> with that, the test is also using java.applet.Applet which is also 
> deprecated, so changed the test to use Frame instead.
> 
> Regards,
> 
> Pankaj Bansal
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep 14 18:03:00 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Sep 2017 11:03:00 -0700
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <992a8202-6ac9-4c16-9fe5-c316e314bed5@default>
References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default>
 <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default>
 <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com>
 <992a8202-6ac9-4c16-9fe5-c316e314bed5@default>
Message-ID: <cd2f4c15-5ec0-a90b-c9d7-93152b6ead5e@oracle.com>

The java uses UTF16, I guess this new api should use it also, and we 
should check that the surrogate pairs will be supported.

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Wednesday, September 13, 2017 5:22 AM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.
> 
> Hi, Shashi.
> One initial question:
> What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?
> 
> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:
>> Hi, I have updated the Webrev to accommodate the comments and here is
>> the new Webrev:
>>
>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/
>>
>> I have separated the /_Unicode_/ keys input via java robot as a new
>> set of /_public_/ api?s (this is in similar fashion as how the
>> platform offers the Unicode keys input into the system) and this has
>> been tested on all the platforms using the test file similar to the
>> attached file in the bug. A more proper test file would be put for
>> review in the subsequent reviews.
>>
>> Thanks and regards,
>>
>> Shashi
>>
>> *From:* Sergey Bylokhov
>> *Sent:* Wednesday, August 30, 2017 2:33 AM
>> *To:* Shashidhara Veerabhadraiah
>> <shashidhara.veerabhadraiah at oracle.com>
>> *Cc:* awt-dev at openjdk.java.net
>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
>> be able to use extended key code characters as ? ? ?.
>>
>> Hi, Shashi.
>>
>> This is part of this fix, to figure out how it will work for external
>> applications. As you said this functionally can be useful for an
>> onscreen keyboards, which virtually can have any possible keys, but we
>> should check how the applications will react on such keys:
>>   ?- Will the application get some kind of keyPress/Release?
>>   ?- Will the application get some keyCode for such event?
>>   ?- Is it possible to get autorepeat for such keys?(between
>> press/release)
>>
>> Depending from the answers above we can enhance existed robot API or
>> provide a new one:
>> like Robot.keyType(char)/etc
>>
>> ----- shashidhara.veerabhadraiah at oracle.com
>> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:
>>>
>>
>>>
>>
>>>
>>
>> Hi Sergey, I was only able to add short cut keys in the Microsoft word
>> but not as a system wide short cut key. There was no mechanism that I
>> could find to add a short cut key for a Unicode char!! Can you please
>> tell me the steps to do the same if you are aware of?
>>
>> Thanks and regards,
>>
>> shashi
>>
>>>
>>
>> *From:*Sergey Bylokhov
>>> *Sent:* Tuesday, August 22, 2017 8:34 PM
>>> *To:* Shashidhara Veerabhadraiah
>>> <shashidhara.veerabhadraiah at oracle.com
>> <mailto:shashidhara.veerabhadraiah at oracle.com>>
>>> *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should
>>> be
>> able to use extended key code characters as ? ? ?.
>>
>> Hi, Shashi.
>>> Can you check how this Robot API will work when the application will have a shortcut for such key? Will such shortcuts will work after this fix?
>>>
>>> ----- shashidhara.veerabhadraiah at oracle.com
>> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:
>>>>
>>
>>>
>>
>>>
>>
>> Hi All, Please review fix for the /_enhancement_/ wherein the robot
>> key press of non-ascii were interpreted as question marks.
>>
>> Issue: The robot key press events was handling only the ascii inputs
>> and ignored the other Unicode inputs. Either it was throwing illegal
>> argument exception in windows or does nothing on the mac for those
>> Unicode inputs.
>>
>> Solution and fix: The platform specific api?s was unable handle the
>> non-ascii inputs. I have modified the api?s to accept the non-ascii
>> inputs and correspondingly send the message to the window to print the
>> non-ascii characters as well. Below is the picture of how the
>> non-ascii inputs are considered and printed onto the window.
>>
>> The solution spans across windows and mac platform and still in search
>> of a solution for the Linux platform. The solution implements key
>> scanning only upon existing valid ascii key was /_not_/ found and
>> assumes it as Unicode key and sends the event to event queue to be
>> processed as Unicode keys. Different formats are being used by
>> different platform implementation of Unicode. For ex., per the below
>> Unicode list, in the case of windows and mac, the key input can take
>> decimal values whereas on Linux it can only take the Code values.
>>
>> On Linux, I was able to get the KeySym of Unicode keys but was unable
>> to fake the key event as there was no mechanism available for the
>> same(which sends the key event to window). Please let me know if there
>> is any such mechanism available to simulate Unicode key events on
>> Linux platform. Hence I think to raise a bug for the Linux platform
>> and close this JDK-8148344 bug.
>>
>> Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344
>>
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/
>>
>> Thanks and regards,
>>
>> Shashi
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep 14 22:46:45 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Sep 2017 15:46:45 -0700
Subject: <AWT Dev> [10] Review Request: 8186559 [macos] the screen location
 is wrong when using AWT/SWT bridge with dual monitors
Message-ID: <a571cf64-a561-3b32-216d-4c9a1608e928@oracle.com>

Hello,
Please review the fix for jdk10.

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

When our NSView is embedded in native to the SWT-based NSWindow we 
incorrectly fetch the location of the NSView. The reason is that we use 
wrong screen when we flip the location. Currently we use [mainScreen] - 
which "returns the screen object containing the window with the keyboard 
focus", but we need the first screen which contains 0,0 coordinates.

In the fix the utility method is reused which internally uses
[[NSScreen screens] objectAtIndex:0]

-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Fri Sep 15 03:56:17 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Fri, 15 Sep 2017 03:56:17 +0000 (UTC)
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch
 keyboard is not shown for text components on a screen touch
In-Reply-To: <918997f8-5ced-d9c9-455e-a2931135c70d@oracle.com>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
 <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
 <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
 <2a1527c5-938c-418c-83aa-8d70afe16999@default>
 <918997f8-5ced-d9c9-455e-a2931135c70d@oracle.com>
Message-ID: <695522d5-f3db-4065-a81e-148c6e131396@default>

Thank you Anton for that information.

?

Thanks and regards,

Shashi

?

From: Anton Litvinov 
Sent: Thursday, September 14, 2017 5:51 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

?

Hello Shashi,

Thank you for attention to my review request. Win32 API provides different API sets dedicated to handling various types of user's touch input in different degree of deepness. For example:
1.? Windows Touch Input (WM_TOUCH messages)
2.? Windows Touch Gestures (WM_GESTURE messages)
??? Official information about 2 API sets ab: https://msdn.microsoft.com/en-us/library/windows/desktop/dd562100(v=vs.85).aspx
3.? Touch Hit Testing - https://msdn.microsoft.com/en-us/library/windows/desktop/hh437255(v=vs.85).aspx

WM_POINTER may be yet another approach.

I chose to exploit API related to "WM_TOUCH" message, because this API, as I understand, provides more opportunities to control the touch input then other 2 APIs specified above, and it allows to handle multiple touch points, what may become necessary in future.

RESPONSE TO YOUR REMARK:
I cannot agree that "WM_TOUCH" is officially deprecated. In the official Win32 API specification there is no information that functions from this API are deprecated or obsolete. For example:
1.? RegisterTouchWindow - https://msdn.microsoft.com/en-us/library/windows/desktop/dd317326(v=vs.85).aspx
2.? GetTouchInputInfo - https://msdn.microsoft.com/en-us/library/windows/desktop/dd371582(v=vs.85).aspx
3.? TOUCHINPUT - https://msdn.microsoft.com/en-us/library/windows/desktop/dd317334(v=vs.85).aspx
4.? WM_TOUCH - https://msdn.microsoft.com/en-us/library/windows/desktop/dd317341(v=vs.85).aspx
??? (There is some community comment, but community comments are written by anybody, deprecation is not announced in community comments. For example, the really deprecated function is "GetVersion" - (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724439(v=vs.85).aspx)).

The web page, whose reference you provided is just a forum, is not Win32 API specification or official announcement from Microsoft. So I would not rely on this information.

Additionally approach based on "WM_TOUCH" showed itself in my test environment reliably, WM_TOUCH are generated stably in MS Windows 10 OS, also I was able to successfully port the fix to JDK 8 and verify that it works. Currently I am working on addressing remarks from Sergey and do not plan to refuse from currently developed real basement of the whole fix, which uses WM_TOUCH.

Thank you,
Anton

On 14/09/2017 10:55, Shashidhara Veerabhadraiah wrote:

Hi Anton, I have a question to ask for. I was working on another bug and found that the WM_TOUCH has been deprecated and instead we should be using the WM_POINTER? Here is some info on that: https://stackoverflow.com/questions/23790602/wm-touch-vs-wm-pointer

Typically, the WM_POINTER types can handle following type of pointers:

typedef enum tagPOINTER_INPUT_TYPE { 

? PT_POINTER?? = 0x00000001,

? PT_TOUCH???? = 0x00000002,

? PT_PEN?????? = 0x00000003,

? PT_MOUSE???? = 0x00000004,

? PT_TOUCHPAD? = 0x00000005

} POINTER_INPUT_TYPE;

Hope this is useful for your fix.

Thanks and regards,

Shashi

-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, September 5, 2017 10:45 PM
To: Anton Litvinov HYPERLINK "mailto:anton.litvinov at oracle.com"<anton.litvinov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

Hi, Anton.

The fix looks good.

? - But can you please recheck that is is not necessary to use additional synchronization in showOrHideTouchKeyboard() if a few EDT will be used.

? - I suggest to invert the awt.touchKeyboardAutoShowIsEnabled and use true as default value, we will have more coverage and feedback in this case. This property will be used as a workaround if some bugs will be found.

On 8/30/17 11:51, Anton Litvinov wrote:

> Hello dear reviewers,

> 

> Could anybody please look at this review request?

> 

> Thank you,

> Anton

> 

> On 17/08/2017 13:20, Anton Litvinov wrote:

>> Hello,

>>?

>> Could you please review the following fix for the bug.

>>?

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

>> Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ealitvinov/8166772/jdk10/webrev.00"http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00

>>?

>> The bug is the fact that, when a user touches any Swing or AWT text 

>> component, for example "JTextField", "JTextArea", "TextField", 

>> "TextArea", by means of a touch screen on a host with MS Windows

>> 10/8.1/8 OS, the system touch keyboard is not shown automatically. 

>> Please find a detailed description of the bug, screenshots depicting 

>> the touch keyboard and a compilable test case with Swing/AWT text 

>> components in JBS bug record. Also a summary of the done research of 

>> the issue with a description of identified approaches for its 

>> resolution are reported in my last comment in the bug record.

>>?

>> THE FIX:

>> On a very abstract level the fix functioning can be presented by the 

>> next 3 stages:

>>?

>> Stage 1.

>> The fix adds support of "WM_TOUCH" system window messages to AWT 

>> native peer windows through C++ class "AwtComponent". It "processes"

>> "WM_TOUCH" message and marks "java.awt.event.MouseEvent", which is 

>> created as a result of handling of the further coming 

>> "WM_LBUTTONDOWN", "WM_LBUTTONUP" messages sent by the system in 

>> substitution for this "WM_TOUCH" message, by the new private field 

>> flag "MouseEvent.causedByTouchEvent".

>>?

>> Stage 2.

>> Then on Java level the fix handles "MouseEvent", "FocusEvent" 

>> received only by the instances of "java.awt.TextComponent", 

>> "javax.swing.text.TextComponent" in 

>> "WToolkit.showOrHideTouchKeyboard()" called from 

>> "Component.dispatchEventImpl()" and shows or hides the touch keyboard 

>> on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" events by 

>> calling corresponding native methods of "WToolkit" class.

>>?

>> Stage 3.

>> Showing of the touch keyboard is implemented in C++ class "AwtToolkit" 

>> and is done by launching the system application "TabTip.exe" which 

>> implements the system touch keyboard. This approach is described in 

>> the bug record.

>>?

>> FEATURES OF THE FIX:

>> 1. By default all native and Java parts of the fix do not function at 

>> all - the fix is disabled. To enable the fix the application should 

>> be run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" option. 

>> Handling of this new property is implemented in "sun.awt.SunToolkit" class.

>>?

>> 2. Native parts of the fix functions only on MS Window 8 or later.

>>?

>> 3. The fix implements automatic showing of the touch keyboard for the 

>> following 2 use cases:

>> ??? a.? The user touches the text components using the touch screen.

>> ??? b.? The user does mouse clicks on the text components, while no 

>> any keyboard is attached to the host.

>>?

>> FIX LOGICAL STRUCTURE BY SOURCE CODE:

>> 1. Core of the fix:

>> ??? Native code:? awt_Toolkit.[h/cpp], awt_Component.[h/cpp], 

>> awt_MouseEvent.[h/cpp], awt.h

>> ??? Java:? SunToolkit.java, WToolkit.java, Component.java, 

>> MouseEvent.java, AWTAccessor.java

>>?

>> 2. Changes in all remaining Java files are connected with retaining 

>> of the flag value "MouseEvent.causedByTouchEvent" during creation of 

>> the new instances of "MouseEvent" class based on the original "MouseEvent"

>> instances.

>>?

>> Work of the fix was verified both in the environment with the real 

>> touch screen device and in the environment with the emulated touch 

>> screen.

>>?

>> Thank you,

>> Anton

> 

?

--

Best regards, Sergey.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170915/0c0ff69b/attachment-0001.html>

From pankaj.b.bansal at oracle.com  Fri Sep 15 06:15:15 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 15 Sep 2017 06:15:15 +0000 (UTC)
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
Message-ID: <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>

Hi Sergey,

This test is not failing with JDK 9_181 and JDK10 as methods are deprecated not removed. It is giving lot of warning for using deprecated things, so I made these changes. I think the bug description should be changed to notify that.

Regards,
Pankaj Bansal

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, September 14, 2017 11:30 PM
To: Pankaj Bansal; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

Hi, Pankaj.
Can you please clarify why this test fails on jdk9? This method is deprecated but it was not removed, so it should work.
Probably at some point of jdk9 development it was broken?

On 9/14/17 03:25, Pankaj Bansal wrote:
> Hi All,
> 
> Please review the fix for test program 
> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8081311
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
> 
> Issue:
> 
> The test java/awt/ComponentOrientation/WindowTest.java uses 
> depreciated function ?applyResourceBundle. So the test should be 
> updated to use applyComponentOrientation function.
> 
> Fix:
> 
> Made changes in java/awt/ComponentOrientation/WindowTest.java to use 
> applyComponentOrientation function and did corresponding changes. 
> Along with that, the test is also using java.applet.Applet which is 
> also deprecated, so changed the test to use Frame instead.
> 
> Regards,
> 
> Pankaj Bansal
> 


--
Best regards, Sergey.

From dmitry.markov at oracle.com  Fri Sep 15 11:17:42 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Fri, 15 Sep 2017 12:17:42 +0100
Subject: <AWT Dev> [10] Review Request: 8186559 [macos] the screen
 location is wrong when using AWT/SWT bridge with dual monitors
In-Reply-To: <a571cf64-a561-3b32-216d-4c9a1608e928@oracle.com>
References: <a571cf64-a561-3b32-216d-4c9a1608e928@oracle.com>
Message-ID: <8FE5954E-4D97-43D2-BE39-6A0FAEF7AC09@oracle.com>

Hi Sergey,

The fix looks good to me.

Thanks,
Dmitry 
> On 14 Sep 2017, at 23:46, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello,
> Please review the fix for jdk10.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8186559
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8186559/webrev.00
> 
> When our NSView is embedded in native to the SWT-based NSWindow we incorrectly fetch the location of the NSView. The reason is that we use wrong screen when we flip the location. Currently we use [mainScreen] - which "returns the screen object containing the window with the keyboard focus", but we need the first screen which contains 0,0 coordinates.
> 
> In the fix the utility method is reused which internally uses
> [[NSScreen screens] objectAtIndex:0]
> 
> -- 
> Best regards, Sergey.


From semyon.sadetsky at oracle.com  Fri Sep 15 15:55:17 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 15 Sep 2017 08:55:17 -0700
Subject: <AWT Dev> [10] Review Request: 8186559 [macos] the screen
 location is wrong when using AWT/SWT bridge with dual monitors
In-Reply-To: <a571cf64-a561-3b32-216d-4c9a1608e928@oracle.com>
References: <a571cf64-a561-3b32-216d-4c9a1608e928@oracle.com>
Message-ID: <59BBF7E5.9080104@oracle.com>

Hi Sergey,

what was caused the regression?

--Semyon

On 9/14/2017 3:46 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8186559
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8186559/webrev.00
>
> When our NSView is embedded in native to the SWT-based NSWindow we 
> incorrectly fetch the location of the NSView. The reason is that we 
> use wrong screen when we flip the location. Currently we use 
> [mainScreen] - which "returns the screen object containing the window 
> with the keyboard focus", but we need the first screen which contains 
> 0,0 coordinates.
>
> In the fix the utility method is reused which internally uses
> [[NSScreen screens] objectAtIndex:0]
>


From Sergey.Bylokhov at oracle.com  Fri Sep 15 21:29:57 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Sep 2017 14:29:57 -0700
Subject: <AWT Dev> [10] Review Request: 8186559 [macos] the screen
 location is wrong when using AWT/SWT bridge with dual monitors
In-Reply-To: <59BBF7E5.9080104@oracle.com>
References: <a571cf64-a561-3b32-216d-4c9a1608e928@oracle.com>
 <59BBF7E5.9080104@oracle.com>
Message-ID: <bb76785c-956e-901c-7409-ff027be7ffb5@oracle.com>

It is broken from the moment when it was implemented(I have rechecked on 
8u121 which was mentioned in the report), unlike Apple jdk where it worked.

On 9/15/17 08:55, Semyon Sadetsky wrote:
> Hi Sergey,
> 
> what was caused the regression?
> 
> --Semyon
> 
> On 9/14/2017 3:46 PM, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk10.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8186559
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8186559/webrev.00
>>
>> When our NSView is embedded in native to the SWT-based NSWindow we 
>> incorrectly fetch the location of the NSView. The reason is that we 
>> use wrong screen when we flip the location. Currently we use 
>> [mainScreen] - which "returns the screen object containing the window 
>> with the keyboard focus", but we need the first screen which contains 
>> 0,0 coordinates.
>>
>> In the fix the utility method is reused which internally uses
>> [[NSScreen screens] objectAtIndex:0]
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Sep 15 22:09:48 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Sep 2017 15:09:48 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
Message-ID: <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>


On 9/14/17 23:15, Pankaj Bansal wrote:
> This test is not failing with JDK 9_181 and JDK10 as methods are deprecated not removed. It is giving lot of warning for using deprecated things, so I made these changes. I think the bug description should be changed to notify that.

I am not sure that it is correct to replace one API to another one. This 
test was written as part of i18n support and it checks that our API can 
be configured by the ResourceBundles. The updated test doing the 
different things - it checks that getComponentOrientation will return 
the value which were set by applyComponentOrientation().

Since it was reported that the test failed because of some bug, but 
looks like now it work as expected, this CR can be closed as not 
reproducible. Or you can clean the test but without changing its logic.

> 
> Regards,
> Pankaj Bansal
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Thursday, September 14, 2017 11:30 PM
> To: Pankaj Bansal; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
> 
> Hi, Pankaj.
> Can you please clarify why this test fails on jdk9? This method is deprecated but it was not removed, so it should work.
> Probably at some point of jdk9 development it was broken?
> 
> On 9/14/17 03:25, Pankaj Bansal wrote:
>> Hi All,
>>
>> Please review the fix for test program
>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>
>> Issue:
>>
>> The test java/awt/ComponentOrientation/WindowTest.java uses
>> depreciated function ?applyResourceBundle. So the test should be
>> updated to use applyComponentOrientation function.
>>
>> Fix:
>>
>> Made changes in java/awt/ComponentOrientation/WindowTest.java to use
>> applyComponentOrientation function and did corresponding changes.
>> Along with that, the test is also using java.applet.Applet which is
>> also deprecated, so changed the test to use Frame instead.
>>
>> Regards,
>>
>> Pankaj Bansal
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 15 23:29:11 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 15 Sep 2017 16:29:11 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
Message-ID: <59BC6247.9020408@oracle.com>

The component orientation test suite should use the right API, not the 
deprecated one. This was missed when the new API is created.
So the change is valid from this point with the corresponding comment in 
JIRA.

--Semyon

On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>
> On 9/14/17 23:15, Pankaj Bansal wrote:
>> This test is not failing with JDK 9_181 and JDK10 as methods are 
>> deprecated not removed. It is giving lot of warning for using 
>> deprecated things, so I made these changes. I think the bug 
>> description should be changed to notify that.
>
> I am not sure that it is correct to replace one API to another one. 
> This test was written as part of i18n support and it checks that our 
> API can be configured by the ResourceBundles. The updated test doing 
> the different things - it checks that getComponentOrientation will 
> return the value which were set by applyComponentOrientation().
>
> Since it was reported that the test failed because of some bug, but 
> looks like now it work as expected, this CR can be closed as not 
> reproducible. Or you can clean the test but without changing its logic.
>
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Thursday, September 14, 2017 11:30 PM
>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG] 
>> java/awt/ComponentOrientation/WindowTest.java
>>
>> Hi, Pankaj.
>> Can you please clarify why this test fails on jdk9? This method is 
>> deprecated but it was not removed, so it should work.
>> Probably at some point of jdk9 development it was broken?
>>
>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>> Hi All,
>>>
>>> Please review the fix for test program
>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>
>>> Bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>
>>> Issue:
>>>
>>> The test java/awt/ComponentOrientation/WindowTest.java uses
>>> depreciated function  applyResourceBundle. So the test should be
>>> updated to use applyComponentOrientation function.
>>>
>>> Fix:
>>>
>>> Made changes in java/awt/ComponentOrientation/WindowTest.java to use
>>> applyComponentOrientation function and did corresponding changes.
>>> Along with that, the test is also using java.applet.Applet which is
>>> also deprecated, so changed the test to use Frame instead.
>>>
>>> Regards,
>>>
>>> Pankaj Bansal
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>
>
>


From Sergey.Bylokhov at oracle.com  Fri Sep 15 23:53:32 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Sep 2017 16:53:32 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <59BC6247.9020408@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
 <59BC6247.9020408@oracle.com>
Message-ID: <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>

I guess you missed something, the possibility to configure the 
components via ResourceBudnle or locale is something different that the 
hardcore the orientation in the application. And the fact that this test 
found the bug in jdk9 just show that the test is valid.

On 9/15/17 16:29, Semyon Sadetsky wrote:
> The component orientation test suite should use the right API, not the 
> deprecated one. This was missed when the new API is created.
> So the change is valid from this point with the corresponding comment in 
> JIRA.
> 
> --Semyon
> 
> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>
>> On 9/14/17 23:15, Pankaj Bansal wrote:
>>> This test is not failing with JDK 9_181 and JDK10 as methods are 
>>> deprecated not removed. It is giving lot of warning for using 
>>> deprecated things, so I made these changes. I think the bug 
>>> description should be changed to notify that.
>>
>> I am not sure that it is correct to replace one API to another one. 
>> This test was written as part of i18n support and it checks that our 
>> API can be configured by the ResourceBundles. The updated test doing 
>> the different things - it checks that getComponentOrientation will 
>> return the value which were set by applyComponentOrientation().
>>
>> Since it was reported that the test failed because of some bug, but 
>> looks like now it work as expected, this CR can be closed as not 
>> reproducible. Or you can clean the test but without changing its logic.
>>
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Thursday, September 14, 2017 11:30 PM
>>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG] 
>>> java/awt/ComponentOrientation/WindowTest.java
>>>
>>> Hi, Pankaj.
>>> Can you please clarify why this test fails on jdk9? This method is 
>>> deprecated but it was not removed, so it should work.
>>> Probably at some point of jdk9 development it was broken?
>>>
>>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>>> Hi All,
>>>>
>>>> Please review the fix for test program
>>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>>
>>>> Bug:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>>
>>>> Issue:
>>>>
>>>> The test java/awt/ComponentOrientation/WindowTest.java uses
>>>> depreciated function? applyResourceBundle. So the test should be
>>>> updated to use applyComponentOrientation function.
>>>>
>>>> Fix:
>>>>
>>>> Made changes in java/awt/ComponentOrientation/WindowTest.java to use
>>>> applyComponentOrientation function and did corresponding changes.
>>>> Along with that, the test is also using java.applet.Applet which is
>>>> also deprecated, so changed the test to use Frame instead.
>>>>
>>>> Regards,
>>>>
>>>> Pankaj Bansal
>>>>
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Sat Sep 16 00:04:30 2017
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Fri, 15 Sep 2017 17:04:30 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
 <59BC6247.9020408@oracle.com>
 <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>
Message-ID: <5afacc8a-2236-5955-ed5a-22bd05b378f8@oracle.com>

test/java/awt/ComponentOrientation/WindowTest should test the window 
orientation. So, it should call applyComponentOrientation(). 
ResourceBundle should be tested somewhere else.


On 9/15/17 4:53 PM, Sergey Bylokhov wrote:
> I guess you missed something, the possibility to configure the 
> components via ResourceBudnle or locale is something different that 
> the hardcore the orientation in the application. And the fact that 
> this test found the bug in jdk9 just show that the test is valid.
>
> On 9/15/17 16:29, Semyon Sadetsky wrote:
>> The component orientation test suite should use the right API, not 
>> the deprecated one. This was missed when the new API is created.
>> So the change is valid from this point with the corresponding comment 
>> in JIRA.
>>
>> --Semyon
>>
>> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>>
>>> On 9/14/17 23:15, Pankaj Bansal wrote:
>>>> This test is not failing with JDK 9_181 and JDK10 as methods are 
>>>> deprecated not removed. It is giving lot of warning for using 
>>>> deprecated things, so I made these changes. I think the bug 
>>>> description should be changed to notify that.
>>>
>>> I am not sure that it is correct to replace one API to another one. 
>>> This test was written as part of i18n support and it checks that our 
>>> API can be configured by the ResourceBundles. The updated test doing 
>>> the different things - it checks that getComponentOrientation will 
>>> return the value which were set by applyComponentOrientation().
>>>
>>> Since it was reported that the test failed because of some bug, but 
>>> looks like now it work as expected, this CR can be closed as not 
>>> reproducible. Or you can clean the test but without changing its logic.
>>>
>>>>
>>>> Regards,
>>>> Pankaj Bansal
>>>>
>>>> -----Original Message-----
>>>> From: Sergey Bylokhov
>>>> Sent: Thursday, September 14, 2017 11:30 PM
>>>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>>>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : 
>>>> [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
>>>>
>>>> Hi, Pankaj.
>>>> Can you please clarify why this test fails on jdk9? This method is 
>>>> deprecated but it was not removed, so it should work.
>>>> Probably at some point of jdk9 development it was broken?
>>>>
>>>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review the fix for test program
>>>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>>>
>>>>> Bug:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>>>
>>>>> Issue:
>>>>>
>>>>> The test java/awt/ComponentOrientation/WindowTest.java uses
>>>>> depreciated function  applyResourceBundle. So the test should be
>>>>> updated to use applyComponentOrientation function.
>>>>>
>>>>> Fix:
>>>>>
>>>>> Made changes in java/awt/ComponentOrientation/WindowTest.java to use
>>>>> applyComponentOrientation function and did corresponding changes.
>>>>> Along with that, the test is also using java.applet.Applet which is
>>>>> also deprecated, so changed the test to use Frame instead.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Pankaj Bansal
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Sat Sep 16 00:17:52 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Sep 2017 17:17:52 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <5afacc8a-2236-5955-ed5a-22bd05b378f8@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
 <59BC6247.9020408@oracle.com>
 <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>
 <5afacc8a-2236-5955-ed5a-22bd05b378f8@oracle.com>
Message-ID: <86e0f409-e5d5-666e-a85a-0019e759abdd@oracle.com>

On 9/15/17 17:04, semyon.sadetsky at oracle.com wrote:
> test/java/awt/ComponentOrientation/WindowTest should test the window 
> orientation. So, it should call applyComponentOrientation(). 
> ResourceBundle should be tested somewhere else.

It is fine because it tests the ComponentOrientation class which is 
loaded from the resource bundle and applied to the window.

> 
> 
> On 9/15/17 4:53 PM, Sergey Bylokhov wrote:
>> I guess you missed something, the possibility to configure the 
>> components via ResourceBudnle or locale is something different that 
>> the hardcore the orientation in the application. And the fact that 
>> this test found the bug in jdk9 just show that the test is valid.
>>
>> On 9/15/17 16:29, Semyon Sadetsky wrote:
>>> The component orientation test suite should use the right API, not 
>>> the deprecated one. This was missed when the new API is created.
>>> So the change is valid from this point with the corresponding comment 
>>> in JIRA.
>>>
>>> --Semyon
>>>
>>> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>>>
>>>> On 9/14/17 23:15, Pankaj Bansal wrote:
>>>>> This test is not failing with JDK 9_181 and JDK10 as methods are 
>>>>> deprecated not removed. It is giving lot of warning for using 
>>>>> deprecated things, so I made these changes. I think the bug 
>>>>> description should be changed to notify that.
>>>>
>>>> I am not sure that it is correct to replace one API to another one. 
>>>> This test was written as part of i18n support and it checks that our 
>>>> API can be configured by the ResourceBundles. The updated test doing 
>>>> the different things - it checks that getComponentOrientation will 
>>>> return the value which were set by applyComponentOrientation().
>>>>
>>>> Since it was reported that the test failed because of some bug, but 
>>>> looks like now it work as expected, this CR can be closed as not 
>>>> reproducible. Or you can clean the test but without changing its logic.
>>>>
>>>>>
>>>>> Regards,
>>>>> Pankaj Bansal
>>>>>
>>>>> -----Original Message-----
>>>>> From: Sergey Bylokhov
>>>>> Sent: Thursday, September 14, 2017 11:30 PM
>>>>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>>>>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : 
>>>>> [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
>>>>>
>>>>> Hi, Pankaj.
>>>>> Can you please clarify why this test fails on jdk9? This method is 
>>>>> deprecated but it was not removed, so it should work.
>>>>> Probably at some point of jdk9 development it was broken?
>>>>>
>>>>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review the fix for test program
>>>>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>>>>
>>>>>> Bug:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>>>>
>>>>>> Webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>>>>
>>>>>> Issue:
>>>>>>
>>>>>> The test java/awt/ComponentOrientation/WindowTest.java uses
>>>>>> depreciated function? applyResourceBundle. So the test should be
>>>>>> updated to use applyComponentOrientation function.
>>>>>>
>>>>>> Fix:
>>>>>>
>>>>>> Made changes in java/awt/ComponentOrientation/WindowTest.java to use
>>>>>> applyComponentOrientation function and did corresponding changes.
>>>>>> Along with that, the test is also using java.applet.Applet which is
>>>>>> also deprecated, so changed the test to use Frame instead.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Pankaj Bansal
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Mon Sep 18 15:58:53 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 18 Sep 2017 08:58:53 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
Message-ID: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>

Hi All, Please review this software changes for the enhancement JDK-8178361.

 

Issue: Request was filed to enable the touch event processing for Java client applications.

 

Fix: Windows platform offers 'pointer' implementation thro' which one can tap for the touch inputs as well. A typical 'pointer' function may contain touch, pen, touch pad or mouse inputs. This allows for a uniform input processing though the event source may defer. This fix enables the 'touch' events(via TOUCH pointer) to be passed to the components using the other type of pointer 'mouse'. Essentially there is a conversion put in place to convert a touch event input into a left click mouse event. I think this is the right thing to do considering desktop scenarios to which the typical Java applications that gets exposed to. This is also the same behavior on my touch enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:



Now touch event works as a typical mouse left click as in general. But there is an issue because the icon size of the Java UI is typically small, touching that icon exactly is sometimes difficult. This is handled by an Windows application by having larger icon size or icon view as a standard. Hence I believe this is outside the scope this software update. Any changes to it would be done later as a new bug or an enhancement.

 

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

 

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

 

Thanks and regards,

Shashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170918/e747429b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 21218 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170918/e747429b/image002-0001.jpg>

From semyon.sadetsky at oracle.com  Mon Sep 18 16:53:29 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 18 Sep 2017 09:53:29 -0700
Subject: <AWT Dev> [10] Review Request: 8186559 [macos] the screen
 location is wrong when using AWT/SWT bridge with dual monitors
In-Reply-To: <bb76785c-956e-901c-7409-ff027be7ffb5@oracle.com>
References: <a571cf64-a561-3b32-216d-4c9a1608e928@oracle.com>
 <59BBF7E5.9080104@oracle.com>
 <bb76785c-956e-901c-7409-ff027be7ffb5@oracle.com>
Message-ID: <825df34b-0e03-5dc8-7d88-93746af34f34@oracle.com>

On 09/15/2017 02:29 PM, Sergey Bylokhov wrote:

> It is broken from the moment when it was implemented(I have rechecked 
> on 8u121 which was mentioned in the report), unlike Apple jdk where it 
> worked.
Then probably the regression label need to be removed from the bug?

Should the main screen also fixed in other places, for example, in 
CTrayIcon.m line 137 ?
>
> On 9/15/17 08:55, Semyon Sadetsky wrote:
>> Hi Sergey,
>>
>> what was caused the regression?
>>
>> --Semyon
>>
>> On 9/14/2017 3:46 PM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk10.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8186559
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8186559/webrev.00
>>>
>>> When our NSView is embedded in native to the SWT-based NSWindow we 
>>> incorrectly fetch the location of the NSView. The reason is that we 
>>> use wrong screen when we flip the location. Currently we use 
>>> [mainScreen] - which "returns the screen object containing the 
>>> window with the keyboard focus", but we need the first screen which 
>>> contains 0,0 coordinates.
>>>
>>> In the fix the utility method is reused which internally uses
>>> [[NSScreen screens] objectAtIndex:0]
>>>
>>
>
>


From semyon.sadetsky at oracle.com  Mon Sep 18 17:14:24 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 18 Sep 2017 10:14:24 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <86e0f409-e5d5-666e-a85a-0019e759abdd@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
 <59BC6247.9020408@oracle.com>
 <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>
 <5afacc8a-2236-5955-ed5a-22bd05b378f8@oracle.com>
 <86e0f409-e5d5-666e-a85a-0019e759abdd@oracle.com>
Message-ID: <fba0ab2f-5380-db32-6e13-5751d1ba37b1@oracle.com>

On 09/15/2017 05:17 PM, Sergey Bylokhov wrote:

> On 9/15/17 17:04, semyon.sadetsky at oracle.com wrote:
>> test/java/awt/ComponentOrientation/WindowTest should test the window 
>> orientation. So, it should call applyComponentOrientation(). 
>> ResourceBundle should be tested somewhere else.
>
> It is fine because it tests the ComponentOrientation class which is 
> loaded from the resource bundle and applied to the window.
I would agree with you if the resource bundle at least contained a value 
for the component orientation but it sets some specific locale codes. 
And java's locale functionality is not a subject of the client-libs, it 
is an another module. Also, as it was already pointed out, the method 
was deprecated long time ago.
>
>>
>>
>> On 9/15/17 4:53 PM, Sergey Bylokhov wrote:
>>> I guess you missed something, the possibility to configure the 
>>> components via ResourceBudnle or locale is something different that 
>>> the hardcore the orientation in the application. And the fact that 
>>> this test found the bug in jdk9 just show that the test is valid.
>>>
>>> On 9/15/17 16:29, Semyon Sadetsky wrote:
>>>> The component orientation test suite should use the right API, not 
>>>> the deprecated one. This was missed when the new API is created.
>>>> So the change is valid from this point with the corresponding 
>>>> comment in JIRA.
>>>>
>>>> --Semyon
>>>>
>>>> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>>>>
>>>>> On 9/14/17 23:15, Pankaj Bansal wrote:
>>>>>> This test is not failing with JDK 9_181 and JDK10 as methods are 
>>>>>> deprecated not removed. It is giving lot of warning for using 
>>>>>> deprecated things, so I made these changes. I think the bug 
>>>>>> description should be changed to notify that.
>>>>>
>>>>> I am not sure that it is correct to replace one API to another 
>>>>> one. This test was written as part of i18n support and it checks 
>>>>> that our API can be configured by the ResourceBundles. The updated 
>>>>> test doing the different things - it checks that 
>>>>> getComponentOrientation will return the value which were set by 
>>>>> applyComponentOrientation().
>>>>>
>>>>> Since it was reported that the test failed because of some bug, 
>>>>> but looks like now it work as expected, this CR can be closed as 
>>>>> not reproducible. Or you can clean the test but without changing 
>>>>> its logic.
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Pankaj Bansal
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Sergey Bylokhov
>>>>>> Sent: Thursday, September 14, 2017 11:30 PM
>>>>>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>>>>>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : 
>>>>>> [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
>>>>>>
>>>>>> Hi, Pankaj.
>>>>>> Can you please clarify why this test fails on jdk9? This method 
>>>>>> is deprecated but it was not removed, so it should work.
>>>>>> Probably at some point of jdk9 development it was broken?
>>>>>>
>>>>>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review the fix for test program
>>>>>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>>>>>
>>>>>>> Bug:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>>>>>
>>>>>>> Webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>>>>>
>>>>>>> Issue:
>>>>>>>
>>>>>>> The test java/awt/ComponentOrientation/WindowTest.java uses
>>>>>>> depreciated function  applyResourceBundle. So the test should be
>>>>>>> updated to use applyComponentOrientation function.
>>>>>>>
>>>>>>> Fix:
>>>>>>>
>>>>>>> Made changes in java/awt/ComponentOrientation/WindowTest.java to 
>>>>>>> use
>>>>>>> applyComponentOrientation function and did corresponding changes.
>>>>>>> Along with that, the test is also using java.applet.Applet which is
>>>>>>> also deprecated, so changed the test to use Frame instead.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Pankaj Bansal
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Best regards, Sergey.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Mon Sep 18 18:04:31 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Sep 2017 11:04:31 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <fba0ab2f-5380-db32-6e13-5751d1ba37b1@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
 <59BC6247.9020408@oracle.com>
 <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>
 <5afacc8a-2236-5955-ed5a-22bd05b378f8@oracle.com>
 <86e0f409-e5d5-666e-a85a-0019e759abdd@oracle.com>
 <fba0ab2f-5380-db32-6e13-5751d1ba37b1@oracle.com>
Message-ID: <9bd32de3-af72-a911-2e70-029af10a099f@oracle.com>

On 9/18/17 10:14, Semyon Sadetsky wrote:
>> It is fine because it tests the ComponentOrientation class which is 
>> loaded from the resource bundle and applied to the window.
> I would agree with you if the resource bundle at least contained a value 
> for the component orientation but it sets some specific locale codes. 
> And java's locale functionality is not a subject of the client-libs, it 
> is an another module. Also, as it was already pointed out, the method 
> was deprecated long time ago.

Where did you check these bundles? Because resource bundles for this 
test contains the all variations of orientation 
property(UNKNOWN/LEFT_TO_RIGHT/RIGHT_TO_LEFT/none).

>>
>>>
>>>
>>> On 9/15/17 4:53 PM, Sergey Bylokhov wrote:
>>>> I guess you missed something, the possibility to configure the 
>>>> components via ResourceBudnle or locale is something different that 
>>>> the hardcore the orientation in the application. And the fact that 
>>>> this test found the bug in jdk9 just show that the test is valid.
>>>>
>>>> On 9/15/17 16:29, Semyon Sadetsky wrote:
>>>>> The component orientation test suite should use the right API, not 
>>>>> the deprecated one. This was missed when the new API is created.
>>>>> So the change is valid from this point with the corresponding 
>>>>> comment in JIRA.
>>>>>
>>>>> --Semyon
>>>>>
>>>>> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>>>>>
>>>>>> On 9/14/17 23:15, Pankaj Bansal wrote:
>>>>>>> This test is not failing with JDK 9_181 and JDK10 as methods are 
>>>>>>> deprecated not removed. It is giving lot of warning for using 
>>>>>>> deprecated things, so I made these changes. I think the bug 
>>>>>>> description should be changed to notify that.
>>>>>>
>>>>>> I am not sure that it is correct to replace one API to another 
>>>>>> one. This test was written as part of i18n support and it checks 
>>>>>> that our API can be configured by the ResourceBundles. The updated 
>>>>>> test doing the different things - it checks that 
>>>>>> getComponentOrientation will return the value which were set by 
>>>>>> applyComponentOrientation().
>>>>>>
>>>>>> Since it was reported that the test failed because of some bug, 
>>>>>> but looks like now it work as expected, this CR can be closed as 
>>>>>> not reproducible. Or you can clean the test but without changing 
>>>>>> its logic.
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Pankaj Bansal
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Sergey Bylokhov
>>>>>>> Sent: Thursday, September 14, 2017 11:30 PM
>>>>>>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>>>>>>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : 
>>>>>>> [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
>>>>>>>
>>>>>>> Hi, Pankaj.
>>>>>>> Can you please clarify why this test fails on jdk9? This method 
>>>>>>> is deprecated but it was not removed, so it should work.
>>>>>>> Probably at some point of jdk9 development it was broken?
>>>>>>>
>>>>>>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review the fix for test program
>>>>>>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>>>>>>
>>>>>>>> Issue:
>>>>>>>>
>>>>>>>> The test java/awt/ComponentOrientation/WindowTest.java uses
>>>>>>>> depreciated function? applyResourceBundle. So the test should be
>>>>>>>> updated to use applyComponentOrientation function.
>>>>>>>>
>>>>>>>> Fix:
>>>>>>>>
>>>>>>>> Made changes in java/awt/ComponentOrientation/WindowTest.java to 
>>>>>>>> use
>>>>>>>> applyComponentOrientation function and did corresponding changes.
>>>>>>>> Along with that, the test is also using java.applet.Applet which is
>>>>>>>> also deprecated, so changed the test to use Frame instead.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Pankaj Bansal
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Best regards, Sergey.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep 18 18:27:50 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Sep 2017 11:27:50 -0700
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
In-Reply-To: <dc2d8bd8-9c61-ab13-1405-1338920f9fca@oracle.com>
References: <bc568398-c4e4-41de-be9a-b2f3c57832fb@default>
 <dc2d8bd8-9c61-ab13-1405-1338920f9fca@oracle.com>
Message-ID: <a19185ff-acca-a2ed-a69d-ab0fe7fba753@oracle.com>

Hi, Prasanta.
  - In this version it is unclear what is a purpose of the 
"fxCheckSequenceThread.start()". This code will start the thread and 
will continue execution, it will not wait when the thread will stop.
  - The DefaultKeyboardFocusManager also should check for 
"javafx.embed.singleThread"


On 9/13/17 03:11, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> I have modified the fix to not use SecondaryLoop and not to create one 
> thread per dispatch
> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/
> 
> Regards
> Prasanta
> On 8/30/2017 11:41 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> Can you please provide some description on how the SecondaryLoop will 
>> work when it will run on Appkit thread? Is it possible to get a 
>> deadlock here, since appkit will be blocked?
>>
>>> sequence, ie if the event is not first in sequence, then it will made
>>> to
>>> wait till it is the first event or till it is disposed.
>> Note that the new code (unlike lines 139-150) also waits 1 second, so 
>> we can get a situation when only one event will be dispatched per 
>> second, which is not we want to do.
>> I am not sure how often we create SequencedEvent but creating one 
>> thread per dispatch look inefficient.
>>
>>
>>> Modified webrev
>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/
>>>
>>> Regards
>>> Prasanta
>>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>>
>>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
>>>>> Now, since here FX App thread itself is the dispatch thread, we can
>>>>> be sure the events are dispatched in sequence and dispose is
>>> checked
>>>>> below after EDT.
>>>> Why we can sure about this? If the SequencedEvents were created in
>>> one
>>>> order but dispatch() for each were called in other order then the
>>>> sequenced will not be preserved?
>>>>
>>>>> I have tested with couple of singleThread testcase without any
>>> issue.
>>>>> Regards
>>>>> Prasanta
>>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
>>>>>> Hi, Prasanta, Kevin.
>>>>>>
>>>>>> I have two notes.
>>>>>> ?? - Does this option is really supported? If it is supported we
>>>>>> should evaluate all usage of EventDispatchThread because in this
>>>>>> mode the dispatch thread is not EDT. For example I am not sure
>>> that
>>>>>> we can skip the code which expects EventDispatchThread.
>>>>>> ?? - We have the similar pattern: "EventQueue.isDispatchThread() ->
>>>>>> cast(EventDispatchThread)" in some other places like in
>>>>>> DefaultKeyboardFocusManager.
>>>>>>
>>>>>> -----prasanta.sadhukhan at oracle.com? wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review this fix
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>>>>>>> for an fx issue
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>>>>>>
>>>>>>> More info in JBS.
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep 18 20:12:58 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Sep 2017 13:12:58 -0700
Subject: <AWT Dev> [10] Review Request: 8178274
 Java_sun_lwawt_macosx_NSEvent_nsToJavaKeyInfo() overreads jchar variable
Message-ID: <463fce8b-dfb7-8e74-9476-3a100409c232@oracle.com>

Hello,
Please review the fix for jdk10.

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

We pass jchar to the SetIntArrayRegion() but jint is expected, and 
SetIntArrayRegion() over-reads memory allocated on stack for 
'testDeadChar' variable.
In the fix the size of the testDeadChar was changed to the jint.

The fix was contributed by the Artem Smotrakov.


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep 18 22:04:17 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Sep 2017 15:04:17 -0700
Subject: <AWT Dev> [10] Review Request: 8186559 [macos] the screen
 location is wrong when using AWT/SWT bridge with dual monitors
In-Reply-To: <825df34b-0e03-5dc8-7d88-93746af34f34@oracle.com>
References: <a571cf64-a561-3b32-216d-4c9a1608e928@oracle.com>
 <59BBF7E5.9080104@oracle.com>
 <bb76785c-956e-901c-7409-ff027be7ffb5@oracle.com>
 <825df34b-0e03-5dc8-7d88-93746af34f34@oracle.com>
Message-ID: <e03bf1c0-197f-d4df-2d20-9b0f37390382@oracle.com>

On 9/18/17 09:53, Semyon Sadetsky wrote:
> On 09/15/2017 02:29 PM, Sergey Bylokhov wrote:
> 
>> It is broken from the moment when it was implemented(I have rechecked 
>> on 8u121 which was mentioned in the report), unlike Apple jdk where it 
>> worked.
> Then probably the regression label need to be removed from the bug?

The labels is removed.

> 
> Should the main screen also fixed in other places, for example, in 
> CTrayIcon.m line 137 ?

Yes, it can be changed as well:
http://cr.openjdk.java.net/~serb/8186559/webrev.01

but unfortunately it will not work properly even after this,
the new issues created https://bugs.openjdk.java.net/browse/JDK-8187639

The last usage in getTopmostWindowUnderMouseIDImpl seems correct.

>>
>> On 9/15/17 08:55, Semyon Sadetsky wrote:
>>> Hi Sergey,
>>>
>>> what was caused the regression?
>>>
>>> --Semyon
>>>
>>> On 9/14/2017 3:46 PM, Sergey Bylokhov wrote:
>>>> Hello,
>>>> Please review the fix for jdk10.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8186559
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8186559/webrev.00
>>>>
>>>> When our NSView is embedded in native to the SWT-based NSWindow we 
>>>> incorrectly fetch the location of the NSView. The reason is that we 
>>>> use wrong screen when we flip the location. Currently we use 
>>>> [mainScreen] - which "returns the screen object containing the 
>>>> window with the keyboard focus", but we need the first screen which 
>>>> contains 0,0 coordinates.
>>>>
>>>> In the fix the utility method is reused which internally uses
>>>> [[NSScreen screens] objectAtIndex:0]
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep 18 22:09:29 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Sep 2017 15:09:29 -0700
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
Message-ID: <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>

Hi, Shashi.
Why the bug is JFileChooser specific?
Does it means that it works for other elements(buttons/lists/menu/etc)?

On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
> Hi All, Please review this software changes for the /_enhancement_/ 
> JDK-8178361.
> 
> Issue: Request was filed to enable the touch event processing for Java 
> client applications.
> 
> Fix: Windows platform offers ?pointer? implementation thro? which one 
> can tap for the touch inputs as well. A typical ?pointer? function may 
> contain touch, pen, touch pad or mouse inputs. This allows for a uniform 
> input processing though the event source may defer. This fix enables the 
> ?touch? events(via TOUCH pointer) to be passed to the components using 
> the other type of pointer ?mouse?. Essentially there is a conversion put 
> in place to convert a touch event input into a left click mouse event. I 
> think this is the right thing to do considering desktop scenarios to 
> which the typical Java applications that gets exposed to. This is also 
> the same behavior on my touch enabled windows 10 laptop as well. Please 
> let me know if a different behavior is expected. Below is the output:
> 
> Now touch event works as a typical mouse left click as in general. But 
> there is an issue because the icon size of the Java UI is typically 
> small, touching that icon exactly is sometimes difficult. This is 
> handled by an Windows application by having larger icon size or icon 
> view as a standard. Hence I believe this is outside the scope this 
> software update. Any changes to it would be done later as a new bug or 
> an enhancement.
> 
> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361
> 
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
> 
> Thanks and regards,
> 
> Shashi
> 


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Tue Sep 19 03:35:12 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 18 Sep 2017 20:35:12 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
Message-ID: <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>

Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, September 19, 2017 3:39 AM
To: shashidhara.veerabhadraiah at oracle.com >> Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

Hi, Shashi.
Why the bug is JFileChooser specific?
Does it means that it works for other elements(buttons/lists/menu/etc)?

On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
> Hi All, Please review this software changes for the /_enhancement_/ 
> JDK-8178361.
> 
> Issue: Request was filed to enable the touch event processing for Java 
> client applications.
> 
> Fix: Windows platform offers 'pointer' implementation thro' which one 
> can tap for the touch inputs as well. A typical 'pointer' function may 
> contain touch, pen, touch pad or mouse inputs. This allows for a 
> uniform input processing though the event source may defer. This fix 
> enables the 'touch' events(via TOUCH pointer) to be passed to the 
> components using the other type of pointer 'mouse'. Essentially there 
> is a conversion put in place to convert a touch event input into a 
> left click mouse event. I think this is the right thing to do 
> considering desktop scenarios to which the typical Java applications 
> that gets exposed to. This is also the same behavior on my touch 
> enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
> 
> Now touch event works as a typical mouse left click as in general. But 
> there is an issue because the icon size of the Java UI is typically 
> small, touching that icon exactly is sometimes difficult. This is 
> handled by an Windows application by having larger icon size or icon 
> view as a standard. Hence I believe this is outside the scope this 
> software update. Any changes to it would be done later as a new bug or 
> an enhancement.
> 
> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361
> 
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
> 
> Thanks and regards,
> 
> Shashi
> 


--
Best regards, Sergey.

From pankaj.b.bansal at oracle.com  Tue Sep 19 06:40:01 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 18 Sep 2017 23:40:01 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <9bd32de3-af72-a911-2e70-029af10a099f@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
 <59BC6247.9020408@oracle.com>
 <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>
 <5afacc8a-2236-5955-ed5a-22bd05b378f8@oracle.com>
 <86e0f409-e5d5-666e-a85a-0019e759abdd@oracle.com>
 <fba0ab2f-5380-db32-6e13-5751d1ba37b1@oracle.com>
 <9bd32de3-af72-a911-2e70-029af10a099f@oracle.com>
Message-ID: <dde1665b-59e4-4e98-9381-0e31fbc03c91@default>

Hi Sergey,

In my opinion, the resource bundle loading is tested in java/awt/ComponentOrientation/BasicTest.java file. So WindowTest must be testing the component orientation functionality and we should be using the latest API for the same.

Regards,
Pankaj Bansal

-----Original Message-----
From: Sergey Bylokhov 
Sent: Monday, September 18, 2017 11:35 PM
To: Semyon Sadetsky; Pankaj Bansal; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

On 9/18/17 10:14, Semyon Sadetsky wrote:
>> It is fine because it tests the ComponentOrientation class which is 
>> loaded from the resource bundle and applied to the window.
> I would agree with you if the resource bundle at least contained a 
> value for the component orientation but it sets some specific locale codes.
> And java's locale functionality is not a subject of the client-libs, 
> it is an another module. Also, as it was already pointed out, the 
> method was deprecated long time ago.

Where did you check these bundles? Because resource bundles for this test contains the all variations of orientation property(UNKNOWN/LEFT_TO_RIGHT/RIGHT_TO_LEFT/none).

>>
>>>
>>>
>>> On 9/15/17 4:53 PM, Sergey Bylokhov wrote:
>>>> I guess you missed something, the possibility to configure the 
>>>> components via ResourceBudnle or locale is something different that 
>>>> the hardcore the orientation in the application. And the fact that 
>>>> this test found the bug in jdk9 just show that the test is valid.
>>>>
>>>> On 9/15/17 16:29, Semyon Sadetsky wrote:
>>>>> The component orientation test suite should use the right API, not 
>>>>> the deprecated one. This was missed when the new API is created.
>>>>> So the change is valid from this point with the corresponding 
>>>>> comment in JIRA.
>>>>>
>>>>> --Semyon
>>>>>
>>>>> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>>>>>
>>>>>> On 9/14/17 23:15, Pankaj Bansal wrote:
>>>>>>> This test is not failing with JDK 9_181 and JDK10 as methods are 
>>>>>>> deprecated not removed. It is giving lot of warning for using 
>>>>>>> deprecated things, so I made these changes. I think the bug 
>>>>>>> description should be changed to notify that.
>>>>>>
>>>>>> I am not sure that it is correct to replace one API to another 
>>>>>> one. This test was written as part of i18n support and it checks 
>>>>>> that our API can be configured by the ResourceBundles. The 
>>>>>> updated test doing the different things - it checks that 
>>>>>> getComponentOrientation will return the value which were set by 
>>>>>> applyComponentOrientation().
>>>>>>
>>>>>> Since it was reported that the test failed because of some bug, 
>>>>>> but looks like now it work as expected, this CR can be closed as 
>>>>>> not reproducible. Or you can clean the test but without changing 
>>>>>> its logic.
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Pankaj Bansal
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Sergey Bylokhov
>>>>>>> Sent: Thursday, September 14, 2017 11:30 PM
>>>>>>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>>>>>>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : 
>>>>>>> [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
>>>>>>>
>>>>>>> Hi, Pankaj.
>>>>>>> Can you please clarify why this test fails on jdk9? This method 
>>>>>>> is deprecated but it was not removed, so it should work.
>>>>>>> Probably at some point of jdk9 development it was broken?
>>>>>>>
>>>>>>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review the fix for test program 
>>>>>>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>>>>>>
>>>>>>>> Issue:
>>>>>>>>
>>>>>>>> The test java/awt/ComponentOrientation/WindowTest.java uses 
>>>>>>>> depreciated function? applyResourceBundle. So the test should 
>>>>>>>> be updated to use applyComponentOrientation function.
>>>>>>>>
>>>>>>>> Fix:
>>>>>>>>
>>>>>>>> Made changes in java/awt/ComponentOrientation/WindowTest.java 
>>>>>>>> to use applyComponentOrientation function and did corresponding 
>>>>>>>> changes.
>>>>>>>> Along with that, the test is also using java.applet.Applet 
>>>>>>>> which is also deprecated, so changed the test to use Frame instead.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Pankaj Bansal
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards, Sergey.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


--
Best regards, Sergey.

From anton.litvinov at oracle.com  Tue Sep 19 14:54:58 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Tue, 19 Sep 2017 15:54:58 +0100
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
Message-ID: <9533ba8b-0660-236d-b580-800672f4736e@oracle.com>

Good day Shashidhara,

You took parts of my fix for the bug 
(https://bugs.openjdk.java.net/browse/JDK-8166772) which is being 
reviewed on this e-mail alias since 17/08/2017 and which is almost 
approved by one reviewer 
(http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/012999.html). 
You did not inform me about intention to use the parts of my fix anyhow 
and you are trying to present these copied parts of my fix as yours. 
This is not acceptable and looks as a plagiarism.

You fully copied the code organization from my fix - your fix changes 
the same files in the identical places, in all 4 files there is the code 
which is identical to the code from the same files in my fix, you even 
did not change the text of my source code comments. Though you are 
trying to address a different issue and use a different API, your fix 
edits the same files in the same places what makes our 2 fixes overlap 
each other and conflict with each other. And you knew about these 
compatibility problems, because last week you entered the review of my 
fix and after that you sent your review request on 19/09/2017.

I do not want to remove my parts of the fix from my fix and test and 
review my fix again just to be able to apply my fix over yours 
containing my code, if yours is approved first and pushed first. My 
review request was filed more than one month before your review request.

How to quit this situation?

In order to resolve this situation, I suggest you:
1)  To link your bug to my bug JDK-8166772 and to mark your as "is 
blocked by" my bug.
2)  To agree to remove my parts of the fix from your fix, wait until I 
provide the final version of my fix with 2 micro changes to the 
reviewers, what I will do within next 2 days, and we will sort out with 
you offline, how to recreate your new version of the fix.
Currently I suppose that I will give you the changeset with my approved 
fix, you will clone two instances of "jdk10/client", in one you will "hg 
import" my changeset, then apply your changes and create a "webrev" for 
your fix, in the second instance of "jdk10/client" you will apply my fix 
just using "patch" and then apply your patch from "webrev", we will 
discuss these details offline.

If you accept this way of resolution, I agree to forget about the 
earlier described issue with your fix.

What do you think about my suggestion?

Thank you,
Anton

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 19, 2017 3:39 AM
> To: shashidhara.veerabhadraiah at oracle.com >> Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface
>
> Hi, Shashi.
> Why the bug is JFileChooser specific?
> Does it means that it works for other elements(buttons/lists/menu/etc)?
>
> On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review this software changes for the /_enhancement_/
>> JDK-8178361.
>>
>> Issue: Request was filed to enable the touch event processing for Java
>> client applications.
>>
>> Fix: Windows platform offers 'pointer' implementation thro' which one
>> can tap for the touch inputs as well. A typical 'pointer' function may
>> contain touch, pen, touch pad or mouse inputs. This allows for a
>> uniform input processing though the event source may defer. This fix
>> enables the 'touch' events(via TOUCH pointer) to be passed to the
>> components using the other type of pointer 'mouse'. Essentially there
>> is a conversion put in place to convert a touch event input into a
>> left click mouse event. I think this is the right thing to do
>> considering desktop scenarios to which the typical Java applications
>> that gets exposed to. This is also the same behavior on my touch
>> enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
>>
>> Now touch event works as a typical mouse left click as in general. But
>> there is an issue because the icon size of the Java UI is typically
>> small, touching that icon exactly is sometimes difficult. This is
>> handled by an Windows application by having larger icon size or icon
>> view as a standard. Hence I believe this is outside the scope this
>> software update. Any changes to it would be done later as a new bug or
>> an enhancement.
>>
>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361
>>
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
>>
>> Thanks and regards,
>>
>> Shashi
>>
>
> --
> Best regards, Sergey.


From semyon.sadetsky at oracle.com  Tue Sep 19 15:02:22 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Sep 2017 08:02:22 -0700
Subject: <AWT Dev> [10] Review Request: 8178274
 Java_sun_lwawt_macosx_NSEvent_nsToJavaKeyInfo() overreads jchar variable
In-Reply-To: <463fce8b-dfb7-8e74-9476-3a100409c232@oracle.com>
References: <463fce8b-dfb7-8e74-9476-3a100409c232@oracle.com>
Message-ID: <47f000a2-a798-3177-744c-44a11d48e1a3@oracle.com>

+1

Please, add the corresponding noreg label to the bug.

--Semyon


On 09/18/2017 01:12 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178274
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8178274/webrev.00
>
> We pass jchar to the SetIntArrayRegion() but jint is expected, and 
> SetIntArrayRegion() over-reads memory allocated on stack for 
> 'testDeadChar' variable.
> In the fix the size of the testDeadChar was changed to the jint.
>
> The fix was contributed by the Artem Smotrakov.
>
>


From semyon.sadetsky at oracle.com  Tue Sep 19 15:10:28 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Sep 2017 08:10:28 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <9bd32de3-af72-a911-2e70-029af10a099f@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
 <59BC6247.9020408@oracle.com>
 <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>
 <5afacc8a-2236-5955-ed5a-22bd05b378f8@oracle.com>
 <86e0f409-e5d5-666e-a85a-0019e759abdd@oracle.com>
 <fba0ab2f-5380-db32-6e13-5751d1ba37b1@oracle.com>
 <9bd32de3-af72-a911-2e70-029af10a099f@oracle.com>
Message-ID: <18341159-32d7-ebb4-05da-a04224a4d2e7@oracle.com>

On 09/18/2017 11:04 AM, Sergey Bylokhov wrote:

> On 9/18/17 10:14, Semyon Sadetsky wrote:
>>> It is fine because it tests the ComponentOrientation class which is 
>>> loaded from the resource bundle and applied to the window.
>> I would agree with you if the resource bundle at least contained a 
>> value for the component orientation but it sets some specific locale 
>> codes. And java's locale functionality is not a subject of the 
>> client-libs, it is an another module. Also, as it was already pointed 
>> out, the method was deprecated long time ago.
>
> Where did you check these bundles? Because resource bundles for this 
> test contains the all variations of orientation 
> property(UNKNOWN/LEFT_TO_RIGHT/RIGHT_TO_LEFT/none).
OK. I missed those bundle classes with the orientation properties. I 
think the test may either be left as it is, or moved to the i18n suite 
with adding a test to ComponentOrientation suite that tests 
applyComponentOrientation() directly.
>
>>>
>>>>
>>>>
>>>> On 9/15/17 4:53 PM, Sergey Bylokhov wrote:
>>>>> I guess you missed something, the possibility to configure the 
>>>>> components via ResourceBudnle or locale is something different 
>>>>> that the hardcore the orientation in the application. And the fact 
>>>>> that this test found the bug in jdk9 just show that the test is 
>>>>> valid.
>>>>>
>>>>> On 9/15/17 16:29, Semyon Sadetsky wrote:
>>>>>> The component orientation test suite should use the right API, 
>>>>>> not the deprecated one. This was missed when the new API is created.
>>>>>> So the change is valid from this point with the corresponding 
>>>>>> comment in JIRA.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>>>>>>
>>>>>>> On 9/14/17 23:15, Pankaj Bansal wrote:
>>>>>>>> This test is not failing with JDK 9_181 and JDK10 as methods 
>>>>>>>> are deprecated not removed. It is giving lot of warning for 
>>>>>>>> using deprecated things, so I made these changes. I think the 
>>>>>>>> bug description should be changed to notify that.
>>>>>>>
>>>>>>> I am not sure that it is correct to replace one API to another 
>>>>>>> one. This test was written as part of i18n support and it checks 
>>>>>>> that our API can be configured by the ResourceBundles. The 
>>>>>>> updated test doing the different things - it checks that 
>>>>>>> getComponentOrientation will return the value which were set by 
>>>>>>> applyComponentOrientation().
>>>>>>>
>>>>>>> Since it was reported that the test failed because of some bug, 
>>>>>>> but looks like now it work as expected, this CR can be closed as 
>>>>>>> not reproducible. Or you can clean the test but without changing 
>>>>>>> its logic.
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Pankaj Bansal
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Sergey Bylokhov
>>>>>>>> Sent: Thursday, September 14, 2017 11:30 PM
>>>>>>>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>>>>>>>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : 
>>>>>>>> [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
>>>>>>>>
>>>>>>>> Hi, Pankaj.
>>>>>>>> Can you please clarify why this test fails on jdk9? This method 
>>>>>>>> is deprecated but it was not removed, so it should work.
>>>>>>>> Probably at some point of jdk9 development it was broken?
>>>>>>>>
>>>>>>>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review the fix for test program
>>>>>>>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>>>>>>>
>>>>>>>>> Bug:
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>>>>>>>
>>>>>>>>> Webrev:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>>>>>>>
>>>>>>>>> Issue:
>>>>>>>>>
>>>>>>>>> The test java/awt/ComponentOrientation/WindowTest.java uses
>>>>>>>>> depreciated function  applyResourceBundle. So the test should be
>>>>>>>>> updated to use applyComponentOrientation function.
>>>>>>>>>
>>>>>>>>> Fix:
>>>>>>>>>
>>>>>>>>> Made changes in java/awt/ComponentOrientation/WindowTest.java 
>>>>>>>>> to use
>>>>>>>>> applyComponentOrientation function and did corresponding changes.
>>>>>>>>> Along with that, the test is also using java.applet.Applet 
>>>>>>>>> which is
>>>>>>>>> also deprecated, so changed the test to use Frame instead.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Pankaj Bansal
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Best regards, Sergey.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From shashidhara.veerabhadraiah at oracle.com  Wed Sep 20 04:11:50 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 19 Sep 2017 21:11:50 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <9533ba8b-0660-236d-b580-800672f4736e@oracle.com>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
 <9533ba8b-0660-236d-b580-800672f4736e@oracle.com>
Message-ID: <890cb187-c24a-4ac3-8d9c-6e9030e100d4@default>

Anton, I do not agree to your comments.

I am implementing a different message to enable the touch functionality compared to your software changes. There is only a copy of the win8orlater variable because this is required for my api's too!! Rest all those changes have to be laid in a similar way as opposed to other kinds of windows messages that are handled in the system. I say that you have copied the organization from other software changes what other authors have made long time back. Is'nt it? We both have to use the similar code organization because of the existing laid out code organization inevitably. Our api calls are also dependent on the same library as well and we both need to import from the same dll.
To illustrate my argument, there are other dll import functions that are present in the file awt_Toolkit module for eg., splashscreen.dll importing ' SplashClose' at line no. 2807 to 2812. So this is the reason you have put the import calls in the same file as well after seeing a similar change and I will have to do the same thing as well because of the existing code organization. And obviously I have to change the awt_component module in order to insert the new messages(in this case WM_POINTER message and not the WM_TOUCH as opposed to your's). They are completely different implementations and there is no copy of your code as such.

So if you see in a way everybody has copied the code organization which some author has put it a long time ago(That's the framework implication). I agree to the copy of the win8orlater variable and the corresponding macro IS_WIN8. But again this macro is available in the internet too. I expect once either of our code gets checked in and while doing the other code check in would resolve that issue if they are same. That's the reason I copied as is so that check in would not cause further problems. Even if it causes who ever checks in later would need to resolve it which I think would be me since you have already started the review some time back. Copying here make sense because we both would end up creating different variables for the same functionality which I did not wanted to since I knew that you are also doing a similar change.

If you do not wish to share the same variable , alternatively I can very well create my own namespace for my functionality and hide that variable(isWin8OrLater). Is this approach is fine?

Thanks and regards,
Shashi

-----Original Message-----
From: Anton Litvinov 
Sent: Tuesday, September 19, 2017 8:25 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Sergey Bylokhov <sergey.bylokhov at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

Good day Shashidhara,

You took parts of my fix for the bug
(https://bugs.openjdk.java.net/browse/JDK-8166772) which is being reviewed on this e-mail alias since 17/08/2017 and which is almost approved by one reviewer (http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/012999.html). 
You did not inform me about intention to use the parts of my fix anyhow and you are trying to present these copied parts of my fix as yours. 
This is not acceptable and looks as a plagiarism.

You fully copied the code organization from my fix - your fix changes the same files in the identical places, in all 4 files there is the code which is identical to the code from the same files in my fix, you even did not change the text of my source code comments. Though you are trying to address a different issue and use a different API, your fix edits the same files in the same places what makes our 2 fixes overlap each other and conflict with each other. And you knew about these compatibility problems, because last week you entered the review of my fix and after that you sent your review request on 19/09/2017.

I do not want to remove my parts of the fix from my fix and test and review my fix again just to be able to apply my fix over yours containing my code, if yours is approved first and pushed first. My review request was filed more than one month before your review request.

How to quit this situation?

In order to resolve this situation, I suggest you:
1)  To link your bug to my bug JDK-8166772 and to mark your as "is blocked by" my bug.
2)  To agree to remove my parts of the fix from your fix, wait until I provide the final version of my fix with 2 micro changes to the reviewers, what I will do within next 2 days, and we will sort out with you offline, how to recreate your new version of the fix.
Currently I suppose that I will give you the changeset with my approved fix, you will clone two instances of "jdk10/client", in one you will "hg import" my changeset, then apply your changes and create a "webrev" for your fix, in the second instance of "jdk10/client" you will apply my fix just using "patch" and then apply your patch from "webrev", we will discuss these details offline.

If you accept this way of resolution, I agree to forget about the earlier described issue with your fix.

What do you think about my suggestion?

Thank you,
Anton

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 19, 2017 3:39 AM
> To:  HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com >> Shashidhara 
> Veerabhadraiah < HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com>
> Cc:  HYPERLINK "mailto:awt-dev at openjdk.java.net" awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow 
> to open folders with a double tap when using the touch screen 
> interface
>
> Hi, Shashi.
> Why the bug is JFileChooser specific?
> Does it means that it works for other elements(buttons/lists/menu/etc)?
>
> On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review this software changes for the /_enhancement_/ 
>> JDK-8178361.
>>
>> Issue: Request was filed to enable the touch event processing for 
>> Java client applications.
>>
>> Fix: Windows platform offers 'pointer' implementation thro' which one 
>> can tap for the touch inputs as well. A typical 'pointer' function 
>> may contain touch, pen, touch pad or mouse inputs. This allows for a 
>> uniform input processing though the event source may defer. This fix 
>> enables the 'touch' events(via TOUCH pointer) to be passed to the 
>> components using the other type of pointer 'mouse'. Essentially there 
>> is a conversion put in place to convert a touch event input into a 
>> left click mouse event. I think this is the right thing to do 
>> considering desktop scenarios to which the typical Java applications 
>> that gets exposed to. This is also the same behavior on my touch 
>> enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
>>
>> Now touch event works as a typical mouse left click as in general. 
>> But there is an issue because the icon size of the Java UI is 
>> typically small, touching that icon exactly is sometimes difficult. 
>> This is handled by an Windows application by having larger icon size 
>> or icon view as a standard. Hence I believe this is outside the scope 
>> this software update. Any changes to it would be done later as a new 
>> bug or an enhancement.
>>
>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361
>>
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
>>
>> Thanks and regards,
>>
>> Shashi
>>
>
> --
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170919/72100908/attachment-0001.html>

From prasanta.sadhukhan at oracle.com  Wed Sep 20 05:26:31 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 20 Sep 2017 10:56:31 +0530
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
In-Reply-To: <a19185ff-acca-a2ed-a69d-ab0fe7fba753@oracle.com>
References: <bc568398-c4e4-41de-be9a-b2f3c57832fb@default>
 <dc2d8bd8-9c61-ab13-1405-1338920f9fca@oracle.com>
 <a19185ff-acca-a2ed-a69d-ab0fe7fba753@oracle.com>
Message-ID: <d3727c16-5845-1baf-0700-513b7ff09ec9@oracle.com>

Hi Sergey,


On 9/18/2017 11:57 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> ?- In this version it is unclear what is a purpose of the 
> "fxCheckSequenceThread.start()". This code will start the thread and 
> will continue execution, it will not wait when the thread will stop.
> ?- The DefaultKeyboardFocusManager also should check for 
> "javafx.embed.singleThread"
>
Please find modified webrev catering to both comments
http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.04/

Regards
Prasanta
>
> On 9/13/17 03:11, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> I have modified the fix to not use SecondaryLoop and not to create 
>> one thread per dispatch
>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/
>>
>> Regards
>> Prasanta
>> On 8/30/2017 11:41 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Can you please provide some description on how the SecondaryLoop 
>>> will work when it will run on Appkit thread? Is it possible to get a 
>>> deadlock here, since appkit will be blocked?
>>>
>>>> sequence, ie if the event is not first in sequence, then it will made
>>>> to
>>>> wait till it is the first event or till it is disposed.
>>> Note that the new code (unlike lines 139-150) also waits 1 second, 
>>> so we can get a situation when only one event will be dispatched per 
>>> second, which is not we want to do.
>>> I am not sure how often we create SequencedEvent but creating one 
>>> thread per dispatch look inefficient.
>>>
>>>
>>>> Modified webrev
>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>>
>>>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
>>>>>> Now, since here FX App thread itself is the dispatch thread, we can
>>>>>> be sure the events are dispatched in sequence and dispose is
>>>> checked
>>>>>> below after EDT.
>>>>> Why we can sure about this? If the SequencedEvents were created in
>>>> one
>>>>> order but dispatch() for each were called in other order then the
>>>>> sequenced will not be preserved?
>>>>>
>>>>>> I have tested with couple of singleThread testcase without any
>>>> issue.
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
>>>>>>> Hi, Prasanta, Kevin.
>>>>>>>
>>>>>>> I have two notes.
>>>>>>> ?? - Does this option is really supported? If it is supported we
>>>>>>> should evaluate all usage of EventDispatchThread because in this
>>>>>>> mode the dispatch thread is not EDT. For example I am not sure
>>>> that
>>>>>>> we can skip the code which expects EventDispatchThread.
>>>>>>> ?? - We have the similar pattern: "EventQueue.isDispatchThread() ->
>>>>>>> cast(EventDispatchThread)" in some other places like in
>>>>>>> DefaultKeyboardFocusManager.
>>>>>>>
>>>>>>> -----prasanta.sadhukhan at oracle.com? wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review this fix
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>>>>>>>> for an fx issue
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>>>>>>>
>>>>>>>> More info in JBS.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>
>>
>
>


From pankaj.b.bansal at oracle.com  Wed Sep 20 12:42:41 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 20 Sep 2017 05:42:41 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: JDK-8000171 : [TEST_BUG]
 java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java
Message-ID: <9617743f-31bc-4d2f-82d9-551cb6eeec36@default>

Hi All,

 

Please review the fix for test program test java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java for JDK 10.

 

Bug:

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

 

Webrev:

http://cr.openjdk.java.net/~aghaisas/pankaj/8000171/webrev.0/

 

Issue:

The test java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java fails on Windows as it throws SunToolkit.Infinite loop exception. The reason is it is using SunToolkit.realSync which throws this exception after fixed number of tries. 

 

Fix:

Made changes java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java to use Thread.sleep. The fix iterates until the frame become visible. This test is passing on Windows, Linux and Mac with the proposed fix.

 

 

Regards,

Pankaj Bansal

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170920/f97e74c7/attachment.html>

From pankaj.b.bansal at oracle.com  Wed Sep 20 12:49:30 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 20 Sep 2017 05:49:30 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG]
 java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
Message-ID: <bb4b6c2b-4457-429f-a3be-c9e44a52d38c@default>

Hi All,

 

Please review the fix for test program test java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java for JDK 10.

 

Bug:

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

 

Webrev:

http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/

 

Issue:

The test  java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java fails on Linux intermittently due to "java.lang.IllegalArgumentException: Width (0) and height (0) cannot be <= 0" exception.

 

Fix:

Made changes in java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to set the size of frame to make the test more stable.

 

Regards,

Pankaj Bansal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170920/42d4baeb/attachment.html>

From sergey.bylokhov at oracle.com  Wed Sep 20 14:35:49 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Sep 2017 07:35:49 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG]
 java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
Message-ID: <ca24d335-0118-4dbd-9d29-af694b667d0b@default>

Hi, Pankaj. 
Looks fine, I assume that the test now pass on Ubuntu with GTK L&F. 

----- pankaj.b.bansal at oracle.com wrote: 
> 
> 
> 

Hi All, 



Please review the fix for test program test java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java for JDK 10. 



Bug: 

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



Webrev: 

http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/ 



Issue: 

The test java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java fails on Linux intermittently due to ?java.lang.IllegalArgumentException: Width (0) and height (0) cannot be <= 0? exception. 



Fix: 

Made changes in java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to set the size of frame to make the test more stable. 



Regards, 

Pankaj Bansal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170920/278c5244/attachment.html>

From sergey.bylokhov at oracle.com  Wed Sep 20 14:40:34 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Sep 2017 07:40:34 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: JDK-8000171 : [TEST_BUG]
 java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java
Message-ID: <0861a264-d23d-4b45-bcb5-921c0236c508@default>

Hi, Pankaj. 
The SunToolkit.realSync method is now a part of the public API, the Robot.waitForIdle() is implemented on top of it. If this particular test can produce such exception then it looks like a product issue, not a test bug. 

----- pankaj.b.bansal at oracle.com wrote: 
> 
> 
> 

Hi All, 



Please review the fix for test program test java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java for JDK 10. 



Bug: 

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



Webrev: 

http://cr.openjdk.java.net/~aghaisas/pankaj/8000171/webrev.0/ 



Issue: 

The test java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java fails on Windows as it throws SunToolkit.Infinite loop exception. The reason is it is using SunToolkit.realSync which throws this exception after fixed number of tries. 



Fix: 

Made changes java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java to use Thread.sleep. The fix iterates until the frame become visible. This test is passing on Windows, Linux and Mac with the proposed fix. 





Regards, 

Pankaj Bansal 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170920/b711b3f5/attachment.html>

From semyon.sadetsky at oracle.com  Wed Sep 20 15:32:00 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 20 Sep 2017 08:32:00 -0700
Subject: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG]
 java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
In-Reply-To: <bb4b6c2b-4457-429f-a3be-c9e44a52d38c@default>
References: <bb4b6c2b-4457-429f-a3be-c9e44a52d38c@default>
Message-ID: <2e4e0a44-196d-a0bf-3431-a0cd820243f3@oracle.com>

Hi Pankaj,

The root cause of the issue is that the underling native window is not 
yet created when its with and height are requested. This is because 
windows are created asynchronously. The test should be fixed by adding 
Robot.waitForIdle() after frame.setVisible(true).

--Semyon


On 09/20/2017 05:49 AM, Pankaj Bansal wrote:
>
> Hi All,
>
> Please review the fix for test program test 
> java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java for JDK 10.
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-6857809
>
> Webrev:
>
> http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/ 
> <http://cr.openjdk.java.net/%7Eaghaisas/pankaj/6857809/webrev.0/>
>
> Issue:
>
> The test  java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java 
> fails on Linux intermittently due to 
> ?java.lang.IllegalArgumentException: Width (0) and height (0) cannot 
> be <= 0? exception.
>
> Fix:
>
> Made changes in 
> java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to set the 
> size of frame to make the test more stable.
>
> Regards,
>
> Pankaj Bansal
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170920/b06a268d/attachment-0001.html>

From pankaj.b.bansal at oracle.com  Wed Sep 20 16:21:04 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 20 Sep 2017 09:21:04 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG]
 java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
In-Reply-To: <2e4e0a44-196d-a0bf-3431-a0cd820243f3@oracle.com>
References: <bb4b6c2b-4457-429f-a3be-c9e44a52d38c@default>
 <2e4e0a44-196d-a0bf-3431-a0cd820243f3@oracle.com>
Message-ID: <8843df5e-ace9-41a5-96d6-d49e0d1058ab@default>

Hi Seymon,

 

I think the issue is because no size is set on frame. This is also the proposed fix in the bug description.

 

Regards,

Pankaj

 

From: Semyon Sadetsky 
Sent: Wednesday, September 20, 2017 9:02 PM
To: Pankaj Bansal; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

 

Hi Pankaj,

The root cause of the issue is that the underling native window is not yet created when its with and height are requested. This is because windows are created asynchronously. The test should be fixed by adding Robot.waitForIdle() after frame.setVisible(true).

--Semyon

 

On 09/20/2017 05:49 AM, Pankaj Bansal wrote:

Hi All,

 

Please review the fix for test program test java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java for JDK 10.

 

Bug:

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

 

Webrev:

HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/pankaj/6857809/webrev.0/"http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/

 

Issue:

The test  java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java fails on Linux intermittently due to "java.lang.IllegalArgumentException: Width (0) and height (0) cannot be <= 0" exception.

 

Fix:

Made changes in java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to set the size of frame to make the test more stable.

 

Regards,

Pankaj Bansal

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

From semyon.sadetsky at oracle.com  Wed Sep 20 17:13:27 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 20 Sep 2017 10:13:27 -0700
Subject: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG]
 java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
In-Reply-To: <8843df5e-ace9-41a5-96d6-d49e0d1058ab@default>
References: <bb4b6c2b-4457-429f-a3be-c9e44a52d38c@default>
 <2e4e0a44-196d-a0bf-3431-a0cd820243f3@oracle.com>
 <8843df5e-ace9-41a5-96d6-d49e0d1058ab@default>
Message-ID: <a292e719-7d95-656d-1f8e-c3d35e5d6ec1@oracle.com>

On 09/20/2017 09:21 AM, Pankaj Bansal wrote:

> Hi Seymon,
>
> I think the issue is because no size is set on frame. This is also the 
> proposed fix in the bug description.
>
This is good, but setting a fixed frame size forces the java Frame 
object to return that size only at the very beginning the real and final 
frame dimensions will be established  asynchronously by the native 
window subsystem.
>
> Regards,
>
> Pankaj
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, September 20, 2017 9:02 PM
> *To:* Pankaj Bansal; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG] 
> java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
>
> Hi Pankaj,
>
> The root cause of the issue is that the underling native window is not 
> yet created when its with and height are requested. This is because 
> windows are created asynchronously. The test should be fixed by adding 
> Robot.waitForIdle() after frame.setVisible(true).
>
> --Semyon
>
> On 09/20/2017 05:49 AM, Pankaj Bansal wrote:
>
>     Hi All,
>
>     Please review the fix for test program test
>     java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java for
>     JDK 10.
>
>     Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-6857809
>
>     Webrev:
>
>     http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/
>     <http://cr.openjdk.java.net/%7Eaghaisas/pankaj/6857809/webrev.0/>
>
>     Issue:
>
>     The test
>      java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java fails
>     on Linux intermittently due to
>     ?java.lang.IllegalArgumentException: Width (0) and height (0)
>     cannot be <= 0? exception.
>
>     Fix:
>
>     Made changes in
>     java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to set
>     the size of frame to make the test more stable.
>
>     Regards,
>
>     Pankaj Bansal
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170920/b0b369b9/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Sep 20 21:41:29 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Sep 2017 14:41:29 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
Message-ID: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>

Hi, Semyon
I have some initial comments which are based on the two bugs: 
JDK-8182043 and JDK-8156183.

getSystemIcon(File file, int size):
     - How the user will know what values/sizes should be passed, what 
values are supported? It is unlikely that he will pass all values in 
between 8-256?

"For any positive size value the exact file icon size is queried":
     - This should be double checked because our implementation can 
return MultiResolutionIconImage if the system returns the icon which 
size is different from requested.

FILE_ICON_SMALL(FILE_ICON_LARGE);
     - What these parameters mean? Is it the smallest(biggest) supported 
size or is it a default size? Can it be different if different dpi are 
used on the screen? For example 16(32) by default and 32(64) on HiDPI?

FILE_ICON_SMALL:
    - It seems that this value duplicate functionality of the old 
getSystemIcon(File) method?


Probably it will be better to provide to the user the 
set(list/mri/array/etc) of supported images, or if it is really slow the 
set(list/mri/array/etc) of supported sizes, and the user will be able to 
pass some meaningful sizes.


On 9/13/17 11:01, Semyon Sadetsky wrote:
> Hello,
> 
> Please review fix for JDK10 (the changes involve AWT and Swing):
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
> 
> webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
> 
> The fix? opens the part of the ShellFolder API for getting system icons 
> which was decided to be left closed during the 8081722 enhancement 
> review in 9.
> 
> Also the fix extends the API by adding possibility to query file icons 
> of arbitrary size and implements this extension for Windows platform.
> 
> --Semyon
> 


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Thu Sep 21 06:07:06 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Wed, 20 Sep 2017 23:07:06 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <cd2f4c15-5ec0-a90b-c9d7-93152b6ead5e@oracle.com>
References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default>
 <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default>
 <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com>
 <992a8202-6ac9-4c16-9fe5-c316e314bed5@default>
 <cd2f4c15-5ec0-a90b-c9d7-93152b6ead5e@oracle.com>
Message-ID: <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default>

Hi Sergey, I was able to input the surrogate pairs and got the required output as shown below:

?



?

?

Below is the output after we input the surrogate pairs:

?



?

Thanks and regards,

Shashi

?

?

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, September 14, 2017 11:33 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

?

The java uses UTF16, I guess this new api should use it also, and we should check that the surrogate pairs will be supported.

?

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.

> 

> Thanks and regards,

> Shashi

> 

> -----Original Message-----

> From: Sergey Bylokhov

> Sent: Wednesday, September 13, 2017 5:22 AM

> To: Shashidhara Veerabhadraiah 

> <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky 

> <HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net

> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

> 

> Hi, Shashi.

> One initial question:

> What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?

> 

> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

>> Hi, I have updated the Webrev to accommodate the comments and here is 

>> the new Webrev:

>>?

>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

>>?

>> I have separated the /_Unicode_/ keys input via java robot as a new 

>> set of /_public_/ api?s (this is in similar fashion as how the 

>> platform offers the Unicode keys input into the system) and this has 

>> been tested on all the platforms using the test file similar to the 

>> attached file in the bug. A more proper test file would be put for 

>> review in the subsequent reviews.

>>?

>> Thanks and regards,

>>?

>> Shashi

>>?

>> *From:* Sergey Bylokhov

>> *Sent:* Wednesday, August 30, 2017 2:33 AM

>> *To:* Shashidhara Veerabhadraiah

>> <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>

>> *Cc:* HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net

>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should 

>> be able to use extended key code characters as ? ? ?.

>>?

>> Hi, Shashi.

>>?

>> This is part of this fix, to figure out how it will work for external 

>> applications. As you said this functionally can be useful for an 

>> onscreen keyboards, which virtually can have any possible keys, but 

>> we should check how the applications will react on such keys:

>>?? ?- Will the application get some kind of keyPress/Release?

>>?? ?- Will the application get some keyCode for such event?

>>?? ?- Is it possible to get autorepeat for such keys?(between

>> press/release)

>>?

>> Depending from the answers above we can enhance existed robot API or 

>> provide a new one:

>> like Robot.keyType(char)/etc

>>?

>> ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com

>> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:

>>>?

>>?

>>>?

>>?

>>>?

>>?

>> Hi Sergey, I was only able to add short cut keys in the Microsoft 

>> word but not as a system wide short cut key. There was no mechanism 

>> that I could find to add a short cut key for a Unicode char!! Can you 

>> please tell me the steps to do the same if you are aware of?

>>?

>> Thanks and regards,

>>?

>> shashi

>>?

>>>?

>>?

>> *From:*Sergey Bylokhov

>>> *Sent:* Tuesday, August 22, 2017 8:34 PM

>>> *To:* Shashidhara Veerabhadraiah

>>> <shashidhara.veerabhadraiah at oracle.com

>> <mailto:shashidhara.veerabhadraiah at oracle.com>>

>>> *Cc:* HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>

>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress 

>>> should be

>> able to use extended key code characters as ? ? ?.

>>?

>> Hi, Shashi.

>>> Can you check how this Robot API will work when the application will have a shortcut for such key? Will such shortcuts will work after this fix?

>>>?

>>> ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com

>> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:

>>>>?

>>?

>>>?

>>?

>>>?

>>?

>> Hi All, Please review fix for the /_enhancement_/ wherein the robot 

>> key press of non-ascii were interpreted as question marks.

>>?

>> Issue: The robot key press events was handling only the ascii inputs 

>> and ignored the other Unicode inputs. Either it was throwing illegal 

>> argument exception in windows or does nothing on the mac for those 

>> Unicode inputs.

>>?

>> Solution and fix: The platform specific api?s was unable handle the 

>> non-ascii inputs. I have modified the api?s to accept the non-ascii 

>> inputs and correspondingly send the message to the window to print 

>> the non-ascii characters as well. Below is the picture of how the 

>> non-ascii inputs are considered and printed onto the window.

>>?

>> The solution spans across windows and mac platform and still in 

>> search of a solution for the Linux platform. The solution implements 

>> key scanning only upon existing valid ascii key was /_not_/ found and 

>> assumes it as Unicode key and sends the event to event queue to be 

>> processed as Unicode keys. Different formats are being used by 

>> different platform implementation of Unicode. For ex., per the below 

>> Unicode list, in the case of windows and mac, the key input can take 

>> decimal values whereas on Linux it can only take the Code values.

>>?

>> On Linux, I was able to get the KeySym of Unicode keys but was unable 

>> to fake the key event as there was no mechanism available for the 

>> same(which sends the key event to window). Please let me know if 

>> there is any such mechanism available to simulate Unicode key events 

>> on Linux platform. Hence I think to raise a bug for the Linux 

>> platform and close this JDK-8148344 bug.

>>?

>> Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344

>>?

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

>>?

>> Thanks and regards,

>>?

>> Shashi

>>?

> 

> 

> --

> Best regards, Sergey.

> 

?

?

--

Best regards, Sergey.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170920/8888ae66/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2570 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170920/8888ae66/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 51206 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170920/8888ae66/image004-0001.jpg>

From pankaj.b.bansal at oracle.com  Thu Sep 21 08:29:22 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 21 Sep 2017 01:29:22 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <18341159-32d7-ebb4-05da-a04224a4d2e7@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
 <59BC6247.9020408@oracle.com>
 <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>
 <5afacc8a-2236-5955-ed5a-22bd05b378f8@oracle.com>
 <86e0f409-e5d5-666e-a85a-0019e759abdd@oracle.com>
 <fba0ab2f-5380-db32-6e13-5751d1ba37b1@oracle.com>
 <9bd32de3-af72-a911-2e70-029af10a099f@oracle.com>
 <18341159-32d7-ebb4-05da-a04224a4d2e7@oracle.com>
Message-ID: <c033d389-e602-47b1-9135-fc82e1ad0397@default>

Hi Sergey/Semyon,

I have updated the webrev according to your comments. Please review.
Webrev:   http://cr.openjdk.java.net/~psadhukhan/pankaj/webrev/

Regards,
Pankaj Bansal

-----Original Message-----
From: Semyon Sadetsky 
Sent: Tuesday, September 19, 2017 8:40 PM
To: Sergey Bylokhov; Pankaj Bansal; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

On 09/18/2017 11:04 AM, Sergey Bylokhov wrote:

> On 9/18/17 10:14, Semyon Sadetsky wrote:
>>> It is fine because it tests the ComponentOrientation class which is 
>>> loaded from the resource bundle and applied to the window.
>> I would agree with you if the resource bundle at least contained a 
>> value for the component orientation but it sets some specific locale 
>> codes. And java's locale functionality is not a subject of the 
>> client-libs, it is an another module. Also, as it was already pointed 
>> out, the method was deprecated long time ago.
>
> Where did you check these bundles? Because resource bundles for this 
> test contains the all variations of orientation 
> property(UNKNOWN/LEFT_TO_RIGHT/RIGHT_TO_LEFT/none).
OK. I missed those bundle classes with the orientation properties. I think the test may either be left as it is, or moved to the i18n suite with adding a test to ComponentOrientation suite that tests
applyComponentOrientation() directly.
>
>>>
>>>>
>>>>
>>>> On 9/15/17 4:53 PM, Sergey Bylokhov wrote:
>>>>> I guess you missed something, the possibility to configure the 
>>>>> components via ResourceBudnle or locale is something different 
>>>>> that the hardcore the orientation in the application. And the fact 
>>>>> that this test found the bug in jdk9 just show that the test is 
>>>>> valid.
>>>>>
>>>>> On 9/15/17 16:29, Semyon Sadetsky wrote:
>>>>>> The component orientation test suite should use the right API, 
>>>>>> not the deprecated one. This was missed when the new API is created.
>>>>>> So the change is valid from this point with the corresponding 
>>>>>> comment in JIRA.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>>>>>>
>>>>>>> On 9/14/17 23:15, Pankaj Bansal wrote:
>>>>>>>> This test is not failing with JDK 9_181 and JDK10 as methods 
>>>>>>>> are deprecated not removed. It is giving lot of warning for 
>>>>>>>> using deprecated things, so I made these changes. I think the 
>>>>>>>> bug description should be changed to notify that.
>>>>>>>
>>>>>>> I am not sure that it is correct to replace one API to another 
>>>>>>> one. This test was written as part of i18n support and it checks 
>>>>>>> that our API can be configured by the ResourceBundles. The 
>>>>>>> updated test doing the different things - it checks that 
>>>>>>> getComponentOrientation will return the value which were set by 
>>>>>>> applyComponentOrientation().
>>>>>>>
>>>>>>> Since it was reported that the test failed because of some bug, 
>>>>>>> but looks like now it work as expected, this CR can be closed as 
>>>>>>> not reproducible. Or you can clean the test but without changing 
>>>>>>> its logic.
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Pankaj Bansal
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Sergey Bylokhov
>>>>>>>> Sent: Thursday, September 14, 2017 11:30 PM
>>>>>>>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>>>>>>>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : 
>>>>>>>> [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
>>>>>>>>
>>>>>>>> Hi, Pankaj.
>>>>>>>> Can you please clarify why this test fails on jdk9? This method 
>>>>>>>> is deprecated but it was not removed, so it should work.
>>>>>>>> Probably at some point of jdk9 development it was broken?
>>>>>>>>
>>>>>>>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review the fix for test program 
>>>>>>>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>>>>>>>
>>>>>>>>> Bug:
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>>>>>>>
>>>>>>>>> Webrev:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>>>>>>>
>>>>>>>>> Issue:
>>>>>>>>>
>>>>>>>>> The test java/awt/ComponentOrientation/WindowTest.java uses 
>>>>>>>>> depreciated function  applyResourceBundle. So the test should 
>>>>>>>>> be updated to use applyComponentOrientation function.
>>>>>>>>>
>>>>>>>>> Fix:
>>>>>>>>>
>>>>>>>>> Made changes in java/awt/ComponentOrientation/WindowTest.java
>>>>>>>>> to use
>>>>>>>>> applyComponentOrientation function and did corresponding changes.
>>>>>>>>> Along with that, the test is also using java.applet.Applet 
>>>>>>>>> which is also deprecated, so changed the test to use Frame 
>>>>>>>>> instead.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Pankaj Bansal
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From shashidhara.veerabhadraiah at oracle.com  Thu Sep 21 08:44:05 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 21 Sep 2017 01:44:05 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default>
References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default>
 <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default>
 <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com>
 <992a8202-6ac9-4c16-9fe5-c316e314bed5@default>
 <cd2f4c15-5ec0-a90b-c9d7-93152b6ead5e@oracle.com>
 <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default>
Message-ID: <c2325614-283e-48e0-acef-09df6c9f42b8@default>

Hi All, Please find the updated webrev containing a new test that is added to test out the software changes that were made under this enhancement.

?

http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Thursday, September 21, 2017 11:37 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

?

Hi Sergey, I was able to input the surrogate pairs and got the required output as shown below:

?



?

?

Below is the output after we input the surrogate pairs:

?



?

Thanks and regards,

Shashi

?

?

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, September 14, 2017 11:33 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky <HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

?

The java uses UTF16, I guess this new api should use it also, and we should check that the surrogate pairs will be supported.

?

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as the window characteristic which is UTF 8 as implemented in Java.

> 

> Thanks and regards,

> Shashi

> 

> -----Original Message-----

> From: Sergey Bylokhov

> Sent: Wednesday, September 13, 2017 5:22 AM

> To: Shashidhara Veerabhadraiah 

> <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky 

> <HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net

> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

> 

> Hi, Shashi.

> One initial question:

> What is an int parameter of these methods means, is it a "Unicode code point"? What encoding utf8/utf16 should be used?

> 

> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

>> Hi, I have updated the Webrev to accommodate the comments and here is 

>> the new Webrev:

>>?

>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

>>?

>> I have separated the /_Unicode_/ keys input via java robot as a new 

>> set of /_public_/ api?s (this is in similar fashion as how the 

>> platform offers the Unicode keys input into the system) and this has 

>> been tested on all the platforms using the test file similar to the 

>> attached file in the bug. A more proper test file would be put for 

>> review in the subsequent reviews.

>>?

>> Thanks and regards,

>>?

>> Shashi

>>?

>> *From:* Sergey Bylokhov

>> *Sent:* Wednesday, August 30, 2017 2:33 AM

>> *To:* Shashidhara Veerabhadraiah

>> <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>

>> *Cc:* HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net

>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should 

>> be able to use extended key code characters as ? ? ?.

>>?

>> Hi, Shashi.

>>?

>> This is part of this fix, to figure out how it will work for external 

>> applications. As you said this functionally can be useful for an 

>> onscreen keyboards, which virtually can have any possible keys, but 

>> we should check how the applications will react on such keys:

>>?? ?- Will the application get some kind of keyPress/Release?

>>?? ?- Will the application get some keyCode for such event?

>>?? ?- Is it possible to get autorepeat for such keys?(between

>> press/release)

>>?

>> Depending from the answers above we can enhance existed robot API or 

>> provide a new one:

>> like Robot.keyType(char)/etc

>>?

>> ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com

>> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:

>>>?

>>?

>>>?

>>?

>>>?

>>?

>> Hi Sergey, I was only able to add short cut keys in the Microsoft 

>> word but not as a system wide short cut key. There was no mechanism 

>> that I could find to add a short cut key for a Unicode char!! Can you 

>> please tell me the steps to do the same if you are aware of?

>>?

>> Thanks and regards,

>>?

>> shashi

>>?

>>>?

>>?

>> *From:*Sergey Bylokhov

>>> *Sent:* Tuesday, August 22, 2017 8:34 PM

>>> *To:* Shashidhara Veerabhadraiah

>>> <shashidhara.veerabhadraiah at oracle.com

>> <mailto:shashidhara.veerabhadraiah at oracle.com>>

>>> *Cc:* HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>

>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress 

>>> should be

>> able to use extended key code characters as ? ? ?.

>>?

>> Hi, Shashi.

>>> Can you check how this Robot API will work when the application will have a shortcut for such key? Will such shortcuts will work after this fix?

>>>?

>>> ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com

>> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:

>>>>?

>>?

>>>?

>>?

>>>?

>>?

>> Hi All, Please review fix for the /_enhancement_/ wherein the robot 

>> key press of non-ascii were interpreted as question marks.

>>?

>> Issue: The robot key press events was handling only the ascii inputs 

>> and ignored the other Unicode inputs. Either it was throwing illegal 

>> argument exception in windows or does nothing on the mac for those 

>> Unicode inputs.

>>?

>> Solution and fix: The platform specific api?s was unable handle the 

>> non-ascii inputs. I have modified the api?s to accept the non-ascii 

>> inputs and correspondingly send the message to the window to print 

>> the non-ascii characters as well. Below is the picture of how the 

>> non-ascii inputs are considered and printed onto the window.

>>?

>> The solution spans across windows and mac platform and still in 

>> search of a solution for the Linux platform. The solution implements 

>> key scanning only upon existing valid ascii key was /_not_/ found and 

>> assumes it as Unicode key and sends the event to event queue to be 

>> processed as Unicode keys. Different formats are being used by 

>> different platform implementation of Unicode. For ex., per the below 

>> Unicode list, in the case of windows and mac, the key input can take 

>> decimal values whereas on Linux it can only take the Code values.

>>?

>> On Linux, I was able to get the KeySym of Unicode keys but was unable 

>> to fake the key event as there was no mechanism available for the 

>> same(which sends the key event to window). Please let me know if 

>> there is any such mechanism available to simulate Unicode key events 

>> on Linux platform. Hence I think to raise a bug for the Linux 

>> platform and close this JDK-8148344 bug.

>>?

>> Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344

>>?

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

>>?

>> Thanks and regards,

>>?

>> Shashi

>>?

> 

> 

> --

> Best regards, Sergey.

> 

?

?

--

Best regards, Sergey.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170921/26b8768b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 50252 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170921/26b8768b/image001-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2570 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170921/26b8768b/image002-0001.png>

From pankaj.b.bansal at oracle.com  Thu Sep 21 08:44:22 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 21 Sep 2017 01:44:22 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG]
 java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
In-Reply-To: <a292e719-7d95-656d-1f8e-c3d35e5d6ec1@oracle.com>
References: <bb4b6c2b-4457-429f-a3be-c9e44a52d38c@default>
 <2e4e0a44-196d-a0bf-3431-a0cd820243f3@oracle.com>
 <8843df5e-ace9-41a5-96d6-d49e0d1058ab@default>
 <a292e719-7d95-656d-1f8e-c3d35e5d6ec1@oracle.com>
Message-ID: <9e451163-a1d4-44c4-9484-43210aef032f@default>

Hi Sergey/Seymon,

 

I have incorporated the webrev for review comments.

Yes Sergey, the test passes on Ubuntu with GTK L&F.

Webrev:  http://cr.openjdk.java.net/~psadhukhan/pankaj/JDK-6857809-webrev.01/

Regards,

Pankaj Bansal

 

 

From: Semyon Sadetsky 
Sent: Wednesday, September 20, 2017 10:43 PM
To: Pankaj Bansal; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

 

On 09/20/2017 09:21 AM, Pankaj Bansal wrote:

Hi Seymon,

 

I think the issue is because no size is set on frame. This is also the proposed fix in the bug description.

This is good, but setting a fixed frame size forces the java Frame object to return that size only at the very beginning the real and final frame dimensions will be established  asynchronously by the native window subsystem.



Regards,

Pankaj

 

From: Semyon Sadetsky 
Sent: Wednesday, September 20, 2017 9:02 PM
To: Pankaj Bansal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

 

Hi Pankaj,

The root cause of the issue is that the underling native window is not yet created when its with and height are requested. This is because windows are created asynchronously. The test should be fixed by adding Robot.waitForIdle() after frame.setVisible(true).

--Semyon

 

On 09/20/2017 05:49 AM, Pankaj Bansal wrote:

Hi All,

 

Please review the fix for test program test java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java for JDK 10.

 

Bug:

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

 

Webrev:

HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/pankaj/6857809/webrev.0/"http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/

 

Issue:

The test  java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java fails on Linux intermittently due to "java.lang.IllegalArgumentException: Width (0) and height (0) cannot be <= 0" exception.

 

Fix:

Made changes in java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to set the size of frame to make the test more stable.

 

Regards,

Pankaj Bansal

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170921/178bf119/attachment.html>

From semyon.sadetsky at oracle.com  Thu Sep 21 14:54:00 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 21 Sep 2017 07:54:00 -0700
Subject: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG]
 java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
In-Reply-To: <9e451163-a1d4-44c4-9484-43210aef032f@default>
References: <bb4b6c2b-4457-429f-a3be-c9e44a52d38c@default>
 <2e4e0a44-196d-a0bf-3431-a0cd820243f3@oracle.com>
 <8843df5e-ace9-41a5-96d6-d49e0d1058ab@default>
 <a292e719-7d95-656d-1f8e-c3d35e5d6ec1@oracle.com>
 <9e451163-a1d4-44c4-9484-43210aef032f@default>
Message-ID: <7987dffb-cee8-5e8a-c900-4c51742ce447@oracle.com>

Looks good to me.

--Semyon


On 09/21/2017 01:44 AM, Pankaj Bansal wrote:
>
> Hi Sergey/Seymon,
>
> I have incorporated the webrev for review comments.
>
> Yes Sergey, the test passes on Ubuntu with GTK L&F.
>
> Webrev: 
> http://cr.openjdk.java.net/~psadhukhan/pankaj/JDK-6857809-webrev.01/ 
> <http://cr.openjdk.java.net/%7Epsadhukhan/pankaj/JDK-6857809-webrev.01/>
>
> Regards,
>
> Pankaj Bansal
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, September 20, 2017 10:43 PM
> *To:* Pankaj Bansal; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG] 
> java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
>
> On 09/20/2017 09:21 AM, Pankaj Bansal wrote:
>
>     Hi Seymon,
>
>     I think the issue is because no size is set on frame. This is also
>     the proposed fix in the bug description.
>
> This is good, but setting a fixed frame size forces the java Frame 
> object to return that size only at the very beginning the real and 
> final frame dimensions will be established  asynchronously by the 
> native window subsystem.
>
>     Regards,
>
>     Pankaj
>
>     *From:*Semyon Sadetsky
>     *Sent:* Wednesday, September 20, 2017 9:02 PM
>     *To:* Pankaj Bansal; awt-dev at openjdk.java.net
>     <mailto:awt-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> [10] Review Request: JDK-6857809 :
>     [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
>
>     Hi Pankaj,
>
>     The root cause of the issue is that the underling native window is
>     not yet created when its with and height are requested. This is
>     because windows are created asynchronously. The test should be
>     fixed by adding Robot.waitForIdle() after frame.setVisible(true).
>
>     --Semyon
>
>     On 09/20/2017 05:49 AM, Pankaj Bansal wrote:
>
>         Hi All,
>
>         Please review the fix for test program test
>         java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
>         for JDK 10.
>
>         Bug:
>
>         https://bugs.openjdk.java.net/browse/JDK-6857809
>
>         Webrev:
>
>         http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/
>         <http://cr.openjdk.java.net/%7Eaghaisas/pankaj/6857809/webrev.0/>
>
>         Issue:
>
>         The test
>          java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
>         fails on Linux intermittently due to
>         ?java.lang.IllegalArgumentException: Width (0) and height (0)
>         cannot be <= 0? exception.
>
>         Fix:
>
>         Made changes in
>         java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to
>         set the size of frame to make the test more stable.
>
>         Regards,
>
>         Pankaj Bansal
>

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

From semyon.sadetsky at oracle.com  Thu Sep 21 15:54:40 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 21 Sep 2017 08:54:40 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
Message-ID: <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>

On 09/20/2017 02:41 PM, Sergey Bylokhov wrote:

> Hi, Semyon
> I have some initial comments which are based on the two bugs: 
> JDK-8182043 and JDK-8156183.
>
> getSystemIcon(File file, int size):
>     - How the user will know what values/sizes should be passed, what 
> values are supported? It is unlikely that he will pass all values in 
> between 8-256?
Supported sizes are described in the method spec, aren't they?
This API doesn't imply any size limitation like the 8-256 you mentioned.
>
> "For any positive size value the exact file icon size is queried":
>     - This should be double checked because our implementation can 
> return MultiResolutionIconImage if the system returns the icon which 
> size is different from requested.
>
> FILE_ICON_SMALL(FILE_ICON_LARGE);
>     - What these parameters mean? Is it the smallest(biggest) 
> supported size or is it a default size? Can it be different if 
> different dpi are used on the screen? For example 16(32) by default 
> and 32(64) on HiDPI?
They means what they have been meaning FileChooserUI implementation for 
the Windows L&F which operates by two fixed icon sizes, large and small.
> FILE_ICON_SMALL:
>    - It seems that this value duplicate functionality of the old 
> getSystemIcon(File) method?
How this can be got from the spec? It may return the same size but not 
necessarily.
>
>
> Probably it will be better to provide to the user the 
> set(list/mri/array/etc) of supported images, or if it is really slow 
> the set(list/mri/array/etc) of supported sizes, and the user will be 
> able to pass some meaningful sizes.
This is not a good idea. Extracting all available icon resolutions might 
take significant time and since icons are cached it would be waste of RAM.
>
>
> On 9/13/17 11:01, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>
>> The fix  opens the part of the ShellFolder API for getting system 
>> icons which was decided to be left closed during the 8081722 
>> enhancement review in 9.
>>
>> Also the fix extends the API by adding possibility to query file 
>> icons of arbitrary size and implements this extension for Windows 
>> platform.
>>
>> --Semyon
>>
>
>


From semyon.sadetsky at oracle.com  Thu Sep 21 15:57:02 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 21 Sep 2017 08:57:02 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <5613bc79-21d8-620b-a864-9685dcc805cd@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
 <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
 <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>
 <4d3ae69d-7683-9945-a031-35825068f3b3@oracle.com>
 <0d43afe4-2815-4f56-1d77-c51407fa76f1@oracle.com>
 <3f47f95c-de47-c219-5c8f-a04074197923@oracle.com>
 <bdcaa9ce-9781-105d-64e8-1f67ce38f316@oracle.com>
 <28e93e42-2993-2394-0669-cd54747d5925@oracle.com>
 <59B9B2FB.7050503@oracle.com>
 <5613bc79-21d8-620b-a864-9685dcc805cd@oracle.com>
Message-ID: <3002d4e7-635c-16bf-47ed-50015be5b37c@oracle.com>

On 09/13/2017 03:42 PM, Sergey Bylokhov wrote:

> On 9/13/17 15:36, Semyon Sadetsky wrote:
>>> The problem in the fix is that the new checks do not try to be 
>>> thread safe.
>> So, what do you propose? Add a volatile field "disposing" and do noop 
>> if it is true?
>
> I have added a links to the bug which contain an examples, of how it 
> was implemented in other cases.
I did not get which links do you mean. Can you be more specific about 
the solution you are proposing?
>
>>
>>>
>>>>
>>>> --Semyon
>>>>>
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 09/13/2017 11:55 AM, Sergey Bylokhov wrote:
>>>>>>> On 9/13/17 11:49, Semyon Sadetsky wrote:
>>>>>>>> The tests passes after the fix for me. Which situations do you 
>>>>>>>> mean? Can you provide examples?
>>>>>>>
>>>>>>> For example in XFramePeer.setVisible() it is possible that the 
>>>>>>> peer became disposed after the new check.
>>>>>>>
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:
>>>>>>>>> Hi, Semyon.
>>>>>>>>> Did you check why the bug is not reproduced on jdk8?
>>>>>>>>> I guess that it is still possible to get a situations below 
>>>>>>>>> because of absent synchronization on all paths of usage 
>>>>>>>>> "window",isDispose() and dispose() method:
>>>>>>>>>  - check isDispose().
>>>>>>>>>  - dispose the peer
>>>>>>>>>  - use the long value which was disposed step above
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/8/17 20:00, Semyon Sadetsky wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review fix for JDK10:
>>>>>>>>>>
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
>>>>>>>>>>
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
>>>>>>>>>>
>>>>>>>>>> After toolkit window is destroyed methods invocations on the 
>>>>>>>>>> window component may cause exceptions because of wrong native 
>>>>>>>>>> xwindow ID. The fix introduces checks in the X* peers to 
>>>>>>>>>> ensure that window ID is actual otherwise do nothing.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From philip.race at oracle.com  Thu Sep 21 16:55:27 2017
From: philip.race at oracle.com (Phil Race)
Date: Thu, 21 Sep 2017 09:55:27 -0700
Subject: <AWT Dev> [10] Review request for 185634: Java Fx-Swing dialogs
 appearing behind main stage
In-Reply-To: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com>
References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com>
Message-ID: <c10968d7-af0b-d599-6620-dd95e4d7af12@oracle.com>

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be 
included here.
I've added that list.

And apart from needing separate bug ids, I don't see why the bug below 
is confidential.


I agree with what Kevin pointed out off-line that as in the dialog case, 
the FX side
of the code can use reflection and simply be a harmless non-functional no-op
if the SwingAccessor does not provide the new method.

BTW

264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }

should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8185634
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170921/53dbf90b/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Thu Sep 21 20:52:26 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Sep 2017 13:52:26 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
Message-ID: <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>

On 9/21/17 08:54, Semyon Sadetsky wrote:
> On 09/20/2017 02:41 PM, Sergey Bylokhov wrote:
> 
>> Hi, Semyon
>> I have some initial comments which are based on the two bugs: 
>> JDK-8182043 and JDK-8156183.
>>
>> getSystemIcon(File file, int size):
>> ??? - How the user will know what values/sizes should be passed, what 
>> values are supported? It is unlikely that he will pass all values in 
>> between 8-256?
> Supported sizes are described in the method spec, aren't they?
> This API doesn't imply any size limitation like the 8-256 you mentioned.

Does it mean that all sizes will be supported(1-Integer.MAX_INT)? I 
guess it is unlikely that the the explorer.exe will contains the icons 
bigger than 1024.


>>
>> "For any positive size value the exact file icon size is queried":
>> ??? - This should be double checked because our implementation can 
>> return MultiResolutionIconImage if the system returns the icon which 
>> size is different from requested.
>>
>> FILE_ICON_SMALL(FILE_ICON_LARGE);
>> ??? - What these parameters mean? Is it the smallest(biggest) 
>> supported size or is it a default size? Can it be different if 
>> different dpi are used on the screen? For example 16(32) by default 
>> and 32(64) on HiDPI?
> They means what they have been meaning FileChooserUI implementation for 
> the Windows L&F which operates by two fixed icon sizes, large and small.

But it is not necessary will be used by our implementation of 
FileChooserUI when this API became public. For example in the 
description of JDK-8156183 the user said that large icons are used in "a 
media file browser" and "32x32 isn't large by the standards of 
current-millennium operating systems".
But even in our FileChooserUI implementation shouldn't we use x2 icons 
in case of HiDPI?
FILE_ICON_SMALL - is it a smallest supported size?

>> FILE_ICON_SMALL:
>> ?? - It seems that this value duplicate functionality of the old 
>> getSystemIcon(File) method?
> How this can be got from the spec? It may return the same size but not 
> necessarily.

Then how the old method and the new one are related? Will the old method 
returns the size in between FILE_ICON_SMALL and FILE_ICON_LARGE?

>>
>>
>> Probably it will be better to provide to the user the 
>> set(list/mri/array/etc) of supported images, or if it is really slow 
>> the set(list/mri/array/etc) of supported sizes, and the user will be 
>> able to pass some meaningful sizes.
> This is not a good idea. Extracting all available icon resolutions might 
> take significant time and since icons are cached it would be waste of RAM.

It should be measured, we can try to load them lazy, or provide the list 
of sizes which are supported.

>>
>>
>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>
>>> The fix? opens the part of the ShellFolder API for getting system 
>>> icons which was decided to be left closed during the 8081722 
>>> enhancement review in 9.
>>>
>>> Also the fix extends the API by adding possibility to query file 
>>> icons of arbitrary size and implements this extension for Windows 
>>> platform.
>>>
>>> --Semyon
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep 21 21:01:29 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Sep 2017 14:01:29 -0700
Subject: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG]
 java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
In-Reply-To: <7987dffb-cee8-5e8a-c900-4c51742ce447@oracle.com>
References: <bb4b6c2b-4457-429f-a3be-c9e44a52d38c@default>
 <2e4e0a44-196d-a0bf-3431-a0cd820243f3@oracle.com>
 <8843df5e-ace9-41a5-96d6-d49e0d1058ab@default>
 <a292e719-7d95-656d-1f8e-c3d35e5d6ec1@oracle.com>
 <9e451163-a1d4-44c4-9484-43210aef032f@default>
 <7987dffb-cee8-5e8a-c900-4c51742ce447@oracle.com>
Message-ID: <d0248b72-429a-83f7-6f64-a04c1b7b9501@oracle.com>

+1

On 9/21/17 07:54, Semyon Sadetsky wrote:
> Looks good to me.
> 
> --Semyon
> 
> 
> On 09/21/2017 01:44 AM, Pankaj Bansal wrote:
>>
>> Hi Sergey/Seymon,
>>
>> I have incorporated the webrev for review comments.
>>
>> Yes Sergey, the test passes on Ubuntu with GTK L&F.
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~psadhukhan/pankaj/JDK-6857809-webrev.01/ 
>> <http://cr.openjdk.java.net/%7Epsadhukhan/pankaj/JDK-6857809-webrev.01/>
>>
>> Regards,
>>
>> Pankaj Bansal
>>
>> *From:*Semyon Sadetsky
>> *Sent:* Wednesday, September 20, 2017 10:43 PM
>> *To:* Pankaj Bansal; awt-dev at openjdk.java.net
>> *Subject:* Re: <AWT Dev> [10] Review Request: JDK-6857809 : [TEST_BUG] 
>> java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
>>
>> On 09/20/2017 09:21 AM, Pankaj Bansal wrote:
>>
>>     Hi Seymon,
>>
>>     I think the issue is because no size is set on frame. This is also
>>     the proposed fix in the bug description.
>>
>> This is good, but setting a fixed frame size forces the java Frame 
>> object to return that size only at the very beginning the real and 
>> final frame dimensions will be established? asynchronously by the 
>> native window subsystem.
>>
>>     Regards,
>>
>>     Pankaj
>>
>>     *From:*Semyon Sadetsky
>>     *Sent:* Wednesday, September 20, 2017 9:02 PM
>>     *To:* Pankaj Bansal; awt-dev at openjdk.java.net
>>     <mailto:awt-dev at openjdk.java.net>
>>     *Subject:* Re: <AWT Dev> [10] Review Request: JDK-6857809 :
>>     [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
>>
>>     Hi Pankaj,
>>
>>     The root cause of the issue is that the underling native window is
>>     not yet created when its with and height are requested. This is
>>     because windows are created asynchronously. The test should be
>>     fixed by adding Robot.waitForIdle() after frame.setVisible(true).
>>
>>     --Semyon
>>
>>     On 09/20/2017 05:49 AM, Pankaj Bansal wrote:
>>
>>         Hi All,
>>
>>         Please review the fix for test program test
>>         java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
>>         for JDK 10.
>>
>>         Bug:
>>
>>         https://bugs.openjdk.java.net/browse/JDK-6857809
>>
>>         Webrev:
>>
>>         http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/
>>         <http://cr.openjdk.java.net/%7Eaghaisas/pankaj/6857809/webrev.0/>
>>
>>         Issue:
>>
>>         The test
>>         ?java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
>>         fails on Linux intermittently due to
>>         ?java.lang.IllegalArgumentException: Width (0) and height (0)
>>         cannot be <= 0? exception.
>>
>>         Fix:
>>
>>         Made changes in
>>         java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to
>>         set the size of frame to make the test more stable.
>>
>>         Regards,
>>
>>         Pankaj Bansal
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep 21 21:02:19 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Sep 2017 14:02:19 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <c033d389-e602-47b1-9135-fc82e1ad0397@default>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
 <59BC6247.9020408@oracle.com>
 <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>
 <5afacc8a-2236-5955-ed5a-22bd05b378f8@oracle.com>
 <86e0f409-e5d5-666e-a85a-0019e759abdd@oracle.com>
 <fba0ab2f-5380-db32-6e13-5751d1ba37b1@oracle.com>
 <9bd32de3-af72-a911-2e70-029af10a099f@oracle.com>
 <18341159-32d7-ebb4-05da-a04224a4d2e7@oracle.com>
 <c033d389-e602-47b1-9135-fc82e1ad0397@default>
Message-ID: <1bd19067-a84d-46fe-6c05-c25e14c080d1@oracle.com>

+1

On 9/21/17 01:29, Pankaj Bansal wrote:
> Hi Sergey/Semyon,
> 
> I have updated the webrev according to your comments. Please review.
> Webrev:   http://cr.openjdk.java.net/~psadhukhan/pankaj/webrev/
> 
> Regards,
> Pankaj Bansal
> 
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Tuesday, September 19, 2017 8:40 PM
> To: Sergey Bylokhov; Pankaj Bansal; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
> 
> On 09/18/2017 11:04 AM, Sergey Bylokhov wrote:
> 
>> On 9/18/17 10:14, Semyon Sadetsky wrote:
>>>> It is fine because it tests the ComponentOrientation class which is
>>>> loaded from the resource bundle and applied to the window.
>>> I would agree with you if the resource bundle at least contained a
>>> value for the component orientation but it sets some specific locale
>>> codes. And java's locale functionality is not a subject of the
>>> client-libs, it is an another module. Also, as it was already pointed
>>> out, the method was deprecated long time ago.
>>
>> Where did you check these bundles? Because resource bundles for this
>> test contains the all variations of orientation
>> property(UNKNOWN/LEFT_TO_RIGHT/RIGHT_TO_LEFT/none).
> OK. I missed those bundle classes with the orientation properties. I think the test may either be left as it is, or moved to the i18n suite with adding a test to ComponentOrientation suite that tests
> applyComponentOrientation() directly.
>>
>>>>
>>>>>
>>>>>
>>>>> On 9/15/17 4:53 PM, Sergey Bylokhov wrote:
>>>>>> I guess you missed something, the possibility to configure the
>>>>>> components via ResourceBudnle or locale is something different
>>>>>> that the hardcore the orientation in the application. And the fact
>>>>>> that this test found the bug in jdk9 just show that the test is
>>>>>> valid.
>>>>>>
>>>>>> On 9/15/17 16:29, Semyon Sadetsky wrote:
>>>>>>> The component orientation test suite should use the right API,
>>>>>>> not the deprecated one. This was missed when the new API is created.
>>>>>>> So the change is valid from this point with the corresponding
>>>>>>> comment in JIRA.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>>>>>>>
>>>>>>>> On 9/14/17 23:15, Pankaj Bansal wrote:
>>>>>>>>> This test is not failing with JDK 9_181 and JDK10 as methods
>>>>>>>>> are deprecated not removed. It is giving lot of warning for
>>>>>>>>> using deprecated things, so I made these changes. I think the
>>>>>>>>> bug description should be changed to notify that.
>>>>>>>>
>>>>>>>> I am not sure that it is correct to replace one API to another
>>>>>>>> one. This test was written as part of i18n support and it checks
>>>>>>>> that our API can be configured by the ResourceBundles. The
>>>>>>>> updated test doing the different things - it checks that
>>>>>>>> getComponentOrientation will return the value which were set by
>>>>>>>> applyComponentOrientation().
>>>>>>>>
>>>>>>>> Since it was reported that the test failed because of some bug,
>>>>>>>> but looks like now it work as expected, this CR can be closed as
>>>>>>>> not reproducible. Or you can clean the test but without changing
>>>>>>>> its logic.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Pankaj Bansal
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Sergey Bylokhov
>>>>>>>>> Sent: Thursday, September 14, 2017 11:30 PM
>>>>>>>>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>>>>>>>>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 :
>>>>>>>>> [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
>>>>>>>>>
>>>>>>>>> Hi, Pankaj.
>>>>>>>>> Can you please clarify why this test fails on jdk9? This method
>>>>>>>>> is deprecated but it was not removed, so it should work.
>>>>>>>>> Probably at some point of jdk9 development it was broken?
>>>>>>>>>
>>>>>>>>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review the fix for test program
>>>>>>>>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>>>>>>>>
>>>>>>>>>> Bug:
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>>>>>>>>
>>>>>>>>>> Webrev:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>>>>>>>>
>>>>>>>>>> Issue:
>>>>>>>>>>
>>>>>>>>>> The test java/awt/ComponentOrientation/WindowTest.java uses
>>>>>>>>>> depreciated function  applyResourceBundle. So the test should
>>>>>>>>>> be updated to use applyComponentOrientation function.
>>>>>>>>>>
>>>>>>>>>> Fix:
>>>>>>>>>>
>>>>>>>>>> Made changes in java/awt/ComponentOrientation/WindowTest.java
>>>>>>>>>> to use
>>>>>>>>>> applyComponentOrientation function and did corresponding changes.
>>>>>>>>>> Along with that, the test is also using java.applet.Applet
>>>>>>>>>> which is also deprecated, so changed the test to use Frame
>>>>>>>>>> instead.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Pankaj Bansal
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards, Sergey.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Thu Sep 21 21:12:57 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 21 Sep 2017 14:12:57 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
Message-ID: <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>

On 09/21/2017 01:52 PM, Sergey Bylokhov wrote:

> On 9/21/17 08:54, Semyon Sadetsky wrote:
>> On 09/20/2017 02:41 PM, Sergey Bylokhov wrote:
>>
>>> Hi, Semyon
>>> I have some initial comments which are based on the two bugs: 
>>> JDK-8182043 and JDK-8156183.
>>>
>>> getSystemIcon(File file, int size):
>>>     - How the user will know what values/sizes should be passed, 
>>> what values are supported? It is unlikely that he will pass all 
>>> values in between 8-256?
>> Supported sizes are described in the method spec, aren't they?
>> This API doesn't imply any size limitation like the 8-256 you mentioned.
>
> Does it mean that all sizes will be supported(1-Integer.MAX_INT)? I 
> guess it is unlikely that the the explorer.exe will contains the icons 
> bigger than 1024.
This is a a cross-platform API, not a windows specific implementation.
>
>
>>>
>>> "For any positive size value the exact file icon size is queried":
>>>     - This should be double checked because our implementation can 
>>> return MultiResolutionIconImage if the system returns the icon which 
>>> size is different from requested.
>>>
>>> FILE_ICON_SMALL(FILE_ICON_LARGE);
>>>     - What these parameters mean? Is it the smallest(biggest) 
>>> supported size or is it a default size? Can it be different if 
>>> different dpi are used on the screen? For example 16(32) by default 
>>> and 32(64) on HiDPI?
>> They means what they have been meaning FileChooserUI implementation 
>> for the Windows L&F which operates by two fixed icon sizes, large and 
>> small.
>
> But it is not necessary will be used by our implementation of 
> FileChooserUI when this API became public. For example in the 
> description of JDK-8156183 the user said that large icons are used in 
> "a media file browser" and "32x32 isn't large by the standards of 
> current-millennium operating systems".
> But even in our FileChooserUI implementation shouldn't we use x2 icons 
> in case of HiDPI?
> FILE_ICON_SMALL - is it a smallest supported size?
User may use the new method to get icons at any resolution. Small/large 
sizes are preserved for backward compatibility, because before this 
change only those two sizes were available.
>
>
>>> FILE_ICON_SMALL:
>>>    - It seems that this value duplicate functionality of the old 
>>> getSystemIcon(File) method?
>> How this can be got from the spec? It may return the same size but 
>> not necessarily.
>
> Then how the old method and the new one are related? Will the old 
> method returns the size in between FILE_ICON_SMALL and FILE_ICON_LARGE?
I didn't get how it would be possible?
>
>>>
>>>
>>> Probably it will be better to provide to the user the 
>>> set(list/mri/array/etc) of supported images, or if it is really slow 
>>> the set(list/mri/array/etc) of supported sizes, and the user will be 
>>> able to pass some meaningful sizes.
>> This is not a good idea. Extracting all available icon resolutions 
>> might take significant time and since icons are cached it would be 
>> waste of RAM.
>
> It should be measured, we can try to load them lazy, or provide the 
> list of sizes which are supported.
Sorry, I didn't get what are you proposing to measure? And how do you 
propose to get the icon size without reading the image?
>
>>>
>>>
>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>
>>>> The fix  opens the part of the ShellFolder API for getting system 
>>>> icons which was decided to be left closed during the 8081722 
>>>> enhancement review in 9.
>>>>
>>>> Also the fix extends the API by adding possibility to query file 
>>>> icons of arbitrary size and implements this extension for Windows 
>>>> platform.
>>>>
>>>> --Semyon
>>>>
>>>
>>>
>>
>
>


From semyon.sadetsky at oracle.com  Thu Sep 21 21:14:00 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 21 Sep 2017 14:14:00 -0700
Subject: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG]
 java/awt/ComponentOrientation/WindowTest.java
In-Reply-To: <1bd19067-a84d-46fe-6c05-c25e14c080d1@oracle.com>
References: <c6231728-9548-4e13-b46b-f3c6309b9701@default>
 <fc71d2ce-4f51-1b4b-3d54-178256af06ca@oracle.com>
 <3f1989ee-db99-477c-af19-6a9a90b4b3f9@default>
 <02337570-01e0-9d22-8ba4-a21ec046e9c0@oracle.com>
 <59BC6247.9020408@oracle.com>
 <6c29109c-3948-eea5-e673-49693b1ea4e1@oracle.com>
 <5afacc8a-2236-5955-ed5a-22bd05b378f8@oracle.com>
 <86e0f409-e5d5-666e-a85a-0019e759abdd@oracle.com>
 <fba0ab2f-5380-db32-6e13-5751d1ba37b1@oracle.com>
 <9bd32de3-af72-a911-2e70-029af10a099f@oracle.com>
 <18341159-32d7-ebb4-05da-a04224a4d2e7@oracle.com>
 <c033d389-e602-47b1-9135-fc82e1ad0397@default>
 <1bd19067-a84d-46fe-6c05-c25e14c080d1@oracle.com>
Message-ID: <0477621b-ddcc-0444-30f9-abdbc2b9dddb@oracle.com>

+1


On 09/21/2017 02:02 PM, Sergey Bylokhov wrote:
> +1
>
> On 9/21/17 01:29, Pankaj Bansal wrote:
>> Hi Sergey/Semyon,
>>
>> I have updated the webrev according to your comments. Please review.
>> Webrev:   http://cr.openjdk.java.net/~psadhukhan/pankaj/webrev/
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Tuesday, September 19, 2017 8:40 PM
>> To: Sergey Bylokhov; Pankaj Bansal; awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 : [TEST_BUG] 
>> java/awt/ComponentOrientation/WindowTest.java
>>
>> On 09/18/2017 11:04 AM, Sergey Bylokhov wrote:
>>
>>> On 9/18/17 10:14, Semyon Sadetsky wrote:
>>>>> It is fine because it tests the ComponentOrientation class which is
>>>>> loaded from the resource bundle and applied to the window.
>>>> I would agree with you if the resource bundle at least contained a
>>>> value for the component orientation but it sets some specific locale
>>>> codes. And java's locale functionality is not a subject of the
>>>> client-libs, it is an another module. Also, as it was already pointed
>>>> out, the method was deprecated long time ago.
>>>
>>> Where did you check these bundles? Because resource bundles for this
>>> test contains the all variations of orientation
>>> property(UNKNOWN/LEFT_TO_RIGHT/RIGHT_TO_LEFT/none).
>> OK. I missed those bundle classes with the orientation properties. I 
>> think the test may either be left as it is, or moved to the i18n 
>> suite with adding a test to ComponentOrientation suite that tests
>> applyComponentOrientation() directly.
>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/15/17 4:53 PM, Sergey Bylokhov wrote:
>>>>>>> I guess you missed something, the possibility to configure the
>>>>>>> components via ResourceBudnle or locale is something different
>>>>>>> that the hardcore the orientation in the application. And the fact
>>>>>>> that this test found the bug in jdk9 just show that the test is
>>>>>>> valid.
>>>>>>>
>>>>>>> On 9/15/17 16:29, Semyon Sadetsky wrote:
>>>>>>>> The component orientation test suite should use the right API,
>>>>>>>> not the deprecated one. This was missed when the new API is 
>>>>>>>> created.
>>>>>>>> So the change is valid from this point with the corresponding
>>>>>>>> comment in JIRA.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>>>>>>>>
>>>>>>>>> On 9/14/17 23:15, Pankaj Bansal wrote:
>>>>>>>>>> This test is not failing with JDK 9_181 and JDK10 as methods
>>>>>>>>>> are deprecated not removed. It is giving lot of warning for
>>>>>>>>>> using deprecated things, so I made these changes. I think the
>>>>>>>>>> bug description should be changed to notify that.
>>>>>>>>>
>>>>>>>>> I am not sure that it is correct to replace one API to another
>>>>>>>>> one. This test was written as part of i18n support and it checks
>>>>>>>>> that our API can be configured by the ResourceBundles. The
>>>>>>>>> updated test doing the different things - it checks that
>>>>>>>>> getComponentOrientation will return the value which were set by
>>>>>>>>> applyComponentOrientation().
>>>>>>>>>
>>>>>>>>> Since it was reported that the test failed because of some bug,
>>>>>>>>> but looks like now it work as expected, this CR can be closed as
>>>>>>>>> not reproducible. Or you can clean the test but without changing
>>>>>>>>> its logic.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Pankaj Bansal
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Sergey Bylokhov
>>>>>>>>>> Sent: Thursday, September 14, 2017 11:30 PM
>>>>>>>>>> To: Pankaj Bansal; awt-dev at openjdk.java.net
>>>>>>>>>> Subject: Re: <AWT Dev> [10] Review Request: JDK-8081311 :
>>>>>>>>>> [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java
>>>>>>>>>>
>>>>>>>>>> Hi, Pankaj.
>>>>>>>>>> Can you please clarify why this test fails on jdk9? This method
>>>>>>>>>> is deprecated but it was not removed, so it should work.
>>>>>>>>>> Probably at some point of jdk9 development it was broken?
>>>>>>>>>>
>>>>>>>>>> On 9/14/17 03:25, Pankaj Bansal wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Please review the fix for test program
>>>>>>>>>>> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>>>>>>>>>>>
>>>>>>>>>>> Bug:
>>>>>>>>>>>
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081311
>>>>>>>>>>>
>>>>>>>>>>> Webrev:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>>>>>>>>>>>
>>>>>>>>>>> Issue:
>>>>>>>>>>>
>>>>>>>>>>> The test java/awt/ComponentOrientation/WindowTest.java uses
>>>>>>>>>>> depreciated function  applyResourceBundle. So the test should
>>>>>>>>>>> be updated to use applyComponentOrientation function.
>>>>>>>>>>>
>>>>>>>>>>> Fix:
>>>>>>>>>>>
>>>>>>>>>>> Made changes in java/awt/ComponentOrientation/WindowTest.java
>>>>>>>>>>> to use
>>>>>>>>>>> applyComponentOrientation function and did corresponding 
>>>>>>>>>>> changes.
>>>>>>>>>>> Along with that, the test is also using java.applet.Applet
>>>>>>>>>>> which is also deprecated, so changed the test to use Frame
>>>>>>>>>>> instead.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Pankaj Bansal
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From anton.litvinov at oracle.com  Fri Sep 22 00:39:55 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Fri, 22 Sep 2017 01:39:55 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch
 keyboard is not shown for text components on a screen touch
In-Reply-To: <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
 <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
 <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
Message-ID: <6f3177ec-2915-0004-bbd2-11232e2338c6@oracle.com>

Hello Sergey,

Thank you very much for review of this fix. The second version of the 
fix with minor changes in 3 places which address your remarks is 
created. The new fix version applied to the today's version of the 
consolidated repository "jdk10/client" was verified in my local 
environment successfully. Could you please look at the new version of 
the fix.

Webrev (the 2nd version): 
http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.01

The 2nd version of the fix contains the next changes:
1.  "SunToolkit.java" file - Now "true" is used as the default value for 
the system property "awt.touchKeyboardAutoShowIsEnable".
2.  The 1st version of the fix was not thread-safe, only in case, when 
more than 1 EDT could exist in the process, in 2 places: "WToolkit.java" 
file (access to the fields "compOnTouchDownEvent", 
"compOnMousePressedEvent"), "awt_Toolkit.cpp" file (deletion and 
assignment of "NULL" to the field "m_touchKbrdExeFilePath" in the method 
"ShowTouchKeyboard()").
     - "WToolkit.java" - The modifier "volatile" was added to the fields 
"compOnTouchDownEvent", "compOnMousePressedEvent".
     - "awt_Toolkit.cpp" - Code deleting and assigning NULL to 
"m_touchKbrdExeFilePath" in the method "ShowTouchKeyboard()" was 
substituted for the code which outputs into the trace message in case, 
if launching the touch keyboard system application fails.

Could you please answer my question.
- Should CCC request be filed for the new system property 
"awt.touchKeyboardAutoShowIsEnable", whose value is considered as "true" 
by default, if it is not specified by the user explicitly while 
launching a Java application?

Thank you,
Anton

On 05/09/2017 18:15, Sergey Bylokhov wrote:
> Hi, Anton.
> The fix looks good.
>  - But can you please recheck that is is not necessary to use 
> additional synchronization in showOrHideTouchKeyboard() if a few EDT 
> will be used.
>  - I suggest to invert the awt.touchKeyboardAutoShowIsEnabled and use 
> true as default value, we will have more coverage and feedback in this 
> case. This property will be used as a workaround if some bugs will be 
> found.
>
> On 8/30/17 11:51, Anton Litvinov wrote:
>> Hello dear reviewers,
>>
>> Could anybody please look at this review request?
>>
>> Thank you,
>> Anton
>>
>> On 17/08/2017 13:20, Anton Litvinov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix for the bug.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166772
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00
>>>
>>> The bug is the fact that, when a user touches any Swing or AWT text 
>>> component, for example "JTextField", "JTextArea", "TextField", 
>>> "TextArea", by means of a touch screen on a host with MS Windows 
>>> 10/8.1/8 OS, the system touch keyboard is not shown automatically. 
>>> Please find a detailed description of the bug, screenshots depicting 
>>> the touch keyboard and a compilable test case with Swing/AWT text 
>>> components in JBS bug record. Also a summary of the done research of 
>>> the issue with a description of identified approaches for its 
>>> resolution are reported in my last comment in the bug record.
>>>
>>> THE FIX:
>>> On a very abstract level the fix functioning can be presented by the 
>>> next 3 stages:
>>>
>>> Stage 1.
>>> The fix adds support of "WM_TOUCH" system window messages to AWT 
>>> native peer windows through C++ class "AwtComponent". It "processes" 
>>> "WM_TOUCH" message and marks "java.awt.event.MouseEvent", which is 
>>> created as a result of handling of the further coming 
>>> "WM_LBUTTONDOWN", "WM_LBUTTONUP" messages sent by the system in 
>>> substitution for this "WM_TOUCH" message, by the new private field 
>>> flag "MouseEvent.causedByTouchEvent".
>>>
>>> Stage 2.
>>> Then on Java level the fix handles "MouseEvent", "FocusEvent" 
>>> received only by the instances of "java.awt.TextComponent", 
>>> "javax.swing.text.TextComponent" in 
>>> "WToolkit.showOrHideTouchKeyboard()" called from 
>>> "Component.dispatchEventImpl()" and shows or hides the touch 
>>> keyboard on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" 
>>> events by calling corresponding native methods of "WToolkit" class.
>>>
>>> Stage 3.
>>> Showing of the touch keyboard is implemented in C++ class 
>>> "AwtToolkit" and is done by launching the system application 
>>> "TabTip.exe" which implements the system touch keyboard. This 
>>> approach is described in the bug record.
>>>
>>> FEATURES OF THE FIX:
>>> 1. By default all native and Java parts of the fix do not function 
>>> at all - the fix is disabled. To enable the fix the application 
>>> should be run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" 
>>> option. Handling of this new property is implemented in 
>>> "sun.awt.SunToolkit" class.
>>>
>>> 2. Native parts of the fix functions only on MS Window 8 or later.
>>>
>>> 3. The fix implements automatic showing of the touch keyboard for 
>>> the following 2 use cases:
>>>     a.  The user touches the text components using the touch screen.
>>>     b.  The user does mouse clicks on the text components, while no 
>>> any keyboard is attached to the host.
>>>
>>> FIX LOGICAL STRUCTURE BY SOURCE CODE:
>>> 1. Core of the fix:
>>>     Native code:  awt_Toolkit.[h/cpp], awt_Component.[h/cpp], 
>>> awt_MouseEvent.[h/cpp], awt.h
>>>     Java:  SunToolkit.java, WToolkit.java, Component.java, 
>>> MouseEvent.java, AWTAccessor.java
>>>
>>> 2. Changes in all remaining Java files are connected with retaining 
>>> of the flag value "MouseEvent.causedByTouchEvent" during creation of 
>>> the new instances of "MouseEvent" class based on the original 
>>> "MouseEvent" instances.
>>>
>>> Work of the fix was verified both in the environment with the real 
>>> touch screen device and in the environment with the emulated touch 
>>> screen.
>>>
>>> Thank you,
>>> Anton
>>
>
>


From Sergey.Bylokhov at oracle.com  Fri Sep 22 03:17:36 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Sep 2017 20:17:36 -0700
Subject: <AWT Dev> [10] Review request for 8186495: Some closed SQE
 tests fail after frame dispose() on Linux
In-Reply-To: <3002d4e7-635c-16bf-47ed-50015be5b37c@oracle.com>
References: <17cf11a6-8eb3-78e8-4550-9014fb46323b@oracle.com>
 <039d8c3b-a4b2-7118-bc34-18f5dd59c9a3@oracle.com>
 <c65799fd-d6c4-2b8f-1dd1-d6c961c179b1@oracle.com>
 <4d3ae69d-7683-9945-a031-35825068f3b3@oracle.com>
 <0d43afe4-2815-4f56-1d77-c51407fa76f1@oracle.com>
 <3f47f95c-de47-c219-5c8f-a04074197923@oracle.com>
 <bdcaa9ce-9781-105d-64e8-1f67ce38f316@oracle.com>
 <28e93e42-2993-2394-0669-cd54747d5925@oracle.com>
 <59B9B2FB.7050503@oracle.com>
 <5613bc79-21d8-620b-a864-9685dcc805cd@oracle.com>
 <3002d4e7-635c-16bf-47ed-50015be5b37c@oracle.com>
Message-ID: <d5916978-fd62-e544-51b6-cc21accdd17b@oracle.com>

On 9/21/17 08:57, Semyon Sadetsky wrote:
> On 09/13/2017 03:42 PM, Sergey Bylokhov wrote:
> 
>> On 9/13/17 15:36, Semyon Sadetsky wrote:
>>>> The problem in the fix is that the new checks do not try to be 
>>>> thread safe.
>>> So, what do you propose? Add a volatile field "disposing" and do noop 
>>> if it is true?
>>
>> I have added a links to the bug which contain an examples, of how it 
>> was implemented in other cases.
> I did not get which links do you mean. Can you be more specific about 
> the solution you are proposing?

I added a links to two bugs in the comment, my proposal is to do 
something similar to a fixes for those bugs.

>>
>>>
>>>>
>>>>>
>>>>> --Semyon
>>>>>>
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>>
>>>>>>> On 09/13/2017 11:55 AM, Sergey Bylokhov wrote:
>>>>>>>> On 9/13/17 11:49, Semyon Sadetsky wrote:
>>>>>>>>> The tests passes after the fix for me. Which situations do you 
>>>>>>>>> mean? Can you provide examples?
>>>>>>>>
>>>>>>>> For example in XFramePeer.setVisible() it is possible that the 
>>>>>>>> peer became disposed after the new check.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:
>>>>>>>>>> Hi, Semyon.
>>>>>>>>>> Did you check why the bug is not reproduced on jdk8?
>>>>>>>>>> I guess that it is still possible to get a situations below 
>>>>>>>>>> because of absent synchronization on all paths of usage 
>>>>>>>>>> "window",isDispose() and dispose() method:
>>>>>>>>>> ?- check isDispose().
>>>>>>>>>> ?- dispose the peer
>>>>>>>>>> ?- use the long value which was disposed step above
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/8/17 20:00, Semyon Sadetsky wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review fix for JDK10:
>>>>>>>>>>>
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8186495
>>>>>>>>>>>
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> After toolkit window is destroyed methods invocations on the 
>>>>>>>>>>> window component may cause exceptions because of wrong native 
>>>>>>>>>>> xwindow ID. The fix introduces checks in the X* peers to 
>>>>>>>>>>> ensure that window ID is actual otherwise do nothing.
>>>>>>>>>>>
>>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Sep 22 03:21:39 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Sep 2017 20:21:39 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
Message-ID: <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>

On 9/21/17 14:12, Semyon Sadetsky wrote:
> On 09/21/2017 01:52 PM, Sergey Bylokhov wrote:
> 
>> On 9/21/17 08:54, Semyon Sadetsky wrote:
>>> On 09/20/2017 02:41 PM, Sergey Bylokhov wrote:
>>>
>>>> Hi, Semyon
>>>> I have some initial comments which are based on the two bugs: 
>>>> JDK-8182043 and JDK-8156183.
>>>>
>>>> getSystemIcon(File file, int size):
>>>> ??? - How the user will know what values/sizes should be passed, 
>>>> what values are supported? It is unlikely that he will pass all 
>>>> values in between 8-256?
>>> Supported sizes are described in the method spec, aren't they?
>>> This API doesn't imply any size limitation like the 8-256 you mentioned.
>>
>> Does it mean that all sizes will be supported(1-Integer.MAX_INT)? I 
>> guess it is unlikely that the the explorer.exe will contains the icons 
>> bigger than 1024.
> This is a a cross-platform API, not a windows specific implementation.

This was an example, and the question was how the user will know what 
icons are supported by some specific file.

>>
>>
>>>>
>>>> "For any positive size value the exact file icon size is queried":
>>>> ??? - This should be double checked because our implementation can 
>>>> return MultiResolutionIconImage if the system returns the icon which 
>>>> size is different from requested.
>>>>
>>>> FILE_ICON_SMALL(FILE_ICON_LARGE);
>>>> ??? - What these parameters mean? Is it the smallest(biggest) 
>>>> supported size or is it a default size? Can it be different if 
>>>> different dpi are used on the screen? For example 16(32) by default 
>>>> and 32(64) on HiDPI?
>>> They means what they have been meaning FileChooserUI implementation 
>>> for the Windows L&F which operates by two fixed icon sizes, large and 
>>> small.
>>
>> But it is not necessary will be used by our implementation of 
>> FileChooserUI when this API became public. For example in the 
>> description of JDK-8156183 the user said that large icons are used in 
>> "a media file browser" and "32x32 isn't large by the standards of 
>> current-millennium operating systems".
>> But even in our FileChooserUI implementation shouldn't we use x2 icons 
>> in case of HiDPI?
>> FILE_ICON_SMALL - is it a smallest supported size?
> User may use the new method to get icons at any resolution. Small/large 
> sizes are preserved for backward compatibility, because before this 
> change only those two sizes were available.

Backward compatibility to what? There was know public API for this.
It is still unclear what is a "the small or large file icon variant" means.

>>
>>
>>>> FILE_ICON_SMALL:
>>>> ?? - It seems that this value duplicate functionality of the old 
>>>> getSystemIcon(File) method?
>>> How this can be got from the spec? It may return the same size but 
>>> not necessarily.
>>
>> Then how the old method and the new one are related? Will the old 
>> method returns the size in between FILE_ICON_SMALL and FILE_ICON_LARGE?
> I didn't get how it would be possible?

Possible what? It is unclear how the two methods are related to each other.

>>
>>>>
>>>>
>>>> Probably it will be better to provide to the user the 
>>>> set(list/mri/array/etc) of supported images, or if it is really slow 
>>>> the set(list/mri/array/etc) of supported sizes, and the user will be 
>>>> able to pass some meaningful sizes.
>>> This is not a good idea. Extracting all available icon resolutions 
>>> might take significant time and since icons are cached it would be 
>>> waste of RAM.
>>
>> It should be measured, we can try to load them lazy, or provide the 
>> list of sizes which are supported.
> Sorry, I didn't get what are you proposing to measure? And how do you 
> propose to get the icon size without reading the image?
>>
>>>>
>>>>
>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>
>>>>> The fix? opens the part of the ShellFolder API for getting system 
>>>>> icons which was decided to be left closed during the 8081722 
>>>>> enhancement review in 9.
>>>>>
>>>>> Also the fix extends the API by adding possibility to query file 
>>>>> icons of arbitrary size and implements this extension for Windows 
>>>>> platform.
>>>>>
>>>>> --Semyon
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From alexander.zvegintsev at oracle.com  Fri Sep 22 05:56:04 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 22 Sep 2017 11:26:04 +0530
Subject: <AWT Dev> [10] Review request for 8185634,
 8185634: Java Fx-Swing dialogs appearing behind main stage
In-Reply-To: <c10968d7-af0b-d599-6620-dd95e4d7af12@oracle.com>
References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com>
 <c10968d7-af0b-d599-6620-dd95e4d7af12@oracle.com>
Message-ID: <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>

Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
<https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart of 
this issue.

Thanks,
Alexander.

On 21/09/2017 22:25, Phil Race wrote:
> Some procedural comments :
> Since 90% of this is in AWT code, I'd have thought awt-dev should be 
> included here.
> I've added that list.
>
> And apart from needing separate bug ids, I don't see why the bug below 
> is confidential.
>
>
> I agree with what Kevin pointed out off-line that as in the dialog 
> case, the FX side
> of the code can use reflection and simply be a harmless non-functional 
> no-op
> if the SwingAccessor does not provide the new method.
>
> BTW
> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
> should be "dd" not "d".
>
> -phil.
>
> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8185634
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170922/bd799946/attachment.html>

From alexey.ivanov at oracle.com  Fri Sep 22 11:22:07 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 22 Sep 2017 12:22:07 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
Message-ID: <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>

Hi Sergey,

On 22/09/2017 04:21, Sergey Bylokhov wrote:
> On 9/21/17 14:12, Semyon Sadetsky wrote:
>> On 09/21/2017 01:52 PM, Sergey Bylokhov wrote:
>>
>>> On 9/21/17 08:54, Semyon Sadetsky wrote:
>>>> On 09/20/2017 02:41 PM, Sergey Bylokhov wrote:
>>>>
>>>>> Hi, Semyon
>>>>> I have some initial comments which are based on the two bugs: 
>>>>> JDK-8182043 and JDK-8156183.
>>>>>
>>>>> getSystemIcon(File file, int size):
>>>>> ??? - How the user will know what values/sizes should be passed, 
>>>>> what values are supported? It is unlikely that he will pass all 
>>>>> values in between 8-256?
>>>> Supported sizes are described in the method spec, aren't they?
>>>> This API doesn't imply any size limitation like the 8-256 you 
>>>> mentioned.
>>>
>>> Does it mean that all sizes will be supported(1-Integer.MAX_INT)? I 
>>> guess it is unlikely that the the explorer.exe will contains the 
>>> icons bigger than 1024.
>> This is a a cross-platform API, not a windows specific implementation.
>
> This was an example, and the question was how the user will know what 
> icons are supported by some specific file.

There's no way of knowing in advance.
Explorer does not restrict the size of icons (now), it's up to 
developers of a particular file handler to provide icons. Usually, 
there's only one icon with size larger than 255.

If there's the icon of the requested size, Explorer will give it to you, 
otherwise it will scale the closest available to the requested size.

Windows documentation suggests the following sizes:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn742485(v=vs.85).aspx#size_requirements


As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using Windows 
API to retrieve the recommended size for small and large icon size 
rather than defaulting to 16?16 and 32?32. If HiDPI is in effect, the 
icons must be larger.


Regards,
Alexey

>
>
>>>
>>>
>>>>>
>>>>> "For any positive size value the exact file icon size is queried":
>>>>> ??? - This should be double checked because our implementation can 
>>>>> return MultiResolutionIconImage if the system returns the icon 
>>>>> which size is different from requested.
>>>>>
>>>>> FILE_ICON_SMALL(FILE_ICON_LARGE);
>>>>> ??? - What these parameters mean? Is it the smallest(biggest) 
>>>>> supported size or is it a default size? Can it be different if 
>>>>> different dpi are used on the screen? For example 16(32) by 
>>>>> default and 32(64) on HiDPI?
>>>> They means what they have been meaning FileChooserUI implementation 
>>>> for the Windows L&F which operates by two fixed icon sizes, large 
>>>> and small.
>>>
>>> But it is not necessary will be used by our implementation of 
>>> FileChooserUI when this API became public. For example in the 
>>> description of JDK-8156183 the user said that large icons are used 
>>> in "a media file browser" and "32x32 isn't large by the standards of 
>>> current-millennium operating systems".
>>> But even in our FileChooserUI implementation shouldn't we use x2 
>>> icons in case of HiDPI?
>>> FILE_ICON_SMALL - is it a smallest supported size?
>> User may use the new method to get icons at any resolution. 
>> Small/large sizes are preserved for backward compatibility, because 
>> before this change only those two sizes were available.
>
> Backward compatibility to what? There was know public API for this.
> It is still unclear what is a "the small or large file icon variant" 
> means.
>
>>>
>>>
>>>>> FILE_ICON_SMALL:
>>>>> ?? - It seems that this value duplicate functionality of the old 
>>>>> getSystemIcon(File) method?
>>>> How this can be got from the spec? It may return the same size but 
>>>> not necessarily.
>>>
>>> Then how the old method and the new one are related? Will the old 
>>> method returns the size in between FILE_ICON_SMALL and FILE_ICON_LARGE?
>> I didn't get how it would be possible?
>
> Possible what? It is unclear how the two methods are related to each 
> other.
>
>>>
>>>>>
>>>>>
>>>>> Probably it will be better to provide to the user the 
>>>>> set(list/mri/array/etc) of supported images, or if it is really 
>>>>> slow the set(list/mri/array/etc) of supported sizes, and the user 
>>>>> will be able to pass some meaningful sizes.
>>>> This is not a good idea. Extracting all available icon resolutions 
>>>> might take significant time and since icons are cached it would be 
>>>> waste of RAM.
>>>
>>> It should be measured, we can try to load them lazy, or provide the 
>>> list of sizes which are supported.
>> Sorry, I didn't get what are you proposing to measure? And how do you 
>> propose to get the icon size without reading the image?
>>>
>>>>>
>>>>>
>>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>>
>>>>>> The fix? opens the part of the ShellFolder API for getting system 
>>>>>> icons which was decided to be left closed during the 8081722 
>>>>>> enhancement review in 9.
>>>>>>
>>>>>> Also the fix extends the API by adding possibility to query file 
>>>>>> icons of arbitrary size and implements this extension for Windows 
>>>>>> platform.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From alexey.ivanov at oracle.com  Fri Sep 22 11:49:12 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 22 Sep 2017 12:49:12 +0100
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
Message-ID: <ccff0734-1ed5-8c88-d558-1b41a31a3477@oracle.com>

Hi Shashi,

You use EnableMouseInPointer which converts classical WM_MOUSE events to 
WM_POINTER events. This could have substantial effect on AWT components 
behaviour. I am worried about High DPI support, drag-and-drop 
functionality etc.

Is there a simpler way to handle double-tap?
Windows converts taps to clicks, i.e. the app receives WM_LBUTTONDOWN 
and WM_LBUTTONUP.
Have you tried to find out why double-tap is not converted to double-click?

Do right and middle mouse buttons continue to work as expected? Mouse 
wheel? Any additional mouse buttons?


The documentation for EnableMouseInPointer [1] says: ?This function can 
be called only once in the context of a process lifetime.? You call it 
for every component created. It would have been enough to call it once 
during Toolkit initialization.


Regards,
Alexey

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/hh447467(v=vs.85).aspx

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 19, 2017 3:39 AM
> To:shashidhara.veerabhadraiah at oracle.com  >> Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
> Cc:awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface
>
> Hi, Shashi.
> Why the bug is JFileChooser specific?
> Does it means that it works for other elements(buttons/lists/menu/etc)?
>
> On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review this software changes for the /_enhancement_/
>> JDK-8178361.
>>
>> Issue: Request was filed to enable the touch event processing for Java
>> client applications.
>>
>> Fix: Windows platform offers 'pointer' implementation thro' which one
>> can tap for the touch inputs as well. A typical 'pointer' function may
>> contain touch, pen, touch pad or mouse inputs. This allows for a
>> uniform input processing though the event source may defer. This fix
>> enables the 'touch' events(via TOUCH pointer) to be passed to the
>> components using the other type of pointer 'mouse'. Essentially there
>> is a conversion put in place to convert a touch event input into a
>> left click mouse event. I think this is the right thing to do
>> considering desktop scenarios to which the typical Java applications
>> that gets exposed to. This is also the same behavior on my touch
>> enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
>>
>> Now touch event works as a typical mouse left click as in general. But
>> there is an issue because the icon size of the Java UI is typically
>> small, touching that icon exactly is sometimes difficult. This is
>> handled by an Windows application by having larger icon size or icon
>> view as a standard. Hence I believe this is outside the scope this
>> software update. Any changes to it would be done later as a new bug or
>> an enhancement.
>>
>> Bug ID:https://bugs.openjdk.java.net/browse/JDK-8178361
>>
>> Webrev:http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
>>
>> Thanks and regards,
>>
>> Shashi
>>
> --
> Best regards, Sergey.

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

From alexey.ivanov at oracle.com  Fri Sep 22 11:56:07 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 22 Sep 2017 12:56:07 +0100
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
Message-ID: <957ee779-9a2e-daee-636a-79e8c9522ca3@oracle.com>

Hi Shashi,

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.

I cannot grasp the meaning of this sentence.

What are touch click events?
What are mouse focus events?

So the fix is not JFileChooser-specific, is it?

Regards,
Alexey

>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 19, 2017 3:39 AM
> To: shashidhara.veerabhadraiah at oracle.com >> Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface
>
> Hi, Shashi.
> Why the bug is JFileChooser specific?
> Does it means that it works for other elements(buttons/lists/menu/etc)?
>
> On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review this software changes for the /_enhancement_/
>> JDK-8178361.
>>
>> Issue: Request was filed to enable the touch event processing for Java
>> client applications.
>>
>> Fix: Windows platform offers 'pointer' implementation thro' which one
>> can tap for the touch inputs as well. A typical 'pointer' function may
>> contain touch, pen, touch pad or mouse inputs. This allows for a
>> uniform input processing though the event source may defer. This fix
>> enables the 'touch' events(via TOUCH pointer) to be passed to the
>> components using the other type of pointer 'mouse'. Essentially there
>> is a conversion put in place to convert a touch event input into a
>> left click mouse event. I think this is the right thing to do
>> considering desktop scenarios to which the typical Java applications
>> that gets exposed to. This is also the same behavior on my touch
>> enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
>>
>> Now touch event works as a typical mouse left click as in general. But
>> there is an issue because the icon size of the Java UI is typically
>> small, touching that icon exactly is sometimes difficult. This is
>> handled by an Windows application by having larger icon size or icon
>> view as a standard. Hence I believe this is outside the scope this
>> software update. Any changes to it would be done later as a new bug or
>> an enhancement.
>>
>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361
>>
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
>>
>> Thanks and regards,
>>
>> Shashi
>>
>
> --
> Best regards, Sergey.


From dmitry.markov at oracle.com  Fri Sep 22 12:10:02 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Fri, 22 Sep 2017 13:10:02 +0100
Subject: <AWT Dev> [10] Review Request: 8186559 [macos] the screen
 location is wrong when using AWT/SWT bridge with dual monitors
In-Reply-To: <e03bf1c0-197f-d4df-2d20-9b0f37390382@oracle.com>
References: <a571cf64-a561-3b32-216d-4c9a1608e928@oracle.com>
 <59BBF7E5.9080104@oracle.com>
 <bb76785c-956e-901c-7409-ff027be7ffb5@oracle.com>
 <825df34b-0e03-5dc8-7d88-93746af34f34@oracle.com>
 <e03bf1c0-197f-d4df-2d20-9b0f37390382@oracle.com>
Message-ID: <02E1496B-6499-41FA-BFD7-4B0A4F408109@oracle.com>

Hi Sergey,

The fix still looks good for me.

Thanks,
Dmitry
> On 18 Sep 2017, at 23:04, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> On 9/18/17 09:53, Semyon Sadetsky wrote:
>> On 09/15/2017 02:29 PM, Sergey Bylokhov wrote:
>>> It is broken from the moment when it was implemented(I have rechecked on 8u121 which was mentioned in the report), unlike Apple jdk where it worked.
>> Then probably the regression label need to be removed from the bug?
> 
> The labels is removed.
> 
>> Should the main screen also fixed in other places, for example, in CTrayIcon.m line 137 ?
> 
> Yes, it can be changed as well:
> http://cr.openjdk.java.net/~serb/8186559/webrev.01 <http://cr.openjdk.java.net/~serb/8186559/webrev.01>
> 
> but unfortunately it will not work properly even after this,
> the new issues created https://bugs.openjdk.java.net/browse/JDK-8187639 <https://bugs.openjdk.java.net/browse/JDK-8187639>
> 
> The last usage in getTopmostWindowUnderMouseIDImpl seems correct.
> 
>>> 
>>> On 9/15/17 08:55, Semyon Sadetsky wrote:
>>>> Hi Sergey,
>>>> 
>>>> what was caused the regression?
>>>> 
>>>> --Semyon
>>>> 
>>>> On 9/14/2017 3:46 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk10.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8186559
>>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8186559/webrev.00
>>>>> 
>>>>> When our NSView is embedded in native to the SWT-based NSWindow we incorrectly fetch the location of the NSView. The reason is that we use wrong screen when we flip the location. Currently we use [mainScreen] - which "returns the screen object containing the window with the keyboard focus", but we need the first screen which contains 0,0 coordinates.
>>>>> 
>>>>> In the fix the utility method is reused which internally uses
>>>>> [[NSScreen screens] objectAtIndex:0]
>>>>> 
>>>> 
>>> 
>>> 
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170922/b1ea14ba/attachment.html>

From semyon.sadetsky at oracle.com  Fri Sep 22 16:13:18 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 22 Sep 2017 09:13:18 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
Message-ID: <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>

Hi Alexey,

Thank you for your exact clarification.

On 09/22/2017 04:22 AM, Alexey Ivanov wrote:
> Hi Sergey,
>
> On 22/09/2017 04:21, Sergey Bylokhov wrote:
>> On 9/21/17 14:12, Semyon Sadetsky wrote:
>>> On 09/21/2017 01:52 PM, Sergey Bylokhov wrote:
>>>
>>>> On 9/21/17 08:54, Semyon Sadetsky wrote:
>>>>> On 09/20/2017 02:41 PM, Sergey Bylokhov wrote:
>>>>>
>>>>>> Hi, Semyon
>>>>>> I have some initial comments which are based on the two bugs: 
>>>>>> JDK-8182043 and JDK-8156183.
>>>>>>
>>>>>> getSystemIcon(File file, int size):
>>>>>>     - How the user will know what values/sizes should be passed, 
>>>>>> what values are supported? It is unlikely that he will pass all 
>>>>>> values in between 8-256?
>>>>> Supported sizes are described in the method spec, aren't they?
>>>>> This API doesn't imply any size limitation like the 8-256 you 
>>>>> mentioned.
>>>>
>>>> Does it mean that all sizes will be supported(1-Integer.MAX_INT)? I 
>>>> guess it is unlikely that the the explorer.exe will contains the 
>>>> icons bigger than 1024.
>>> This is a a cross-platform API, not a windows specific implementation.
>>
>> This was an example, and the question was how the user will know what 
>> icons are supported by some specific file.
>
> There's no way of knowing in advance.
> Explorer does not restrict the size of icons (now), it's up to 
> developers of a particular file handler to provide icons. Usually, 
> there's only one icon with size larger than 255.
>
> If there's the icon of the requested size, Explorer will give it to 
> you, otherwise it will scale the closest available to the requested size.
This I think a general approach for all platforms. Since the icons size 
may be set to arbitrarily value in the shell the shell should have a way 
to scale to it.

>
> Windows documentation suggests the following sizes:
> https://msdn.microsoft.com/en-us/library/windows/desktop/dn742485(v=vs.85).aspx#size_requirements 
>
>
>
> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using Windows 
> API to retrieve the recommended size for small and large icon size 
> rather than defaulting to 16?16 and 32?32. If HiDPI is in effect, the 
> icons must be larger.
I also found this as most suitable approach for the moment.
Later this may be changed, for example, if Swing JFC is re-factored to 
support shell determined icon sizes at HiDPI.

--Semyon
>
>
> Regards,
> Alexey
>
>>
>>
>>>>
>>>>
>>>>>>
>>>>>> "For any positive size value the exact file icon size is queried":
>>>>>>     - This should be double checked because our implementation 
>>>>>> can return MultiResolutionIconImage if the system returns the 
>>>>>> icon which size is different from requested.
>>>>>>
>>>>>> FILE_ICON_SMALL(FILE_ICON_LARGE);
>>>>>>     - What these parameters mean? Is it the smallest(biggest) 
>>>>>> supported size or is it a default size? Can it be different if 
>>>>>> different dpi are used on the screen? For example 16(32) by 
>>>>>> default and 32(64) on HiDPI?
>>>>> They means what they have been meaning FileChooserUI 
>>>>> implementation for the Windows L&F which operates by two fixed 
>>>>> icon sizes, large and small.
>>>>
>>>> But it is not necessary will be used by our implementation of 
>>>> FileChooserUI when this API became public. For example in the 
>>>> description of JDK-8156183 the user said that large icons are used 
>>>> in "a media file browser" and "32x32 isn't large by the standards 
>>>> of current-millennium operating systems".
>>>> But even in our FileChooserUI implementation shouldn't we use x2 
>>>> icons in case of HiDPI?
>>>> FILE_ICON_SMALL - is it a smallest supported size?
>>> User may use the new method to get icons at any resolution. 
>>> Small/large sizes are preserved for backward compatibility, because 
>>> before this change only those two sizes were available.
>>
>> Backward compatibility to what? There was know public API for this.
>> It is still unclear what is a "the small or large file icon variant" 
>> means.
>>
>>>>
>>>>
>>>>>> FILE_ICON_SMALL:
>>>>>>    - It seems that this value duplicate functionality of the old 
>>>>>> getSystemIcon(File) method?
>>>>> How this can be got from the spec? It may return the same size but 
>>>>> not necessarily.
>>>>
>>>> Then how the old method and the new one are related? Will the old 
>>>> method returns the size in between FILE_ICON_SMALL and 
>>>> FILE_ICON_LARGE?
>>> I didn't get how it would be possible?
>>
>> Possible what? It is unclear how the two methods are related to each 
>> other.
>>
>>>>
>>>>>>
>>>>>>
>>>>>> Probably it will be better to provide to the user the 
>>>>>> set(list/mri/array/etc) of supported images, or if it is really 
>>>>>> slow the set(list/mri/array/etc) of supported sizes, and the user 
>>>>>> will be able to pass some meaningful sizes.
>>>>> This is not a good idea. Extracting all available icon resolutions 
>>>>> might take significant time and since icons are cached it would be 
>>>>> waste of RAM.
>>>>
>>>> It should be measured, we can try to load them lazy, or provide the 
>>>> list of sizes which are supported.
>>> Sorry, I didn't get what are you proposing to measure? And how do 
>>> you propose to get the icon size without reading the image?
>>>>
>>>>>>
>>>>>>
>>>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>>>
>>>>>>> The fix  opens the part of the ShellFolder API for getting 
>>>>>>> system icons which was decided to be left closed during the 
>>>>>>> 8081722 enhancement review in 9.
>>>>>>>
>>>>>>> Also the fix extends the API by adding possibility to query file 
>>>>>>> icons of arbitrary size and implements this extension for 
>>>>>>> Windows platform.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From alexey.ivanov at oracle.com  Fri Sep 22 16:43:44 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 22 Sep 2017 17:43:44 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
Message-ID: <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>

Hi Semyon,

On 22/09/2017 17:13, Semyon Sadetsky wrote:
> Hi Alexey,
>
> Thank you for your exact clarification.
>
> On 09/22/2017 04:22 AM, Alexey Ivanov wrote:
>> <SNIP>
>>
>> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using Windows 
>> API to retrieve the recommended size for small and large icon size 
>> rather than defaulting to 16?16 and 32?32. If HiDPI is in effect, the 
>> icons must be larger.
> I also found this as most suitable approach for the moment.
> Later this may be changed, for example, if Swing JFC is re-factored to 
> support shell determined icon sizes at HiDPI.

Swing UI scales to accommodate HiDPI settings. If fonts are larger then 
icons should be larger too. Otherwise icons are too small compared to 
surrounding text.

Anyway it could be postponed to a later fix.

Does it make sense to declare the standard sizes of 16?16 and 32?32 as 
constants at least in Java sources? This way, it would be easier to find 
the places in code where a change is necessary.


Regards,
Alexey

>
>
> --Semyon
>>
>>
>> Regards,
>> Alexey
>>
>>>
>>>> <SNIP>
>>>>>
>>>>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>>>>
>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>>>>
>>>>>>>> The fix? opens the part of the ShellFolder API for getting 
>>>>>>>> system icons which was decided to be left closed during the 
>>>>>>>> 8081722 enhancement review in 9.
>>>>>>>>
>>>>>>>> Also the fix extends the API by adding possibility to query 
>>>>>>>> file icons of arbitrary size and implements this extension for 
>>>>>>>> Windows platform.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>


From semyon.sadetsky at oracle.com  Fri Sep 22 17:29:22 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 22 Sep 2017 10:29:22 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
Message-ID: <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>

Hi Alexey,

On 09/22/2017 09:43 AM, Alexey Ivanov wrote:
> Hi Semyon,
>
> On 22/09/2017 17:13, Semyon Sadetsky wrote:
>> Hi Alexey,
>>
>> Thank you for your exact clarification.
>>
>> On 09/22/2017 04:22 AM, Alexey Ivanov wrote:
>>> <SNIP>
>>>
>>> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using 
>>> Windows API to retrieve the recommended size for small and large 
>>> icon size rather than defaulting to 16?16 and 32?32. If HiDPI is in 
>>> effect, the icons must be larger.
>> I also found this as most suitable approach for the moment.
>> Later this may be changed, for example, if Swing JFC is re-factored 
>> to support shell determined icon sizes at HiDPI.
>
> Swing UI scales to accommodate HiDPI settings. If fonts are larger 
> then icons should be larger too. Otherwise icons are too small 
> compared to surrounding text.
>
> Anyway it could be postponed to a later fix.
>
> Does it make sense to declare the standard sizes of 16?16 and 32?32 as 
> constants at least in Java sources? This way, it would be easier to 
> find the places in code where a change is necessary.
This topic requires more investigations. At first, we need to keep the 
API cross-platform and this requires comparing all supported platforms 
in details. At the second, even for the existing windows implementation 
there is an ambiguity in icons sizes received form the OS shell. Windows 
platform has number of predefined constants to query icon sizes (small, 
large, extra large, jumbo...) but their actual size may differ depending 
on the shell preferences.
Those icon sizes may be changed by Windows registry settings and may 
depend on the hi-res scale. I did several experiments and found that 
depending on the way of desktop scaling  in Windows 10 (it has two ways 
the new one and the old) at the same scale 2x the returned large icon, 
for example,  may be 32 or 64 pixels in size (this was the root cause of 
the 8151385  bug).
I would postpone digging in this direction because we are not planning 
to update Swing JFC dialog for better HiDPI view in the nearest future. 
Also,we don't have statistics how users may use the API. Since that, the 
most flexible API that leaves to the user the decision about icon size 
to query seems more preferable.

--Semyon
>
>
> Regards,
> Alexey
>
>>
>>
>> --Semyon
>>>
>>>
>>> Regards,
>>> Alexey
>>>
>>>>
>>>>> <SNIP>
>>>>>>
>>>>>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>>>>>
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>>>>>
>>>>>>>>> The fix  opens the part of the ShellFolder API for getting 
>>>>>>>>> system icons which was decided to be left closed during the 
>>>>>>>>> 8081722 enhancement review in 9.
>>>>>>>>>
>>>>>>>>> Also the fix extends the API by adding possibility to query 
>>>>>>>>> file icons of arbitrary size and implements this extension for 
>>>>>>>>> Windows platform.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>


From alexey.ivanov at oracle.com  Fri Sep 22 17:53:29 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 22 Sep 2017 18:53:29 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
Message-ID: <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>

Hi Semyon,

On 22/09/2017 18:29, Semyon Sadetsky wrote:
> Hi Alexey,
>
> On 09/22/2017 09:43 AM, Alexey Ivanov wrote:
>> Hi Semyon,
>>
>> On 22/09/2017 17:13, Semyon Sadetsky wrote:
>>> Hi Alexey,
>>>
>>> Thank you for your exact clarification.
>>>
>>> On 09/22/2017 04:22 AM, Alexey Ivanov wrote:
>>>> <SNIP>
>>>>
>>>> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using 
>>>> Windows API to retrieve the recommended size for small and large 
>>>> icon size rather than defaulting to 16?16 and 32?32. If HiDPI is in 
>>>> effect, the icons must be larger.
>>> I also found this as most suitable approach for the moment.
>>> Later this may be changed, for example, if Swing JFC is re-factored 
>>> to support shell determined icon sizes at HiDPI.
>>
>> Swing UI scales to accommodate HiDPI settings. If fonts are larger 
>> then icons should be larger too. Otherwise icons are too small 
>> compared to surrounding text.
>>
>> Anyway it could be postponed to a later fix.
>>
>> Does it make sense to declare the standard sizes of 16?16 and 32?32 
>> as constants at least in Java sources? This way, it would be easier 
>> to find the places in code where a change is necessary.
> This topic requires more investigations. At first, we need to keep the 
> API cross-platform and this requires comparing all supported platforms 
> in details. At the second, even for the existing windows 
> implementation there is an ambiguity in icons sizes received form the 
> OS shell. Windows platform has number of predefined constants to query 
> icon sizes (small, large, extra large, jumbo...) but their actual size 
> may differ depending on the shell preferences.
> Those icon sizes may be changed by Windows registry settings and may 
> depend on the hi-res scale. I did several experiments and found that 
> depending on the way of desktop scaling? in Windows 10 (it has two 
> ways the new one and the old) at the same scale 2x the returned large 
> icon, for example,? may be 32 or 64 pixels in size (this was the root 
> cause of the 8151385? bug).
> I would postpone digging in this direction because we are not planning 
> to update Swing JFC dialog for better HiDPI view in the nearest 
> future. Also,we don't have statistics how users may use the API. Since 
> that, the most flexible API that leaves to the user the decision about 
> icon size to query seems more preferable.

I totally agree with your points. And the new API provides means for app 
developer to choose better-suited size for icons.

What about using constants, private ones, for the two standard sizes 
instead of using ?magic? numbers?
Other than that, the fix looks good to me.


Regards,
Alexey

>
>
> --Semyon
>>
>>
>> Regards,
>> Alexey
>>
>>>
>>>
>>> --Semyon
>>>>
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>>>
>>>>>> <SNIP>
>>>>>>>
>>>>>>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>>>>>>>>
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>>>>>>
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>>>>>>
>>>>>>>>>> The fix? opens the part of the ShellFolder API for getting 
>>>>>>>>>> system icons which was decided to be left closed during the 
>>>>>>>>>> 8081722 enhancement review in 9.
>>>>>>>>>>
>>>>>>>>>> Also the fix extends the API by adding possibility to query 
>>>>>>>>>> file icons of arbitrary size and implements this extension 
>>>>>>>>>> for Windows platform.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>


From semyon.sadetsky at oracle.com  Fri Sep 22 19:06:32 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 22 Sep 2017 12:06:32 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
Message-ID: <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>

Hi Alexey,

On 09/22/2017 10:53 AM, Alexey Ivanov wrote:
> Hi Semyon,
>
> On 22/09/2017 18:29, Semyon Sadetsky wrote:
>> Hi Alexey,
>>
>> On 09/22/2017 09:43 AM, Alexey Ivanov wrote:
>>> Hi Semyon,
>>>
>>> On 22/09/2017 17:13, Semyon Sadetsky wrote:
>>>> Hi Alexey,
>>>>
>>>> Thank you for your exact clarification.
>>>>
>>>> On 09/22/2017 04:22 AM, Alexey Ivanov wrote:
>>>>> <SNIP>
>>>>>
>>>>> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using 
>>>>> Windows API to retrieve the recommended size for small and large 
>>>>> icon size rather than defaulting to 16?16 and 32?32. If HiDPI is 
>>>>> in effect, the icons must be larger.
>>>> I also found this as most suitable approach for the moment.
>>>> Later this may be changed, for example, if Swing JFC is re-factored 
>>>> to support shell determined icon sizes at HiDPI.
>>>
>>> Swing UI scales to accommodate HiDPI settings. If fonts are larger 
>>> then icons should be larger too. Otherwise icons are too small 
>>> compared to surrounding text.
>>>
>>> Anyway it could be postponed to a later fix.
>>>
>>> Does it make sense to declare the standard sizes of 16?16 and 32?32 
>>> as constants at least in Java sources? This way, it would be easier 
>>> to find the places in code where a change is necessary.
>> This topic requires more investigations. At first, we need to keep 
>> the API cross-platform and this requires comparing all supported 
>> platforms in details. At the second, even for the existing windows 
>> implementation there is an ambiguity in icons sizes received form the 
>> OS shell. Windows platform has number of predefined constants to 
>> query icon sizes (small, large, extra large, jumbo...) but their 
>> actual size may differ depending on the shell preferences.
>> Those icon sizes may be changed by Windows registry settings and may 
>> depend on the hi-res scale. I did several experiments and found that 
>> depending on the way of desktop scaling  in Windows 10 (it has two 
>> ways the new one and the old) at the same scale 2x the returned large 
>> icon, for example,  may be 32 or 64 pixels in size (this was the root 
>> cause of the 8151385  bug).
>> I would postpone digging in this direction because we are not 
>> planning to update Swing JFC dialog for better HiDPI view in the 
>> nearest future. Also,we don't have statistics how users may use the 
>> API. Since that, the most flexible API that leaves to the user the 
>> decision about icon size to query seems more preferable.
>
> I totally agree with your points. And the new API provides means for 
> app developer to choose better-suited size for icons.
>
> What about using constants, private ones, for the two standard sizes 
> instead of using ?magic? numbers?
Which constants do you mean? The next for large and small sizes?

public static final int FILE_ICON_SMALL = -1;

public static final int FILE_ICON_LARGE = -2;

they cannot be private because they are part of the new API that is 
requested in the bug. The bug asks enabling the query for the large icon 
that ShellFolder had been providing before. The bug itself is not 
related to HiDPI. The possibility to get arbitrary icon sizes was added 
because after 9 this may be in demand for HiDPI UIs.

--Semyon

> Other than that, the fix looks good to me.
>
>
> Regards,
> Alexey
>
>>
>>
>> --Semyon
>>>
>>>
>>> Regards,
>>> Alexey
>>>
>>>>
>>>>
>>>> --Semyon
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>>>
>>>>>>> <SNIP>
>>>>>>>>
>>>>>>>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review fix for JDK10 (the changes involve AWT and 
>>>>>>>>>>> Swing):
>>>>>>>>>>>
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>>>>>>>
>>>>>>>>>>> webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> The fix  opens the part of the ShellFolder API for getting 
>>>>>>>>>>> system icons which was decided to be left closed during the 
>>>>>>>>>>> 8081722 enhancement review in 9.
>>>>>>>>>>>
>>>>>>>>>>> Also the fix extends the API by adding possibility to query 
>>>>>>>>>>> file icons of arbitrary size and implements this extension 
>>>>>>>>>>> for Windows platform.
>>>>>>>>>>>
>>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170922/17946139/attachment-0001.html>

From alexey.ivanov at oracle.com  Fri Sep 22 20:01:33 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 22 Sep 2017 21:01:33 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
 <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
Message-ID: <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>

Hi Semyon,

On 22/09/2017 20:06, Semyon Sadetsky wrote:
>
> Hi Alexey,
>
> On 09/22/2017 10:53 AM, Alexey Ivanov wrote:
>> Hi Semyon,
>>
>> On 22/09/2017 18:29, Semyon Sadetsky wrote:
>>> Hi Alexey,
>>>
>>> On 09/22/2017 09:43 AM, Alexey Ivanov wrote:
>>>> Hi Semyon,
>>>>
>>>> On 22/09/2017 17:13, Semyon Sadetsky wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> Thank you for your exact clarification.
>>>>>
>>>>> On 09/22/2017 04:22 AM, Alexey Ivanov wrote:
>>>>>> <SNIP>
>>>>>>
>>>>>> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using 
>>>>>> Windows API to retrieve the recommended size for small and large 
>>>>>> icon size rather than defaulting to 16?16 and 32?32. If HiDPI is 
>>>>>> in effect, the icons must be larger.
>>>>> I also found this as most suitable approach for the moment.
>>>>> Later this may be changed, for example, if Swing JFC is 
>>>>> re-factored to support shell determined icon sizes at HiDPI.
>>>>
>>>> Swing UI scales to accommodate HiDPI settings. If fonts are larger 
>>>> then icons should be larger too. Otherwise icons are too small 
>>>> compared to surrounding text.
>>>>
>>>> Anyway it could be postponed to a later fix.
>>>>
>>>> Does it make sense to declare the standard sizes of 16?16 and 32?32 
>>>> as constants at least in Java sources? This way, it would be easier 
>>>> to find the places in code where a change is necessary.
>>> This topic requires more investigations. At first, we need to keep 
>>> the API cross-platform and this requires comparing all supported 
>>> platforms in details. At the second, even for the existing windows 
>>> implementation there is an ambiguity in icons sizes received form 
>>> the OS shell. Windows platform has number of predefined constants to 
>>> query icon sizes (small, large, extra large, jumbo...) but their 
>>> actual size may differ depending on the shell preferences.
>>> Those icon sizes may be changed by Windows registry settings and may 
>>> depend on the hi-res scale. I did several experiments and found that 
>>> depending on the way of desktop scaling? in Windows 10 (it has two 
>>> ways the new one and the old) at the same scale 2x the returned 
>>> large icon, for example,? may be 32 or 64 pixels in size (this was 
>>> the root cause of the 8151385 bug).
>>> I would postpone digging in this direction because we are not 
>>> planning to update Swing JFC dialog for better HiDPI view in the 
>>> nearest future. Also,we don't have statistics how users may use the 
>>> API. Since that, the most flexible API that leaves to the user the 
>>> decision about icon size to query seems more preferable.
>>
>> I totally agree with your points. And the new API provides means for 
>> app developer to choose better-suited size for icons.
>>
>> What about using constants, private ones, for the two standard sizes 
>> instead of using ?magic? numbers?
> Which constants do you mean? The next for large and small sizes?
>
> public static final int FILE_ICON_SMALL = -1;
> public static final int FILE_ICON_LARGE = -2;
> they cannot be private because they are part of the new API that is 
> requested in the bug. The bug asks enabling the query for the large 
> icon that ShellFolder had been providing before. The bug itself is not 
> related to HiDPI. The possibility to get arbitrary icon sizes was 
> added because after 9 this may be in demand for HiDPI UIs.

I'm talking about these two numbers in Win32ShellFolder2.java as an example:

 ?? public Image getIcon(final boolean getLargeIcon) {
 ?????? int size = getLargeIcon ? *32* : *16*;

Does it make sense to declare constants for the size of 16 and 32. So 
that the places where they're used are more easily identified if someone 
decides to update the code later for supporting system icon size.


Regards,
Alexey

>
> --Semyon
>
>> Other than that, the fix looks good to me.
>>
>>
>> Regards,
>> Alexey
>>
>>>
>>>
>>> --Semyon
>>>>
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>>>
>>>>>
>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alexey
>>>>>>
>>>>>>>
>>>>>>>> <SNIP>
>>>>>>>>>
>>>>>>>>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review fix for JDK10 (the changes involve AWT and 
>>>>>>>>>>>> Swing):
>>>>>>>>>>>>
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>>>>>>>>
>>>>>>>>>>>> webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> The fix? opens the part of the ShellFolder API for getting 
>>>>>>>>>>>> system icons which was decided to be left closed during the 
>>>>>>>>>>>> 8081722 enhancement review in 9.
>>>>>>>>>>>>
>>>>>>>>>>>> Also the fix extends the API by adding possibility to query 
>>>>>>>>>>>> file icons of arbitrary size and implements this extension 
>>>>>>>>>>>> for Windows platform.
>>>>>>>>>>>>
>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170922/08db120a/attachment.html>

From semyon.sadetsky at oracle.com  Fri Sep 22 21:05:08 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 22 Sep 2017 14:05:08 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
 <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
 <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>
Message-ID: <125d7526-1b85-d950-41c6-fbadebbde114@oracle.com>

Hi Alexey,

On 09/22/2017 01:01 PM, Alexey Ivanov wrote:
> Hi Semyon,
>
> On 22/09/2017 20:06, Semyon Sadetsky wrote:
>>
>> Hi Alexey,
>>
>> On 09/22/2017 10:53 AM, Alexey Ivanov wrote:
>>> Hi Semyon,
>>>
>>> On 22/09/2017 18:29, Semyon Sadetsky wrote:
>>>> Hi Alexey,
>>>>
>>>> On 09/22/2017 09:43 AM, Alexey Ivanov wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> On 22/09/2017 17:13, Semyon Sadetsky wrote:
>>>>>> Hi Alexey,
>>>>>>
>>>>>> Thank you for your exact clarification.
>>>>>>
>>>>>> On 09/22/2017 04:22 AM, Alexey Ivanov wrote:
>>>>>>> <SNIP>
>>>>>>>
>>>>>>> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using 
>>>>>>> Windows API to retrieve the recommended size for small and large 
>>>>>>> icon size rather than defaulting to 16?16 and 32?32. If HiDPI is 
>>>>>>> in effect, the icons must be larger.
>>>>>> I also found this as most suitable approach for the moment.
>>>>>> Later this may be changed, for example, if Swing JFC is 
>>>>>> re-factored to support shell determined icon sizes at HiDPI.
>>>>>
>>>>> Swing UI scales to accommodate HiDPI settings. If fonts are larger 
>>>>> then icons should be larger too. Otherwise icons are too small 
>>>>> compared to surrounding text.
>>>>>
>>>>> Anyway it could be postponed to a later fix.
>>>>>
>>>>> Does it make sense to declare the standard sizes of 16?16 and 
>>>>> 32?32 as constants at least in Java sources? This way, it would be 
>>>>> easier to find the places in code where a change is necessary.
>>>> This topic requires more investigations. At first, we need to keep 
>>>> the API cross-platform and this requires comparing all supported 
>>>> platforms in details. At the second, even for the existing windows 
>>>> implementation there is an ambiguity in icons sizes received form 
>>>> the OS shell. Windows platform has number of predefined constants 
>>>> to query icon sizes (small, large, extra large, jumbo...) but their 
>>>> actual size may differ depending on the shell preferences.
>>>> Those icon sizes may be changed by Windows registry settings and 
>>>> may depend on the hi-res scale. I did several experiments and found 
>>>> that depending on the way of desktop scaling  in Windows 10 (it has 
>>>> two ways the new one and the old) at the same scale 2x the returned 
>>>> large icon, for example,  may be 32 or 64 pixels in size (this was 
>>>> the root cause of the 8151385  bug).
>>>> I would postpone digging in this direction because we are not 
>>>> planning to update Swing JFC dialog for better HiDPI view in the 
>>>> nearest future. Also,we don't have statistics how users may use the 
>>>> API. Since that, the most flexible API that leaves to the user the 
>>>> decision about icon size to query seems more preferable.
>>>
>>> I totally agree with your points. And the new API provides means for 
>>> app developer to choose better-suited size for icons.
>>>
>>> What about using constants, private ones, for the two standard sizes 
>>> instead of using ?magic? numbers?
>> Which constants do you mean? The next for large and small sizes?
>>
>> public static final int FILE_ICON_SMALL = -1;
>> public static final int FILE_ICON_LARGE = -2;
>> they cannot be private because they are part of the new API that is 
>> requested in the bug. The bug asks enabling the query for the large 
>> icon that ShellFolder had been providing before. The bug itself is 
>> not related to HiDPI. The possibility to get arbitrary icon sizes was 
>> added because after 9 this may be in demand for HiDPI UIs.
>
> I'm talking about these two numbers in Win32ShellFolder2.java as an 
> example:
>
>    public Image getIcon(final boolean getLargeIcon) {
>        int size = getLargeIcon ? *32* : *16*;
>
> Does it make sense to declare constants for the size of 16 and 32. So 
> that the places where they're used are more easily identified if 
> someone decides to update the code later for supporting system icon size.
I updated the fix.

http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/

--Semyon
>
>
> Regards,
> Alexey
>
>>
>> --Semyon
>>
>>> Other than that, the fix looks good to me.
>>>
>>>
>>> Regards,
>>> Alexey
>>>
>>>>
>>>>
>>>> --Semyon
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>>>
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>>
>>>>>>>>
>>>>>>>>> <SNIP>
>>>>>>>>>>
>>>>>>>>>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review fix for JDK10 (the changes involve AWT and 
>>>>>>>>>>>>> Swing):
>>>>>>>>>>>>>
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>>>>>>>>>
>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fix  opens the part of the ShellFolder API for getting 
>>>>>>>>>>>>> system icons which was decided to be left closed during 
>>>>>>>>>>>>> the 8081722 enhancement review in 9.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also the fix extends the API by adding possibility to 
>>>>>>>>>>>>> query file icons of arbitrary size and implements this 
>>>>>>>>>>>>> extension for Windows platform.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170922/e5de16dd/attachment-0001.html>

From philip.race at oracle.com  Fri Sep 22 22:05:40 2017
From: philip.race at oracle.com (Phil Race)
Date: Fri, 22 Sep 2017 15:05:40 -0700
Subject: <AWT Dev> [10] Review request for 8185634,
 8185634: Java Fx-Swing dialogs appearing behind main stage
In-Reply-To: <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com>
 <c10968d7-af0b-d599-6620-dd95e4d7af12@oracle.com>
 <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
Message-ID: <213a2fbf-6d66-7e8b-adda-289374f09e3f@oracle.com>

I need to look more closely but at a quick glance I don't see any 
problems so a tentative +1 ..
but a final +1 will go in the bug.
Have you tested the various configurations .. running this on top of 
current JDK (not FX) 10
both with and without the FX changes ?

-phil.


On 09/21/2017 10:56 PM, Alexander Zvegintsev wrote:
>
> Hi Phil,
>
> Please review the updated fix with reflection incorporated
> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/
>
> New issue created JDK-8187803 
> <https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart 
> of this issue.
>
> Thanks,
> Alexander.
> On 21/09/2017 22:25, Phil Race wrote:
>> Some procedural comments :
>> Since 90% of this is in AWT code, I'd have thought awt-dev should be 
>> included here.
>> I've added that list.
>>
>> And apart from needing separate bug ids, I don't see why the bug 
>> below is confidential.
>>
>>
>> I agree with what Kevin pointed out off-line that as in the dialog 
>> case, the FX side
>> of the code can use reflection and simply be a harmless 
>> non-functional no-op
>> if the SwingAccessor does not provide the new method.
>>
>> BTW
>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
>> should be "dd" not "d".
>>
>> -phil.
>>
>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:
>>> Hello,
>>>
>>> please review the fix
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8185634
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170922/c23c5b33/attachment.html>

From Sergey.Bylokhov at oracle.com  Sat Sep 23 02:22:24 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 22 Sep 2017 19:22:24 -0700
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
In-Reply-To: <d3727c16-5845-1baf-0700-513b7ff09ec9@oracle.com>
References: <bc568398-c4e4-41de-be9a-b2f3c57832fb@default>
 <dc2d8bd8-9c61-ab13-1405-1338920f9fca@oracle.com>
 <a19185ff-acca-a2ed-a69d-ab0fe7fba753@oracle.com>
 <d3727c16-5845-1baf-0700-513b7ff09ec9@oracle.com>
Message-ID: <98abeab4-f831-a724-dae0-6745df63dfc0@oracle.com>

Hi, Prasanta.

On 9/19/17 22:26, Prasanta Sadhukhan wrote:
>> Hi, Prasanta.
>> ?- In this version it is unclear what is a purpose of the 
>> "fxCheckSequenceThread.start()". This code will start the thread and 
>> will continue execution, it will not wait when the thread will stop.
>> ?- The DefaultKeyboardFocusManager also should check for 
>> "javafx.embed.singleThread"
>>
> Please find modified webrev catering to both comments
> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.04/

The new code in DefaultKeyboardFocusManager also will not wait when the 
thread will stop.

> 
> Regards
> Prasanta
>>
>> On 9/13/17 03:11, Prasanta Sadhukhan wrote:
>>> Hi Sergey,
>>>
>>> I have modified the fix to not use SecondaryLoop and not to create 
>>> one thread per dispatch
>>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/
>>>
>>> Regards
>>> Prasanta
>>> On 8/30/2017 11:41 AM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>> Can you please provide some description on how the SecondaryLoop 
>>>> will work when it will run on Appkit thread? Is it possible to get a 
>>>> deadlock here, since appkit will be blocked?
>>>>
>>>>> sequence, ie if the event is not first in sequence, then it will made
>>>>> to
>>>>> wait till it is the first event or till it is disposed.
>>>> Note that the new code (unlike lines 139-150) also waits 1 second, 
>>>> so we can get a situation when only one event will be dispatched per 
>>>> second, which is not we want to do.
>>>> I am not sure how often we create SequencedEvent but creating one 
>>>> thread per dispatch look inefficient.
>>>>
>>>>
>>>>> Modified webrev
>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:
>>>>>> Hi, Prasanta.
>>>>>>
>>>>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
>>>>>>> Now, since here FX App thread itself is the dispatch thread, we can
>>>>>>> be sure the events are dispatched in sequence and dispose is
>>>>> checked
>>>>>>> below after EDT.
>>>>>> Why we can sure about this? If the SequencedEvents were created in
>>>>> one
>>>>>> order but dispatch() for each were called in other order then the
>>>>>> sequenced will not be preserved?
>>>>>>
>>>>>>> I have tested with couple of singleThread testcase without any
>>>>> issue.
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Prasanta, Kevin.
>>>>>>>>
>>>>>>>> I have two notes.
>>>>>>>> ?? - Does this option is really supported? If it is supported we
>>>>>>>> should evaluate all usage of EventDispatchThread because in this
>>>>>>>> mode the dispatch thread is not EDT. For example I am not sure
>>>>> that
>>>>>>>> we can skip the code which expects EventDispatchThread.
>>>>>>>> ?? - We have the similar pattern: "EventQueue.isDispatchThread() ->
>>>>>>>> cast(EventDispatchThread)" in some other places like in
>>>>>>>> DefaultKeyboardFocusManager.
>>>>>>>>
>>>>>>>> -----prasanta.sadhukhan at oracle.com? wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review this fix
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>>>>>>>>> for an fx issue
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>>>>>>>>
>>>>>>>>> More info in JBS.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Sep 23 02:31:35 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 22 Sep 2017 19:31:35 -0700
Subject: <AWT Dev> [10] Review request for 8185634,
 8185634: Java Fx-Swing dialogs appearing behind main stage
In-Reply-To: <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com>
 <c10968d7-af0b-d599-6620-dd95e4d7af12@oracle.com>
 <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
Message-ID: <7c868789-6c1e-28c9-af7a-057d551e0dfe@oracle.com>

Hi, Alexander.
How can we be sure that the parent frame will not be disposed while we 
use a pointer?

long ownerWindowPtr = peer.getOverridenWindowHandle();
<<<<< Dispose the peer
if (ownerWindowPtr != 0) {
     //Place window above JavaFX stage
     CWrapper.NSWindow.addChildWindow(
     ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
<<<<< Boom
}


On 9/21/17 22:56, Alexander Zvegintsev wrote:
> Hi Phil,
> 
> Please review the updated fix with reflection incorporated
> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/
> 
> New issue created JDK-8187803 
> <https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart of 
> this issue.
> 
> Thanks,
> Alexander.
> 
> On 21/09/2017 22:25, Phil Race wrote:
>> Some procedural comments :
>> Since 90% of this is in AWT code, I'd have thought awt-dev should be 
>> included here.
>> I've added that list.
>>
>> And apart from needing separate bug ids, I don't see why the bug below 
>> is confidential.
>>
>>
>> I agree with what Kevin pointed out off-line that as in the dialog 
>> case, the FX side
>> of the code can use reflection and simply be a harmless non-functional 
>> no-op
>> if the SwingAccessor does not provide the new method.
>>
>> BTW
>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
>> should be "dd" not "d".
>>
>> -phil.
>>
>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:
>>> Hello,
>>>
>>> please review the fix
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8185634
>>>
>>
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Sat Sep 23 07:03:32 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 23 Sep 2017 12:33:32 +0530
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
In-Reply-To: <98abeab4-f831-a724-dae0-6745df63dfc0@oracle.com>
References: <bc568398-c4e4-41de-be9a-b2f3c57832fb@default>
 <dc2d8bd8-9c61-ab13-1405-1338920f9fca@oracle.com>
 <a19185ff-acca-a2ed-a69d-ab0fe7fba753@oracle.com>
 <d3727c16-5845-1baf-0700-513b7ff09ec9@oracle.com>
 <98abeab4-f831-a724-dae0-6745df63dfc0@oracle.com>
Message-ID: <2df0d688-5111-3320-d287-d3500dd3ffaa@oracle.com>

Hi Sergey,

Please find modified webrev catering to DefaultKeyboardFocusManager also
http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.05/

Regards
Prasanta
On 9/23/2017 7:52 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
>
> On 9/19/17 22:26, Prasanta Sadhukhan wrote:
>>> Hi, Prasanta.
>>> ?- In this version it is unclear what is a purpose of the 
>>> "fxCheckSequenceThread.start()". This code will start the thread and 
>>> will continue execution, it will not wait when the thread will stop.
>>> ?- The DefaultKeyboardFocusManager also should check for 
>>> "javafx.embed.singleThread"
>>>
>> Please find modified webrev catering to both comments
>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.04/
>
> The new code in DefaultKeyboardFocusManager also will not wait when 
> the thread will stop.
>
>>
>> Regards
>> Prasanta
>>>
>>> On 9/13/17 03:11, Prasanta Sadhukhan wrote:
>>>> Hi Sergey,
>>>>
>>>> I have modified the fix to not use SecondaryLoop and not to create 
>>>> one thread per dispatch
>>>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 8/30/2017 11:41 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Can you please provide some description on how the SecondaryLoop 
>>>>> will work when it will run on Appkit thread? Is it possible to get 
>>>>> a deadlock here, since appkit will be blocked?
>>>>>
>>>>>> sequence, ie if the event is not first in sequence, then it will 
>>>>>> made
>>>>>> to
>>>>>> wait till it is the first event or till it is disposed.
>>>>> Note that the new code (unlike lines 139-150) also waits 1 second, 
>>>>> so we can get a situation when only one event will be dispatched 
>>>>> per second, which is not we want to do.
>>>>> I am not sure how often we create SequencedEvent but creating one 
>>>>> thread per dispatch look inefficient.
>>>>>
>>>>>
>>>>>> Modified webrev
>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:
>>>>>>> Hi, Prasanta.
>>>>>>>
>>>>>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
>>>>>>>> Now, since here FX App thread itself is the dispatch thread, we 
>>>>>>>> can
>>>>>>>> be sure the events are dispatched in sequence and dispose is
>>>>>> checked
>>>>>>>> below after EDT.
>>>>>>> Why we can sure about this? If the SequencedEvents were created in
>>>>>> one
>>>>>>> order but dispatch() for each were called in other order then the
>>>>>>> sequenced will not be preserved?
>>>>>>>
>>>>>>>> I have tested with couple of singleThread testcase without any
>>>>>> issue.
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
>>>>>>>>> Hi, Prasanta, Kevin.
>>>>>>>>>
>>>>>>>>> I have two notes.
>>>>>>>>> ?? - Does this option is really supported? If it is supported we
>>>>>>>>> should evaluate all usage of EventDispatchThread because in this
>>>>>>>>> mode the dispatch thread is not EDT. For example I am not sure
>>>>>> that
>>>>>>>>> we can skip the code which expects EventDispatchThread.
>>>>>>>>> ?? - We have the similar pattern: 
>>>>>>>>> "EventQueue.isDispatchThread() ->
>>>>>>>>> cast(EventDispatchThread)" in some other places like in
>>>>>>>>> DefaultKeyboardFocusManager.
>>>>>>>>>
>>>>>>>>> -----prasanta.sadhukhan at oracle.com? wrote:
>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review this fix
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>>>>>>>>>> for an fx issue
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>>>>>>>>>
>>>>>>>>>> More info in JBS.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>
>>>>
>>>
>>>
>>
>
>


From dmitry.markov at oracle.com  Sat Sep 23 15:25:19 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Sat, 23 Sep 2017 16:25:19 +0100
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition issue
Message-ID: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>

Hello,

Could you review a fix for jdk10, please?

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

Problem description:
Currently we restore focus synchronously to a component if the window (which contains it) owns the focus. However if another window/dialog is displayed at the same time, the first window loses focus, (i.e. synchronous focus request failed) and the focus target is shifted to the next component in the focus traversal cycle.

Fix:
It is necessary to check the result of synchronous focus request for a component. If the focus request?s failed because the contained window lost focus, we should restore focus to this component next time when its parent window obtains focus.

Testing:
I ran corresponding JCK and regression tests and did not observe any new failures.

Thanks,
Dmitry

From dmitry.markov at oracle.com  Sat Sep 23 15:51:04 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Sat, 23 Sep 2017 16:51:04 +0100
Subject: <AWT Dev> [10] Review request for 8185634,
 8185634: Java Fx-Swing dialogs appearing behind main stage
In-Reply-To: <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com>
 <c10968d7-af0b-d599-6620-dd95e4d7af12@oracle.com>
 <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
Message-ID: <F5964E0F-A0A7-49BE-B056-8E590B0C8559@oracle.com>

Hi Alexander,

In CPlatformWindow class you call CWrapper.NSWindow.addChildWindow() to place a window above JavaFX stage. The usage of addChilWindow() or/and removeChildWindow() may cause ?jumping window issue? in multi-monitor environment, see JDK-8080729 for more details.

To avoid possible problems in multi monitor set-up I suggest that you should replace addChildWindow() with orderWindow() or use some another approach to locate the window above the stage.

Thanks,
Dmitry
> On 22 Sep 2017, at 06:56, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
> 
> Hi Phil,
> 
> Please review the updated fix with reflection incorporated
> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/
> 
> New issue created JDK-8187803 <https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart of this issue.
> 
> Thanks,
> Alexander.
> 
> On 21/09/2017 22:25, Phil Race wrote:
>> Some procedural comments :
>> Since 90% of this is in AWT code, I'd have thought awt-dev should be included here.
>> I've added that list.
>> 
>> And apart from needing separate bug ids, I don't see why the bug below is confidential.
>> 
>> 
>> I agree with what Kevin pointed out off-line that as in the dialog case, the FX side
>> of the code can use reflection and simply be a harmless non-functional no-op
>> if the SwingAccessor does not provide the new method.
>> 
>> BTW
>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
>> should be "dd" not "d".
>> 
>> -phil.
>> 
>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:
>>> Hello,
>>> 
>>> please review the fix
>>> 
>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/
>>> 
>>> for the issue
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8185634
>>> 
>> 
> 


From shashidhara.veerabhadraiah at oracle.com  Mon Sep 25 06:29:36 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Sun, 24 Sep 2017 23:29:36 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <ccff0734-1ed5-8c88-d558-1b41a31a3477@oracle.com>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
 <ccff0734-1ed5-8c88-d558-1b41a31a3477@oracle.com>
Message-ID: <cddc59b7-0dec-4a33-9e38-e284ed1d8a4d@default>

Hi Alexey, Thank you for pointing that out. I misread the info that EnableMouseInPointer() is a must call and would enable the WM_POINTER messages being sent to the component. But actually it is not required to be enabled and as you rightly pointed out that it would convert the WM_MOUSE to the WM_POINTER messages.

?

Below is the Webrev that does this change. Now since mouse in pointer is disabled, the mouse behavior should not have any effect at all by this software updates.

?

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.01/

?

For additional replies, please see below.

?

Thanks and regards,

Shashi

?

From: Alexey Ivanov 
Sent: Friday, September 22, 2017 5:19 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Sergey Bylokhov <sergey.bylokhov at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

?

Hi Shashi,

You use EnableMouseInPointer which converts classical WM_MOUSE events to WM_POINTER events. This could have substantial effect on AWT components behaviour. I am worried about High DPI support, drag-and-drop functionality etc.

[Shashi] This is not required and hence removed.

Is there a simpler way to handle double-tap?
Windows converts taps to clicks, i.e. the app receives WM_LBUTTONDOWN and WM_LBUTTONUP.
Have you tried to find out why double-tap is not converted to double-click?

[Shashi] Since the mouse in pointer is disabled and a windows icon behavior is different from a windows button behavior(Because the a touch on the icon does not translate to a left button down event whereas it does for a windows button(file name!!)), it is required to bring in the WM_POINTER message type into the component message handling routine.

Do right and middle mouse buttons continue to work as expected? Mouse wheel? Any additional mouse buttons?

[Shashi] It should not have any effect after mouse in pointer is disabled.

The documentation for EnableMouseInPointer [1] says: ?This function can be called only once in the context of a process lifetime.? You call it for every component created. It would have been enough to call it once during Toolkit initialization.


Regards,
Alexey

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/hh447467(v=vs.85).aspx

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:

Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, September 19, 2017 3:39 AM
To: HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com >> Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface
?
Hi, Shashi.
Why the bug is JFileChooser specific?
Does it means that it works for other elements(buttons/lists/menu/etc)?
?
On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:

Hi All, Please review this software changes for the /_enhancement_/ 
JDK-8178361.
?
Issue: Request was filed to enable the touch event processing for Java 
client applications.
?
Fix: Windows platform offers 'pointer' implementation thro' which one 
can tap for the touch inputs as well. A typical 'pointer' function may 
contain touch, pen, touch pad or mouse inputs. This allows for a 
uniform input processing though the event source may defer. This fix 
enables the 'touch' events(via TOUCH pointer) to be passed to the 
components using the other type of pointer 'mouse'. Essentially there 
is a conversion put in place to convert a touch event input into a 
left click mouse event. I think this is the right thing to do 
considering desktop scenarios to which the typical Java applications 
that gets exposed to. This is also the same behavior on my touch 
enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
?
Now touch event works as a typical mouse left click as in general. But 
there is an issue because the icon size of the Java UI is typically 
small, touching that icon exactly is sometimes difficult. This is 
handled by an Windows application by having larger icon size or icon 
view as a standard. Hence I believe this is outside the scope this 
software update. Any changes to it would be done later as a new bug or 
an enhancement.
?
Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361
?
Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8178361/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
?
Thanks and regards,
?
Shashi
?

?
--
Best regards, Sergey.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170924/27fc6c91/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Mon Sep 25 06:46:55 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Sun, 24 Sep 2017 23:46:55 -0700 (PDT)
Subject: <AWT Dev> FW: [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <cfff084f-cfa6-43c4-91e9-4de9749bc567@default>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
 <957ee779-9a2e-daee-636a-79e8c9522ca3@oracle.com>
 <2fa8e9ea-61e4-4685-b956-fef31b367f2a@default>
 <cfff084f-cfa6-43c4-91e9-4de9749bc567@default>
Message-ID: <79d2250f-e880-40ae-be12-435d1b51978a@default>

Hi Alexey, Please see below for my replies:

[Attachments will be shared upon request as they are of considerable size and cannot be sent to AWT dev group because of the email size limitation.]

Thanks and regards,
Shashi

-----Original Message-----
From: Alexey Ivanov 
Sent: Friday, September 22, 2017 5:26 PM
To: Shashidhara Veerabhadraiah < HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com>; Sergey Bylokhov < HYPERLINK "mailto:sergey.bylokhov at oracle.com" sergey.bylokhov at oracle.com>
Cc:  HYPERLINK "mailto:awt-dev at openjdk.java.net" awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

Hi Shashi,

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.

I cannot grasp the meaning of this sentence.

What are touch click events?
[Shashi] Below are the related macros:
#define WM_LBUTTONDOWN                  0x0201
#define WM_LBUTTONDBLCLK                0x0203

#define WM_POINTERDOWN                   0x0246

[Shashi]  More appropriately, touch double tap events. On a technical note, whenever I did a double tap touch on the folder I could get WM_POINTERDOWN(0x0246) and none of the left button down or left button double click events. I have attached the proof for the same captured as text file(for both touch double tap and a mouse double click events). Please note that this behavior is seen after the removal of EnableMouseInPointer() as it is not required anymore(Please see for the reply to your other email). I could not get left double click event but instead only the left button down events via the mouse double click. I think we use the time gap between the left button down events and then convert to a double click event internally.
[Shashi] So in a way we can conclude that after we do a touch double tap action there was no left button down events that we received. Please note that this is the behavior if we do a double tap touch on the file icon.

What are mouse focus events?
[Shashi] Since there are 2 components in the file chooser. One is the icon and another is the file name. In the Java implementation the file chooser dialog has the icon representations being pretty small and usually it is difficult to exactly tap on the icon!! If there is a touch tap onto the file name we do receive left button down and as well as pointer down messages. I have attached a file containing the proof of it for the same.

[Shashi] This is actually a surprise for me and also tells me that the type of an icon component and the file name components are having different behaviors. I am not sure how I can change this behavior of the icon component.
With this fix, we can touch on all the icons and have the required actions being performed as expected, which was not happening earlier.

So the fix is not JFileChooser-specific, is it?
[Shashi] No it is not. It enables the touch for all the components.

Regards,
Alexey

>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 19, 2017 3:39 AM
> To:  HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com >> Shashidhara 
> Veerabhadraiah < HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com>
> Cc:  HYPERLINK "mailto:awt-dev at openjdk.java.net" awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow 
> to open folders with a double tap when using the touch screen 
> interface
>
> Hi, Shashi.
> Why the bug is JFileChooser specific?
> Does it means that it works for other elements(buttons/lists/menu/etc)?
>
> On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review this software changes for the /_enhancement_/ 
>> JDK-8178361.
>>
>> Issue: Request was filed to enable the touch event processing for 
>> Java client applications.
>>
>> Fix: Windows platform offers 'pointer' implementation thro' which one 
>> can tap for the touch inputs as well. A typical 'pointer' function 
>> may contain touch, pen, touch pad or mouse inputs. This allows for a 
>> uniform input processing though the event source may defer. This fix 
>> enables the 'touch' events(via TOUCH pointer) to be passed to the 
>> components using the other type of pointer 'mouse'. Essentially there 
>> is a conversion put in place to convert a touch event input into a 
>> left click mouse event. I think this is the right thing to do 
>> considering desktop scenarios to which the typical Java applications 
>> that gets exposed to. This is also the same behavior on my touch 
>> enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
>>
>> Now touch event works as a typical mouse left click as in general. 
>> But there is an issue because the icon size of the Java UI is 
>> typically small, touching that icon exactly is sometimes difficult. 
>> This is handled by an Windows application by having larger icon size 
>> or icon view as a standard. Hence I believe this is outside the scope 
>> this software update. Any changes to it would be done later as a new 
>> bug or an enhancement.
>>
>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361
>>
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
>>
>> Thanks and regards,
>>
>> Shashi
>>
>
> --
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170924/3dc7a3a4/attachment-0001.html>

From alexey.ivanov at oracle.com  Mon Sep 25 12:00:47 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 25 Sep 2017 13:00:47 +0100
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <2fa8e9ea-61e4-4685-b956-fef31b367f2a@default>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
 <957ee779-9a2e-daee-636a-79e8c9522ca3@oracle.com>
 <2fa8e9ea-61e4-4685-b956-fef31b367f2a@default>
Message-ID: <4fbead01-484d-a7da-4ffc-799d946e9639@oracle.com>

Hi Shashi,


On 25/09/2017 06:59, Shashidhara Veerabhadraiah wrote:
> RE: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open 
> folders with a double tap when using the touch screen interface
>
> Hi Alexey, Please see below for my replies:
>
> <<...>> <<...>> <<...>>
>
> Thanks and regards,
>
> Shashi
>
> -----Original Message-----
> From:Alexey Ivanov
> Sent:Friday, September 22, 2017 5:26 PM
> To: Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; Sergey Bylokhov 
> <sergey.bylokhov at oracle.com>
> Cc:awt-dev at openjdk.java.net
> Subject:Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to 
> open folders with a double tap when using the touch screen interface
>
> Hi Shashi,
>
> On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:
>
> > Hi Sergey, When I checked it was not working on the Java applications. 
> None of the controls could take touch click events but it used to 
> highlight because when we touch on the touch screen interface the 
> system moves the cursor over to the touch point thereby enabling mouse 
> focus events being sent.
>
> I cannot grasp the meaning of this sentence.
>
> What are touch click events?
>
> */[Shashi]/**/Below are therelatedmacros:/*
>
> #define WM_LBUTTONDOWN????????????????? 0x0201
>
> #define WM_LBUTTONDBLCLK??????????????? 0x0203
>
> #define WM_POINTERDOWN?????????????????? 0x0246
>
> */[Shashi]/*More appropriately, touchdoubletap events.On a technical 
> note,wheneverI did a double tap touch on the folder I could get 
> WM_POINTERDOWN(0x0246)and none of the left button down or left button 
> double click events. I have attached the proof for the same captured 
> as text file(for both touch double tap and a mouse double click 
> events).Please note that this behavior is seen after theremoval 
> ofEnableMouseInPointer() as it is/_not_/ required anymore(Please see 
> for the reply to your other email). I could not get left double click 
> event but instead only the left button down events via the mouse 
> double click. I think we use the time gap between the left button down 
> events and then convert to a double click event internally.
>

Double clicks as |WM_LBUTTONDBLCLK| are never received by AWT windows 
because |CS_DOUBLE| style is not set. The number of clicks is counted in 
|WmMouseDown| and is included in |MouseEvent|.

Yet the complete picture is still unclear to me. So when you double-tap, 
you get |WM_LBUTTONDOWN|, |WM_LBUTTONUP|, and then |WM_POINTERDOWN| 
followed by |WM_POINTERUP|, right?


> */[Shashi]/**/So in a way we can conclude that after we do 
> a/**/touch/**/double ta/**/p action there was no left button down 
> events that we received./**/Please note that this is the behavior if 
> we do a double tap touch/**/_on_/**/the file icon./*
>

Is the behaviour different if you double-tap on another component?

> What are mouse focus events?
>
> */[Shashi]/**/Since there are 2 components in the file chooser. One is 
> the icon and another is the file name. In the Java implementation the 
> file chooser dialog has the icon 
> r/**/epresentations/**/being/**/pretty small and usually it is 
> difficult to exactly/**/tap/**/on the icon!! If there is/**/a/**/touch 
> tap onto the file name we do receive/**/left button down and as well 
> as pointer down messages./**/I have attached a file containing the 
> proof of it for the same./*
>

It's a bit weird.
If you double-click a folder name with mouse, |JFileChooser| opens the 
folder.
If you delay the second click, |JFileChooser| initiates file name editing.
It corresponds to the behaviour of Windows Explorer for example.

When I double-tap a folder name in |JFileChooser|, it usually goes into 
name editing mode. It could be related to the fact that mouse is more 
accurate than a tap: it's easier to double-click than to double-tap. I 
mean that when you double-tap, the coordinates of the second tap could 
be /farther away/ from the first tap. Is it the case?


> */[Shashi]/**/This is actually a surprise for me and als/**/o tells me 
> that the type of an icon component and the file name components are 
> having different/**/behaviors/**/./**/I am not sure how I can change 
> this/**/behaviorof the icon component/**/./*
>
> <<...>>
>
> With this fix,we can touchon all the icons as highlighted aboveand 
> have the required actions being performed as expected, which 
> was/_not_/happening earlier.
>
> So the fix is not JFileChooser-specific, is it?
>
> */[Shashi]/**/No it is not./**/It enables the touch for all the 
> components./*
>

You should've mentioned it in your review request.
Otherwise, it looked as if the change is |JFileChooser| specific because 
you discussed only this component.


Regards,
Alexey


> Regards,
>
> Alexey
>
> >
>
> > Thanks and regards,
>
> > Shashi
>
> >
>
> > -----Original Message-----
>
> > From: Sergey Bylokhov
>
> > Sent: Tuesday, September 19, 2017 3:39 AM
>
> > To:shashidhara.veerabhadraiah at oracle.com<mailto:shashidhara.veerabhadraiah at oracle.com>>> 
> Shashidhara
>
> > Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com<mailto:shashidhara.veerabhadraiah at oracle.com>>
>
> > Cc:awt-dev at openjdk.java.net<mailto:awt-dev at openjdk.java.net>
>
> > Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow
>
> > to open folders with a double tap when using the touch screen
>
> > interface
>
> >
>
> > Hi, Shashi.
>
> > Why the bug is JFileChooser specific?
>
> > Does it means that it works for other elements(buttons/lists/menu/etc)?
>
> >
>
> > On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
>
> >> Hi All, Please review this software changes for the /_enhancement_/
>
> >> JDK-8178361.
>
> >>
>
> >> Issue: Request was filed to enable the touch event processing for
>
> >> Java client applications.
>
> >>
>
> >> Fix: Windows platform offers 'pointer' implementation thro' which one
>
> >> can tap for the touch inputs as well. A typical 'pointer' function
>
> >> may contain touch, pen, touch pad or mouse inputs. This allows for a
>
> >> uniform input processing though the event source may defer. This fix
>
> >> enables the 'touch' events(via TOUCH pointer) to be passed to the
>
> >> components using the other type of pointer 'mouse'. Essentially there
>
> >> is a conversion put in place to convert a touch event input into a
>
> >> left click mouse event. I think this is the right thing to do
>
> >> considering desktop scenarios to which the typical Java applications
>
> >> that gets exposed to. This is also the same behavior on my touch
>
> >> enabled windows 10 laptop as well. Please let me know if a different 
> behavior is expected. Below is the output:
>
> >>
>
> >> Now touch event works as a typical mouse left click as in general.
>
> >> But there is an issue because the icon size of the Java UI is
>
> >> typically small, touching that icon exactly is sometimes difficult.
>
> >> This is handled by an Windows application by having larger icon size
>
> >> or icon view as a standard. Hence I believe this is outside the scope
>
> >> this software update. Any changes to it would be done later as a new
>
> >> bug or an enhancement.
>
> >>
>
> >> Bug ID:https://bugs.openjdk.java.net/browse/JDK-8178361
>
> >>
>
> >> Webrev:http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/<http://cr.openjdk.java.net/%7Esveerabhadra/8178361/webrev.00/>
>
> >>
>
> >> Thanks and regards,
>
> >>
>
> >> Shashi
>
> >>
>
> >
>
> > --
>
> > Best regards, Sergey.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170925/a5333f2e/attachment-0001.html>

From alexander.zvegintsev at oracle.com  Mon Sep 25 12:05:11 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 25 Sep 2017 17:35:11 +0530
Subject: <AWT Dev> [10] Review request for 8185634,
 8185634: Java Fx-Swing dialogs appearing behind main stage
In-Reply-To: <F5964E0F-A0A7-49BE-B056-8E590B0C8559@oracle.com>
References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com>
 <c10968d7-af0b-d599-6620-dd95e4d7af12@oracle.com>
 <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
 <F5964E0F-A0A7-49BE-B056-8E590B0C8559@oracle.com>
Message-ID: <dc5e5f35-38ee-b1a0-d5e0-408e8fdc25c1@oracle.com>

Hi Dmitry,

 From my understanding JavaFX stage can't be easily integrated in JDK to 
support orderWindow() approach,

addChildWindow() is a native(and the simplest) way to maintain one 
window above other one, should be called only once.

IIUC the main concert of JDK-8080729 that child windows jumping to 
parent's display upon focus receiving, this is not an issue with current 
fix,

because addChildWindow() will be called only upon dialog creation in 
case of JavaFX-Swing interop.

Jump may happen if user want to create a child swing dialog on display 
other than JavaFX stage's one,

but such rare scenario can be easily workarounded on a user side by 
calling setLocation() right after setVisible() call.

So I would prefer to use addChildWindow() to make this fix as simple as 
possible.


Thanks,
Alexander.

On 23/09/2017 21:21, Dmitry Markov wrote:
> Hi Alexander,
>
> In CPlatformWindow class you call CWrapper.NSWindow.addChildWindow() to place a window above JavaFX stage. The usage of addChilWindow() or/and removeChildWindow() may cause ?jumping window issue? in multi-monitor environment, see JDK-8080729 for more details.
>
> To avoid possible problems in multi monitor set-up I suggest that you should replace addChildWindow() with orderWindow() or use some another approach to locate the window above the stage.
>
> Thanks,
> Dmitry
>> On 22 Sep 2017, at 06:56, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
>>
>> Hi Phil,
>>
>> Please review the updated fix with reflection incorporated
>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/
>>
>> New issue created JDK-8187803 <https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart of this issue.
>>
>> Thanks,
>> Alexander.
>>
>> On 21/09/2017 22:25, Phil Race wrote:
>>> Some procedural comments :
>>> Since 90% of this is in AWT code, I'd have thought awt-dev should be included here.
>>> I've added that list.
>>>
>>> And apart from needing separate bug ids, I don't see why the bug below is confidential.
>>>
>>>
>>> I agree with what Kevin pointed out off-line that as in the dialog case, the FX side
>>> of the code can use reflection and simply be a harmless non-functional no-op
>>> if the SwingAccessor does not provide the new method.
>>>
>>> BTW
>>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
>>> should be "dd" not "d".
>>>
>>> -phil.
>>>
>>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:
>>>> Hello,
>>>>
>>>> please review the fix
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/
>>>>
>>>> for the issue
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8185634
>>>>


From alexander.zvegintsev at oracle.com  Mon Sep 25 12:06:43 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 25 Sep 2017 17:36:43 +0530
Subject: <AWT Dev> [10] Review request for 8185634,
 8185634: Java Fx-Swing dialogs appearing behind main stage
In-Reply-To: <7c868789-6c1e-28c9-af7a-057d551e0dfe@oracle.com>
References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com>
 <c10968d7-af0b-d599-6620-dd95e4d7af12@oracle.com>
 <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
 <7c868789-6c1e-28c9-af7a-057d551e0dfe@oracle.com>
Message-ID: <14319a76-ca8c-c0a9-008e-cfe950b9df33@oracle.com>

Hi Sergey,

Thanks for catching this, this is an issue which should be addressed.

Thanks,
Alexander.

On 23/09/2017 08:01, Sergey Bylokhov wrote:
> Hi, Alexander.
> How can we be sure that the parent frame will not be disposed while we 
> use a pointer?
>
> long ownerWindowPtr = peer.getOverridenWindowHandle();
> <<<<< Dispose the peer
> if (ownerWindowPtr != 0) {
> ??? //Place window above JavaFX stage
> ??? CWrapper.NSWindow.addChildWindow(
> ??? ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
> <<<<< Boom
> }
>
>
> On 9/21/17 22:56, Alexander Zvegintsev wrote:
>> Hi Phil,
>>
>> Please review the updated fix with reflection incorporated
>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/
>>
>> New issue created JDK-8187803 
>> <https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart 
>> of this issue.
>>
>> Thanks,
>> Alexander.
>>
>> On 21/09/2017 22:25, Phil Race wrote:
>>> Some procedural comments :
>>> Since 90% of this is in AWT code, I'd have thought awt-dev should be 
>>> included here.
>>> I've added that list.
>>>
>>> And apart from needing separate bug ids, I don't see why the bug 
>>> below is confidential.
>>>
>>>
>>> I agree with what Kevin pointed out off-line that as in the dialog 
>>> case, the FX side
>>> of the code can use reflection and simply be a harmless 
>>> non-functional no-op
>>> if the SwingAccessor does not provide the new method.
>>>
>>> BTW
>>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
>>> should be "dd" not "d".
>>>
>>> -phil.
>>>
>>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:
>>>> Hello,
>>>>
>>>> please review the fix
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/
>>>>
>>>> for the issue
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8185634
>>>>
>>>
>>
>
>


From semyon.sadetsky at oracle.com  Mon Sep 25 14:58:38 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 25 Sep 2017 07:58:38 -0700
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
Message-ID: <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>

Hi Dmitry,

This issue was already fixed in 9. See 8139218 & 8159432.

--Semyon


On 09/23/2017 08:25 AM, Dmitry Markov wrote:
> Hello,
>
> Could you review a fix for jdk10, please?
>
>    bug: https://bugs.openjdk.java.net/browse/JDK-8155197
>    webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.00/
>
> Problem description:
> Currently we restore focus synchronously to a component if the window (which contains it) owns the focus. However if another window/dialog is displayed at the same time, the first window loses focus, (i.e. synchronous focus request failed) and the focus target is shifted to the next component in the focus traversal cycle.
>
> Fix:
> It is necessary to check the result of synchronous focus request for a component. If the focus request?s failed because the contained window lost focus, we should restore focus to this component next time when its parent window obtains focus.
>
> Testing:
> I ran corresponding JCK and regression tests and did not observe any new failures.
>
> Thanks,
> Dmitry


From semyon.sadetsky at oracle.com  Mon Sep 25 15:36:47 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 25 Sep 2017 08:36:47 -0700
Subject: <AWT Dev> [10] Review request for 8185634,
 8185634: Java Fx-Swing dialogs appearing behind main stage
In-Reply-To: <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com>
 <c10968d7-af0b-d599-6620-dd95e4d7af12@oracle.com>
 <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
Message-ID: <596225fc-d924-8bab-bbd1-5bb73398d32d@oracle.com>

Hi Alexander,

On the Windows platform you've only modified the dialog native peer 
while on other platforms all window types are modified to use FX window 
as a parent. Shouldn't the frame native peer  be modified too on the 
Windows platform?

--Semyon


On 09/21/2017 10:56 PM, Alexander Zvegintsev wrote:
>
> Hi Phil,
>
> Please review the updated fix with reflection incorporated
> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/
>
> New issue created JDK-8187803 
> <https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart 
> of this issue.
>
> Thanks,
> Alexander.
> On 21/09/2017 22:25, Phil Race wrote:
>> Some procedural comments :
>> Since 90% of this is in AWT code, I'd have thought awt-dev should be 
>> included here.
>> I've added that list.
>>
>> And apart from needing separate bug ids, I don't see why the bug 
>> below is confidential.
>>
>>
>> I agree with what Kevin pointed out off-line that as in the dialog 
>> case, the FX side
>> of the code can use reflection and simply be a harmless 
>> non-functional no-op
>> if the SwingAccessor does not provide the new method.
>>
>> BTW
>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
>> should be "dd" not "d".
>>
>> -phil.
>>
>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:
>>> Hello,
>>>
>>> please review the fix
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8185634
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170925/dd5c39f0/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Sep 25 16:08:53 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 Sep 2017 09:08:53 -0700
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
Message-ID: <8b23d799-41aa-d0fb-9373-13f0069acebe@oracle.com>

Looks fine.

On 9/23/17 08:25, Dmitry Markov wrote:
> Hello,
> 
> Could you review a fix for jdk10, please?
> 
>    bug: https://bugs.openjdk.java.net/browse/JDK-8155197
>    webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.00/
> 
> Problem description:
> Currently we restore focus synchronously to a component if the window (which contains it) owns the focus. However if another window/dialog is displayed at the same time, the first window loses focus, (i.e. synchronous focus request failed) and the focus target is shifted to the next component in the focus traversal cycle.
> 
> Fix:
> It is necessary to check the result of synchronous focus request for a component. If the focus request?s failed because the contained window lost focus, we should restore focus to this component next time when its parent window obtains focus.
> 
> Testing:
> I ran corresponding JCK and regression tests and did not observe any new failures.
> 
> Thanks,
> Dmitry
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep 25 16:21:31 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 Sep 2017 09:21:31 -0700
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
In-Reply-To: <2df0d688-5111-3320-d287-d3500dd3ffaa@oracle.com>
References: <bc568398-c4e4-41de-be9a-b2f3c57832fb@default>
 <dc2d8bd8-9c61-ab13-1405-1338920f9fca@oracle.com>
 <a19185ff-acca-a2ed-a69d-ab0fe7fba753@oracle.com>
 <d3727c16-5845-1baf-0700-513b7ff09ec9@oracle.com>
 <98abeab4-f831-a724-dae0-6745df63dfc0@oracle.com>
 <2df0d688-5111-3320-d287-d3500dd3ffaa@oracle.com>
Message-ID: <b4a64b90-e2db-291b-54b0-98399e0195c2@oracle.com>

 From the AWT point of view the fix looks fine.

On 9/23/17 00:03, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> Please find modified webrev catering to DefaultKeyboardFocusManager also
> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.05/
> 
> Regards
> Prasanta
> On 9/23/2017 7:52 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>>
>> On 9/19/17 22:26, Prasanta Sadhukhan wrote:
>>>> Hi, Prasanta.
>>>> ?- In this version it is unclear what is a purpose of the 
>>>> "fxCheckSequenceThread.start()". This code will start the thread and 
>>>> will continue execution, it will not wait when the thread will stop.
>>>> ?- The DefaultKeyboardFocusManager also should check for 
>>>> "javafx.embed.singleThread"
>>>>
>>> Please find modified webrev catering to both comments
>>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.04/
>>
>> The new code in DefaultKeyboardFocusManager also will not wait when 
>> the thread will stop.
>>
>>>
>>> Regards
>>> Prasanta
>>>>
>>>> On 9/13/17 03:11, Prasanta Sadhukhan wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> I have modified the fix to not use SecondaryLoop and not to create 
>>>>> one thread per dispatch
>>>>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 8/30/2017 11:41 AM, Sergey Bylokhov wrote:
>>>>>> Hi, Prasanta.
>>>>>> Can you please provide some description on how the SecondaryLoop 
>>>>>> will work when it will run on Appkit thread? Is it possible to get 
>>>>>> a deadlock here, since appkit will be blocked?
>>>>>>
>>>>>>> sequence, ie if the event is not first in sequence, then it will 
>>>>>>> made
>>>>>>> to
>>>>>>> wait till it is the first event or till it is disposed.
>>>>>> Note that the new code (unlike lines 139-150) also waits 1 second, 
>>>>>> so we can get a situation when only one event will be dispatched 
>>>>>> per second, which is not we want to do.
>>>>>> I am not sure how often we create SequencedEvent but creating one 
>>>>>> thread per dispatch look inefficient.
>>>>>>
>>>>>>
>>>>>>> Modified webrev
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Prasanta.
>>>>>>>>
>>>>>>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
>>>>>>>>> Now, since here FX App thread itself is the dispatch thread, we 
>>>>>>>>> can
>>>>>>>>> be sure the events are dispatched in sequence and dispose is
>>>>>>> checked
>>>>>>>>> below after EDT.
>>>>>>>> Why we can sure about this? If the SequencedEvents were created in
>>>>>>> one
>>>>>>>> order but dispatch() for each were called in other order then the
>>>>>>>> sequenced will not be preserved?
>>>>>>>>
>>>>>>>>> I have tested with couple of singleThread testcase without any
>>>>>>> issue.
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
>>>>>>>>>> Hi, Prasanta, Kevin.
>>>>>>>>>>
>>>>>>>>>> I have two notes.
>>>>>>>>>> ?? - Does this option is really supported? If it is supported we
>>>>>>>>>> should evaluate all usage of EventDispatchThread because in this
>>>>>>>>>> mode the dispatch thread is not EDT. For example I am not sure
>>>>>>> that
>>>>>>>>>> we can skip the code which expects EventDispatchThread.
>>>>>>>>>> ?? - We have the similar pattern: 
>>>>>>>>>> "EventQueue.isDispatchThread() ->
>>>>>>>>>> cast(EventDispatchThread)" in some other places like in
>>>>>>>>>> DefaultKeyboardFocusManager.
>>>>>>>>>>
>>>>>>>>>> -----prasanta.sadhukhan at oracle.com? wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Please review this fix
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>>>>>>>>>>> for an fx issue
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>>>>>>>>>>
>>>>>>>>>>> More info in JBS.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep 25 16:30:32 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 Sep 2017 09:30:32 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch
 keyboard is not shown for text components on a screen touch
In-Reply-To: <6f3177ec-2915-0004-bbd2-11232e2338c6@oracle.com>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
 <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
 <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
 <6f3177ec-2915-0004-bbd2-11232e2338c6@oracle.com>
Message-ID: <35aac19c-ee68-0d6b-319d-1343e59cb5c4@oracle.com>

Looks fine.

On 9/21/17 17:39, Anton Litvinov wrote:
> Could you please answer my question.
> - Should CCC request be filed for the new system property 
> "awt.touchKeyboardAutoShowIsEnable", whose value is considered as "true" 
> by default, if it is not specified by the user explicitly while 
> launching a Java application?

I suggest to create a CSR, because this fix introduce some behavior 
change(it does not mean that we will make this property public).


-- 
Best regards, Sergey.

From anton.litvinov at oracle.com  Mon Sep 25 18:49:39 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Mon, 25 Sep 2017 19:49:39 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch
 keyboard is not shown for text components on a screen touch
In-Reply-To: <35aac19c-ee68-0d6b-319d-1343e59cb5c4@oracle.com>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
 <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
 <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
 <6f3177ec-2915-0004-bbd2-11232e2338c6@oracle.com>
 <35aac19c-ee68-0d6b-319d-1343e59cb5c4@oracle.com>
Message-ID: <a4a2249f-3853-e3d1-ba35-df97b5c60b8e@oracle.com>

Hello Sergey,

Thank you for approval of the fix. Yes, sure, I will file a CSR. Do you 
suggest to file a CSR about the new property 
"awt.touchKeyboardAutoShowIsEnabled" or the whole functionality 
implemented in this fix, particularly - support of automatic showing of 
the touch keyboard without mentioning of this new system property?

Thank you,
Anton

On 25/09/2017 17:30, Sergey Bylokhov wrote:
> Looks fine.
>
> On 9/21/17 17:39, Anton Litvinov wrote:
>> Could you please answer my question.
>> - Should CCC request be filed for the new system property 
>> "awt.touchKeyboardAutoShowIsEnable", whose value is considered as 
>> "true" by default, if it is not specified by the user explicitly 
>> while launching a Java application?
>
> I suggest to create a CSR, because this fix introduce some behavior 
> change(it does not mean that we will make this property public).
>
>


From shashidhara.veerabhadraiah at oracle.com  Mon Sep 25 05:59:30 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Sun, 24 Sep 2017 22:59:30 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <957ee779-9a2e-daee-636a-79e8c9522ca3@oracle.com>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
 <957ee779-9a2e-daee-636a-79e8c9522ca3@oracle.com>
Message-ID: <2fa8e9ea-61e4-4685-b956-fef31b367f2a@default>

Hi Alexey, Please see below for my replies:
   
Thanks and regards,
Shashi

-----Original Message-----
From: Alexey Ivanov 
Sent: Friday, September 22, 2017 5:26 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Sergey Bylokhov <sergey.bylokhov at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

Hi Shashi,

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.

I cannot grasp the meaning of this sentence.

What are touch click events?
[Shashi] Below are the related macros:
#define WM_LBUTTONDOWN                  0x0201
#define WM_LBUTTONDBLCLK                0x0203

#define WM_POINTERDOWN                   0x0246

[Shashi]  More appropriately, touch double tap events. On a technical note, whenever I did a double tap touch on the folder I could get WM_POINTERDOWN(0x0246) and none of the left button down or left button double click events. I have attached the proof for the same captured as text file(for both touch double tap and a mouse double click events). Please note that this behavior is seen after the removal of EnableMouseInPointer() as it is not required anymore(Please see for the reply to your other email). I could not get left double click event but instead only the left button down events via the mouse double click. I think we use the time gap between the left button down events and then convert to a double click event internally.
[Shashi] So in a way we can conclude that after we do a touch double tap action there was no left button down events that we received. Please note that this is the behavior if we do a double tap touch on the file icon.

What are mouse focus events?
[Shashi] Since there are 2 components in the file chooser. One is the icon and another is the file name. In the Java implementation the file chooser dialog has the icon representations being pretty small and usually it is difficult to exactly tap on the icon!! If there is a touch tap onto the file name we do receive left button down and as well as pointer down messages. I have attached a file containing the proof of it for the same.

[Shashi] This is actually a surprise for me and also tells me that the type of an icon component and the file name components are having different behaviors. I am not sure how I can change this behavior of the icon component.
 
With this fix, we can touch on all the icons as highlighted above and have the required actions being performed as expected, which was not happening earlier.

So the fix is not JFileChooser-specific, is it?
[Shashi] No it is not. It enables the touch for all the components.

Regards,
Alexey

>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 19, 2017 3:39 AM
> To:  HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com >> Shashidhara 
> Veerabhadraiah < HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com>
> Cc:  HYPERLINK "mailto:awt-dev at openjdk.java.net" awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow 
> to open folders with a double tap when using the touch screen 
> interface
>
> Hi, Shashi.
> Why the bug is JFileChooser specific?
> Does it means that it works for other elements(buttons/lists/menu/etc)?
>
> On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review this software changes for the /_enhancement_/ 
>> JDK-8178361.
>>
>> Issue: Request was filed to enable the touch event processing for 
>> Java client applications.
>>
>> Fix: Windows platform offers 'pointer' implementation thro' which one 
>> can tap for the touch inputs as well. A typical 'pointer' function 
>> may contain touch, pen, touch pad or mouse inputs. This allows for a 
>> uniform input processing though the event source may defer. This fix 
>> enables the 'touch' events(via TOUCH pointer) to be passed to the 
>> components using the other type of pointer 'mouse'. Essentially there 
>> is a conversion put in place to convert a touch event input into a 
>> left click mouse event. I think this is the right thing to do 
>> considering desktop scenarios to which the typical Java applications 
>> that gets exposed to. This is also the same behavior on my touch 
>> enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
>>
>> Now touch event works as a typical mouse left click as in general. 
>> But there is an issue because the icon size of the Java UI is 
>> typically small, touching that icon exactly is sometimes difficult. 
>> This is handled by an Windows application by having larger icon size 
>> or icon view as a standard. Hence I believe this is outside the scope 
>> this software update. Any changes to it would be done later as a new 
>> bug or an enhancement.
>>
>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361
>>
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
>>
>> Thanks and regards,
>>
>> Shashi
>>
>
> --
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170924/63f43c09/attachment-0001.html>
-------------- next part --------------
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp

 Component event:70
 Component event:36
 Component event:70
 Component event:36
 Component event:799
 Component event:38923
 Component event:70
 Component event:36
 Component event:131
 Component event:71
 Component event:5
 Component event:48
 Component event:128
 Component event:128
 Component event:12
 Component event:124
 Component event:125
 Component event:131
 Component event:71
 Component event:70
 Component event:131
 Component event:71
 Component event:128
 Component event:128
 Component event:799
 Component event:48
 Component event:38923
 Component event:70
 Component event:131
 Component event:71
 Component event:5
 Component event:48
 Component event:128
 Component event:128
 Component event:12
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:124
 Component event:131
 Component event:71
 Component event:125
 Component event:128
 Component event:128
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:131
 Component event:71
 Component event:38923
 Component event:70
 Component event:36
 Component event:131
 Component event:71
 Component event:5
 Component event:38925
 Component event:38926
 Component event:38925
 Component event:38926
 Component event:38923
 Component event:70
 Component event:36
 Component event:131
 Component event:71
 Component event:3
 Component event:5
 Component event:38925
 Component event:38926
 Component event:38925
 Component event:38926
 Component event:38925
 Component event:38926
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:38916
 Component event:24
 Component event:70
 Component event:70
 Component event:28
 Component event:28
 Component event:134
 Component event:6
 Component event:641
 Component event:642
 Component event:70
 Component event:70
 Component event:133
 Component event:20
 Component event:71
 Component event:124
 Component event:15
 Component event:125
 Component event:128
 Component event:128
 Component event:132
 Component event:15
 Component event:133
 Component event:132
 Component event:38925
 Component event:132
 Component event:132
 Component event:38926
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:61
 Component event:61
 Component event:61
 Component event:61
 Component event:356
 Component event:49293
 Component event:132
 Component event:32
 Component event:132
 Component event:38914
 Component event:512
 Component event:38958
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:38919
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 ComJComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 249b9c5f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
ponent event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component eJComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 5ac30ec1,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
Listener:mouse
Listener:focus
Listener:comp
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 5ac30ec1,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
vent:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:641
 Component event:641
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:38918
 Component event:7
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component eveJComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 5ac30ec1,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:focus
Listener:focus
JComp Childs: sun.swing.FilePane$4[,0,0,1734x143,alignmentX=0.0,alignmentY=0.0,border=,flags=58720552,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=1],Parent:javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false]
JComp Childs: javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],Parent:javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 249b9c5f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=]
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 249b9c5f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
JComp Childs: sun.swing.FilePane$4[,0,0,1734x143,alignmentX=0.0,alignmentY=0.0,border=,flags=58720552,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=1],Parent:javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false]
JComp Childs: javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],Parent:javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 249b9c5f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=]
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 249b9c5f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
Listener:mouse
JComp Childs: sun.swing.FilePane$4[,0,0,1734x143,alignmentX=0.0,alignmentY=0.0,border=,flags=58720552,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=1],Parent:javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false]
JComp Childs: javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],Parent:javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 249b9c5f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=]
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 249b9c5f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$1[,56,0,275x29,layout=javax.swing.plaf.metal.MetalComboBoxUI$MetalComboBoxLayoutManager,alignmentX=0.0,alignmentY=0.0,border=,flags=328,maximumSize=,minimumSize=,preferredSize=,isEditable=false,lightWeightPopupEnabled=true,maximumRowCount=8,selectedItemReminder=C:\ProgramData\Oracle\Baseimage\Desktop Tools],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.JButton[,0,2,24x24,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 24344653,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=sun.swing.ImageIconUIResource at 197a0fd6,disabledIcon=sun.swing.ImageIconUIResource at 73adeb89,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=null,defaultCapable=true],Parent:javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:comp
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 249b9c5f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x158,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: sun.swing.FilePane$4[,0,0,474x158,alignmentX=0.0,alignmentY=0.0,border=,flags=58720552,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=1],Parent:javax.swing.JViewport[,1,1,474x158,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false]
JComp Childs: javax.swing.JViewport[,1,1,474x158,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],Parent:javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 249b9c5f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x158,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=]
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 249b9c5f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x158,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:comp
nt:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:513
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:38918
 Component event:8
 Component event:641
 Component event:641
 Component event:641
 Component event:641
 Component event:38918
 Component event:7
 Component event:132
 Component event:514
 Component event:533
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:513
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:514
 Component event:533
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 ComponListener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
ent event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 ComListener:mouse
Listener:mouse
JComp Childs: javax.swing.plaf.metal.MetalComboBoxButton[,255,0,20x29,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 24344653,flags=12583208,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=1,bottom=1,right=3],paintBorder=true,paintFocus=false,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true],Parent:javax.swing.plaf.metal.MetalFileChooserUI$1[,56,0,275x29,layout=javax.swing.plaf.metal.MetalComboBoxUI$MetalComboBoxLayoutManager,alignmentX=0.0,alignmentY=0.0,border=,flags=328,maximumSize=,minimumSize=,preferredSize=,isEditable=false,lightWeightPopupEnabled=true,maximumRowCount=8,selectedItemReminder=C:\ProgramData\Oracle\Baseimage\Desktop Tools]
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$1[,56,0,275x29,layout=javax.swing.plaf.metal.MetalComboBoxUI$MetalComboBoxLayoutManager,alignmentX=0.0,alignmentY=0.0,border=,flags=328,maximumSize=,minimumSize=,preferredSize=,isEditable=false,lightWeightPopupEnabled=true,maximumRowCount=8,selectedItemReminder=C:\ProgramData\Oracle\Baseimage\Desktop Tools],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
JComp Childs: javax.swing.plaf.metal.MetalComboBoxButton[,255,0,20x29,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 24344653,flags=12583208,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=1,bottom=1,right=3],paintBorder=true,paintFocus=false,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true],Parent:javax.swing.plaf.metal.MetalFileChooserUI$1[,56,0,275x29,layout=javax.swing.plaf.metal.MetalComboBoxUI$MetalComboBoxLayoutManager,alignmentX=0.0,alignmentY=0.0,border=,flags=328,maximumSize=,minimumSize=,preferredSize=,isEditable=false,lightWeightPopupEnabled=true,maximumRowCount=8,selectedItemReminder=C:\ProgramData\Oracle\Baseimage\Desktop Tools]
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$1[,56,0,275x29,layout=javax.swing.plaf.metal.MetalComboBoxUI$MetalComboBoxLayoutManager,alignmentX=0.0,alignmentY=0.0,border=,flags=328,maximumSize=,minimumSize=,preferredSize=,isEditable=false,lightWeightPopupEnabled=true,maximumRowCount=8,selectedItemReminder=C:\ProgramData\Oracle\Baseimage\Desktop Tools],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
JComp Childs: javax.swing.JButton[,0,2,24x24,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 24344653,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=sun.swing.ImageIconUIResource at 197a0fd6,disabledIcon=sun.swing.ImageIconUIResource at 73adeb89,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=null,defaultCapable=true],Parent:javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
JComp Childs: javax.swing.JButton[,0,2,24x24,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 24344653,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=sun.swing.ImageIconUIResource at 197a0fd6,disabledIcon=sun.swing.ImageIconUIResource at 73adeb89,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=null,defaultCapable=true],Parent:javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.JButton[,29,2,24x24,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 24344653,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=sun.swing.ImageIconUIResource at 63fdb93f,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true],Parent:javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
JComp Childs: javax.swing.JButton[,29,2,24x24,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 24344653,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=sun.swing.ImageIconUIResource at 63fdb93f,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true],Parent:javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
ponent event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
JComp Childs: javax.swing.JButton[,58,2,24x24,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 24344653,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=sun.swing.ImageIconUIResource at 3851a28,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=null,defaultCapable=true],Parent:javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
JComp Childs: javax.swing.JButton[,58,2,24x24,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 24344653,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=sun.swing.ImageIconUIResource at 3851a28,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=null,defaultCapable=true],Parent:javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 2066c60d,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:focus
Listener:comp
132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:38915
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:161
 Component event:533
 Component event:174
 Component event:174
 Component event:174
 Component event:274
 Component event:16
 Component event:674
 Component event:32
 Component event:160
 Component event:38917
 Component event:24
 Component event:70
 Component event:70
 Component event:71
 Component event:134
 Component event:6
 Component event:28
 Component event:28
 Component event:641
 Component event:642
 Component event:674
 Component event:38918
 Component event:8
 Component event:38960
 Component event:38960
-------------- next part --------------
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 2fd7d1f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 76494711,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:focus
Listener:comp
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 76494711,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 76494711,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 76494711,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 76494711,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
Listener:focus
Listener:focus
JComp Childs: sun.swing.FilePane$4[,0,0,1734x143,alignmentX=0.0,alignmentY=0.0,border=,flags=58720552,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=1],Parent:javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false]
JComp Childs: javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],Parent:javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 2fd7d1f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=]
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 2fd7d1f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse

 Component event:70
 Component event:36
 Component event:70
 Component event:36
 Component event:799
 Component event:38923
 Component event:70
 Component event:36
 Component event:131
 Component event:71
 Component event:5
 Component event:48
 Component event:128
 Component event:128
 Component event:12
 Component event:124
 Component event:125
 Component event:131
 Component event:71
 Component event:70
 Component event:131
 Component event:71
 Component event:128
 Component event:128
 Component event:799
 Component event:48
 Component event:38923
 Component event:70
 Component event:131
 Component event:71
 Component event:5
 Component event:48
 Component event:128
 Component event:128
 Component event:12
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:124
 Component event:131
 Component event:71
 Component event:125
 Component event:128
 Component event:128
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:131
 Component event:71
 Component event:38923
 Component event:70
 Component event:36
 Component event:131
 Component event:71
 Component event:5
 Component event:38925
 Component event:38926
 Component event:38925
 Component event:38926
 Component event:38923
 Component event:70
 Component event:36
 Component event:131
 Component event:71
 Component event:3
 Component event:5
 Component event:38925
 Component event:38926
 Component event:38925
 Component event:38926
 Component event:38925
 Component event:38926
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:38916
 Component event:24
 Component event:70
 Component event:70
 Component event:28
 Component event:28
 Component event:134
 Component event:6
 Component event:641
 Component event:642
 Component event:70
 Component event:70
 Component event:133
 Component event:20
 Component event:71
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:15
 Component event:133
 Component event:61
 Component event:61
 Component event:61
 Component event:61
 Component event:38925
 Component event:356
 Component event:49293
 Component event:38926
 Component event:38958
 Component event:38919
 Component event:641
 Component event:641
 Component event:38918
 Component event:7
 Component event:132
 Component event:132
 Component event:585
 Component event:582
 Component event:49306
 Component event:581
 Component event:581
 Component event:38918
 Component event:8
 Component event:581
 Component event:641
 Component event:641
 Component event:641
 Component event:641
 Component event:38918
 Component event:7
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:583
 Component event:61
 Component event:61
 Component event:61
 Component event:356
 Component event:49306
 Component event:586
 Component event:132
 Component event:132
 Component event:585
 Component event:582
 Component event:49306
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:583
 Component event:61
 Component event:61
 Component event:61
 Component event:356
 Component event:49306
 Component event:586
 Component event:132
 Component event:132
 Component event:585
 Component event:582
 Component event:49306
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:583
 Component event:61
 Component event:61
 Component event:61
 Component event:356
 Component event:49306
 Component event:586
 Component event:132
 Component event:132
 Component event:585
 Component event:582
 Component event:49306
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:581
 Component event:583
 Component event:533
 Component event:61
 Component event:61
 Component event:61
 Component event:356
 Component event:49306
 ComponListener:mouse
JComp Childs: sun.swing.FilePane$4[,0,0,1734x143,alignmentX=0.0,alignmentY=0.0,border=,flags=58720552,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=1],Parent:javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false]
JComp Childs: javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],Parent:javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 2fd7d1f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=]
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 2fd7d1f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.JButton[,0,2,24x24,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at ad2f208,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=sun.swing.ImageIconUIResource at 237c5c48,disabledIcon=sun.swing.ImageIconUIResource at dd63534,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=null,defaultCapable=true],Parent:javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,342,0,135x29,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$1[,56,0,275x29,layout=javax.swing.plaf.metal.MetalComboBoxUI$MetalComboBoxLayoutManager,alignmentX=0.0,alignmentY=0.0,border=,flags=328,maximumSize=,minimumSize=,preferredSize=,isEditable=false,lightWeightPopupEnabled=true,maximumRowCount=8,selectedItemReminder=C:\ProgramData\Oracle\Baseimage\Desktop Tools],Parent:javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,12,477x29,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:comp
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 2fd7d1f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x158,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: sun.swing.FilePane$4[,0,0,474x158,alignmentX=0.0,alignmentY=0.0,border=,flags=58720552,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=1],Parent:javax.swing.JViewport[,1,1,474x158,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false]
JComp Childs: javax.swing.JViewport[,1,1,474x158,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],Parent:javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 2fd7d1f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x158,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=]
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 2fd7d1f,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x158,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 1e4a0373,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\ProgramData\Oracle\Baseimage\Desktop Tools,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:comp
Listener:focus
Listener:comp
ent event:586
 Component event:132
 Component event:32
 Component event:174
 Component event:174
 Component event:174
 Component event:132
 Component event:160
 Component event:132
 Component event:32
 Component event:132
 Component event:160
 Component event:132
 Component event:32
 Component event:132
 Component event:160
 Component event:132
 Component event:32
 Component event:132
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:160
 Component event:32
 Component event:161
 Component event:533
 Component event:274
 Component event:16
 Component event:674
 Component event:32
 Component event:160
 Component event:38917
 Component event:24
 Component event:70
 Component event:70
 Component event:71
 Component event:134
 Component event:6
 Component event:28
 Component event:28
 Component event:641
 Component event:642
 Component event:674
 Component event:38918
 Component event:8
 Component event:38960
 Component event:38960
-------------- next part --------------
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:comp
Listener:mouse
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 3c94e74d,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 32a128e5,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:focus
Listener:comp
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 32a128e5,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
JComp Childs: javax.swing.plaf.metal.MetalFileChooserUI$3[,87,0,390x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 32a128e5,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=35,columnWidth=10,command=,horizontalAlignment=LEADING],Parent:javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x20,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,12,224,477x93,layout=javax.swing.BoxLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
Listener:mouse
Listener:focus
Listener:focus
JComp Childs: sun.swing.FilePane$4[,0,0,1734x143,alignmentX=0.0,alignmentY=0.0,border=,flags=58720552,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=1],Parent:javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false]
JComp Childs: javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],Parent:javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 3c94e74d,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=]
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 3c94e74d,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Listener:mouse
Listener:mouse
Listener:mouse
JComp Childs: sun.swing.FilePane$4[,0,0,1734x143,alignmentX=0.0,alignmentY=0.0,border=,flags=58720552,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=1],Parent:javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false]
JComp Childs: javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],Parent:javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 3c94e74d,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=]
JComp Childs: javax.swing.JScrollPane[,0,0,477x161,layout=javax.swing.ScrollPaneLayout$UIResource,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$ScrollPaneBorder at 3c94e74d,flags=8388936,maximumSize=,minimumSize=,preferredSize=,columnHeader=,horizontalScrollBar=javax.swing.JScrollPane$ScrollBar[,1,144,474x15,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1],horizontalScrollBarPolicy=HORIZONTAL_SCROLLBAR_AS_NEEDED,lowerLeft=,lowerRight=,rowHeader=,upperLeft=,upperRight=,verticalScrollBar=javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=javax.swing.plaf.metal.MetalScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=12583240,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1],verticalScrollBarPolicy=VERTICAL_SCROLLBAR_AS_NEEDED,viewport=javax.swing.JViewport[,1,1,474x143,layout=javax.swing.ViewportLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=25165832,maximumSize=,minimumSize=,preferredSize=,isViewSizeSet=true,lastPaintPosition=java.awt.Point[x=0,y=0],scrollUnderway=false],viewportBorder=],Parent:javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[,0,0,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=8388617,maximumSize=,minimumSize=,preferredSize=],Parent:sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]]
JComp Childs: sun.swing.FilePane[,12,52,477x161,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=265,maximumSize=,minimumSize=,preferredSize=java.awt.Dimension[width=405,height=135]],Parent:javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false]
JComp Childs: javax.swing.JFileChooser[,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.border.EmptyBorder at 274da46f,flags=320,maximumSize=,minimumSize=,preferredSize=,approveButtonText=,currentDirectory=C:\Users\shveerab.ORADEV\Desktop,dialogTitle=,dialogType=OPEN_DIALOG,fileSelectionMode=FILES_ONLY,returnValue=ERROR_OPTION,selectedFile=,useFileHiding=false],Parent:javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JPanel[null.contentPane,0,0,500x328,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true]
JComp Childs: javax.swing.JLayeredPane[null.layeredPane,0,0,500x328,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,optimizedDrawingPossible=true],Parent:javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=]
JComp Childs: javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],Parent:javax.swing.JDialog[dialog0,511,231,516x367,invalid,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Open,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,8,31,500x328,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]

 Component event:70
 Component event:36
 Component event:70
 Component event:36
 Component event:799
 Component event:38923
 Component event:70
 Component event:36
 Component event:131
 Component event:71
 Component event:5
 Component event:48
 Component event:128
 Component event:128
 Component event:12
 Component event:124
 Component event:125
 Component event:131
 Component event:71
 Component event:70
 Component event:131
 Component event:71
 Component event:128
 Component event:128
 Component event:799
 Component event:48
 Component event:38923
 Component event:70
 Component event:131
 Component event:71
 Component event:5
 Component event:48
 Component event:128
 Component event:128
 Component event:12
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:124
 Component event:131
 Component event:71
 Component event:125
 Component event:128
 Component event:128
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:131
 Component event:71
 Component event:38923
 Component event:70
 Component event:36
 Component event:131
 Component event:71
 Component event:5
 Component event:38925
 Component event:38926
 Component event:38925
 Component event:38926
 Component event:38923
 Component event:70
 Component event:36
 Component event:131
 Component event:71
 Component event:3
 Component event:5
 Component event:38925
 Component event:38926
 Component event:38925
 Component event:38926
 Component event:38925
 Component event:38926
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:38916
 Component event:24
 Component event:70
 Component event:70
 Component event:28
 Component event:28
 Component event:134
 Component event:6
 Component event:641
 Component event:642
 Component event:70
 Component event:70
 Component event:133
 Component event:20
 Component event:71
 Component event:124
 Component event:125
 Component event:128
 Component event:128
 Component event:15
 Component event:133
 Component event:132
 Component event:132
 Component event:132
 Component event:61
 Component event:61
 Component event:61
 Component event:61
 Component event:38925
 Component event:356
 Component event:49293
 Component event:38926
 Component event:132
 Component event:132
 Component event:132
 Component event:32
 Component event:132
 Component event:38914
 Component event:512
 Component event:132
 Component event:132
 Component event:38958
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:38919
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:641
 Component event:641
 Component event:132
 Component event:38918
 Component event:7
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:585
 Component event:582
 Component event:49306
 Component event:132
 Component event:581
 Component event:38918
 Component event:8
 Component event:581
 Component event:641
 Component event:641
 Component event:641
 Component event:641
 Component event:38918
 Component event:7
 Component event:581
 Component event:581
 Component event:581
 Component event:583
 Component event:61
 Component event:61
 Component event:61
 Component event:356
 Component event:49306
 Component event:586
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 ComponenListener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
Listener:mouse
t event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:38921
 Component event:132
 Component event:38915
 Component event:512
 Component event:132
 Component event:132
 Component event:32
 Component event:174
 Component event:174
 Component event:174
 Component event:38921
 Component event:512
 Component event:38921
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:32
 Component event:38921
 Component event:132
 Component event:38914
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:512
 Component event:132
 Component event:132
 Component event:132
 Component event:132
 Component event:38915
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component eveListener:focus
nt:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:512
 Component event:132
 Component event:32
 Component event:38921
 Component event:513
 Component event:38921
 Component event:514
 Component event:533
 Component event:38921
 Component event:132
 Component event:32
 Component event:32
 Component event:160
 Component event:32
 Component event:161
 Component event:533
 Component event:274
 Component event:16
 Component event:674
 Component event:32
 Component event:160
 Component event:38917
 Component event:24
 Component event:70
 Component event:70
 Component event:71
 Component event:134
 Component event:6
 Component event:28
 Component event:28
 Component event:641
 Component event:642
 Component event:674
 Component event:38918
 Component event:8
 Component event:38960
 Component event:38960
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 902676 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170924/63f43c09/winmail-0001.dat>

From shashidhara.veerabhadraiah at oracle.com  Mon Sep 25 06:38:44 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Sun, 24 Sep 2017 23:38:44 -0700 (PDT)
Subject: <AWT Dev> FW: [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <2fa8e9ea-61e4-4685-b956-fef31b367f2a@default>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
 <957ee779-9a2e-daee-636a-79e8c9522ca3@oracle.com>
 <2fa8e9ea-61e4-4685-b956-fef31b367f2a@default>
Message-ID: <cfff084f-cfa6-43c4-91e9-4de9749bc567@default>

Hi Alexey, Please see below for my replies:

[Attachments will be shared upon request as they are of considerable size and cannot be sent to AWT dev group because of the email size limitation.]

Thanks and regards,
Shashi

-----Original Message-----
From: Alexey Ivanov 
Sent: Friday, September 22, 2017 5:26 PM
To: Shashidhara Veerabhadraiah < HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com>; Sergey Bylokhov < HYPERLINK "mailto:sergey.bylokhov at oracle.com" sergey.bylokhov at oracle.com>
Cc:  HYPERLINK "mailto:awt-dev at openjdk.java.net" awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

Hi Shashi,

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.

I cannot grasp the meaning of this sentence.

What are touch click events?
[Shashi] Below are the related macros:
#define WM_LBUTTONDOWN                  0x0201
#define WM_LBUTTONDBLCLK                0x0203

#define WM_POINTERDOWN                   0x0246

[Shashi]  More appropriately, touch double tap events. On a technical note, whenever I did a double tap touch on the folder I could get WM_POINTERDOWN(0x0246) and none of the left button down or left button double click events. I have attached the proof for the same captured as text file(for both touch double tap and a mouse double click events). Please note that this behavior is seen after the removal of EnableMouseInPointer() as it is not required anymore(Please see for the reply to your other email). I could not get left double click event but instead only the left button down events via the mouse double click. I think we use the time gap between the left button down events and then convert to a double click event internally.
[Shashi] So in a way we can conclude that after we do a touch double tap action there was no left button down events that we received. Please note that this is the behavior if we do a double tap touch on the file icon.

What are mouse focus events?
[Shashi] Since there are 2 components in the file chooser. One is the icon and another is the file name. In the Java implementation the file chooser dialog has the icon representations being pretty small and usually it is difficult to exactly tap on the icon!! If there is a touch tap onto the file name we do receive left button down and as well as pointer down messages. I have attached a file containing the proof of it for the same.

[Shashi] This is actually a surprise for me and also tells me that the type of an icon component and the file name components are having different behaviors. I am not sure how I can change this behavior of the icon component.
 
With this fix, we can touch on all the icons as highlighted above and have the required actions being performed as expected, which was not happening earlier.

So the fix is not JFileChooser-specific, is it?
[Shashi] No it is not. It enables the touch for all the components.

Regards,
Alexey

>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 19, 2017 3:39 AM
> To:  HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com >> Shashidhara 
> Veerabhadraiah < HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com>
> Cc:  HYPERLINK "mailto:awt-dev at openjdk.java.net" awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow 
> to open folders with a double tap when using the touch screen 
> interface
>
> Hi, Shashi.
> Why the bug is JFileChooser specific?
> Does it means that it works for other elements(buttons/lists/menu/etc)?
>
> On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review this software changes for the /_enhancement_/ 
>> JDK-8178361.
>>
>> Issue: Request was filed to enable the touch event processing for 
>> Java client applications.
>>
>> Fix: Windows platform offers 'pointer' implementation thro' which one 
>> can tap for the touch inputs as well. A typical 'pointer' function 
>> may contain touch, pen, touch pad or mouse inputs. This allows for a 
>> uniform input processing though the event source may defer. This fix 
>> enables the 'touch' events(via TOUCH pointer) to be passed to the 
>> components using the other type of pointer 'mouse'. Essentially there 
>> is a conversion put in place to convert a touch event input into a 
>> left click mouse event. I think this is the right thing to do 
>> considering desktop scenarios to which the typical Java applications 
>> that gets exposed to. This is also the same behavior on my touch 
>> enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
>>
>> Now touch event works as a typical mouse left click as in general. 
>> But there is an issue because the icon size of the Java UI is 
>> typically small, touching that icon exactly is sometimes difficult. 
>> This is handled by an Windows application by having larger icon size 
>> or icon view as a standard. Hence I believe this is outside the scope 
>> this software update. Any changes to it would be done later as a new 
>> bug or an enhancement.
>>
>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361
>>
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
>>
>> Thanks and regards,
>>
>> Shashi
>>
>
> --
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170924/47e116d3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 902180 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170924/47e116d3/winmail-0001.dat>

From dmitry.markov at oracle.com  Mon Sep 25 20:09:25 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 25 Sep 2017 21:09:25 +0100
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
 <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
Message-ID: <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>

Hi Semyon,

This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.

The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.

Thanks,
Dmitry
> On 25 Sep 2017, at 15:58, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Dmitry,
> 
> This issue was already fixed in 9. See 8139218 & 8159432.
> 
> --Semyon
> 
> 
> On 09/23/2017 08:25 AM, Dmitry Markov wrote:
>> Hello,
>> 
>> Could you review a fix for jdk10, please?
>> 
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8155197
>>   webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.00/
>> 
>> Problem description:
>> Currently we restore focus synchronously to a component if the window (which contains it) owns the focus. However if another window/dialog is displayed at the same time, the first window loses focus, (i.e. synchronous focus request failed) and the focus target is shifted to the next component in the focus traversal cycle.
>> 
>> Fix:
>> It is necessary to check the result of synchronous focus request for a component. If the focus request?s failed because the contained window lost focus, we should restore focus to this component next time when its parent window obtains focus.
>> 
>> Testing:
>> I ran corresponding JCK and regression tests and did not observe any new failures.
>> 
>> Thanks,
>> Dmitry
> 


From dmitry.markov at oracle.com  Mon Sep 25 20:31:08 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 25 Sep 2017 21:31:08 +0100
Subject: <AWT Dev> [10] Review request for 8185634,
 8185634: Java Fx-Swing dialogs appearing behind main stage
In-Reply-To: <dc5e5f35-38ee-b1a0-d5e0-408e8fdc25c1@oracle.com>
References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com>
 <c10968d7-af0b-d599-6620-dd95e4d7af12@oracle.com>
 <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com>
 <F5964E0F-A0A7-49BE-B056-8E590B0C8559@oracle.com>
 <dc5e5f35-38ee-b1a0-d5e0-408e8fdc25c1@oracle.com>
Message-ID: <C204ECBD-19BB-4C26-B613-E107CE456626@oracle.com>

Hi Alexander,

Sounds reasonable. I am OK with usage of addChildWindow() in this case.

Thanks,
Dmitry
> On 25 Sep 2017, at 13:05, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
> 
> Hi Dmitry,
> 
> From my understanding JavaFX stage can't be easily integrated in JDK to support orderWindow() approach,
> 
> addChildWindow() is a native(and the simplest) way to maintain one window above other one, should be called only once.
> 
> IIUC the main concert of JDK-8080729 that child windows jumping to parent's display upon focus receiving, this is not an issue with current fix,
> 
> because addChildWindow() will be called only upon dialog creation in case of JavaFX-Swing interop.
> 
> Jump may happen if user want to create a child swing dialog on display other than JavaFX stage's one,
> 
> but such rare scenario can be easily workarounded on a user side by calling setLocation() right after setVisible() call.
> 
> So I would prefer to use addChildWindow() to make this fix as simple as possible.
> 
> 
> Thanks,
> Alexander.
> 
> On 23/09/2017 21:21, Dmitry Markov wrote:
>> Hi Alexander,
>> 
>> In CPlatformWindow class you call CWrapper.NSWindow.addChildWindow() to place a window above JavaFX stage. The usage of addChilWindow() or/and removeChildWindow() may cause ?jumping window issue? in multi-monitor environment, see JDK-8080729 for more details.
>> 
>> To avoid possible problems in multi monitor set-up I suggest that you should replace addChildWindow() with orderWindow() or use some another approach to locate the window above the stage.
>> 
>> Thanks,
>> Dmitry
>>> On 22 Sep 2017, at 06:56, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
>>> 
>>> Hi Phil,
>>> 
>>> Please review the updated fix with reflection incorporated
>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/
>>> 
>>> New issue created JDK-8187803 <https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart of this issue.
>>> 
>>> Thanks,
>>> Alexander.
>>> 
>>> On 21/09/2017 22:25, Phil Race wrote:
>>>> Some procedural comments :
>>>> Since 90% of this is in AWT code, I'd have thought awt-dev should be included here.
>>>> I've added that list.
>>>> 
>>>> And apart from needing separate bug ids, I don't see why the bug below is confidential.
>>>> 
>>>> 
>>>> I agree with what Kevin pointed out off-line that as in the dialog case, the FX side
>>>> of the code can use reflection and simply be a harmless non-functional no-op
>>>> if the SwingAccessor does not provide the new method.
>>>> 
>>>> BTW
>>>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
>>>> should be "dd" not "d".
>>>> 
>>>> -phil.
>>>> 
>>>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:
>>>>> Hello,
>>>>> 
>>>>> please review the fix
>>>>> 
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/
>>>>> 
>>>>> for the issue
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8185634
>>>>> 
> 


From Sergey.Bylokhov at oracle.com  Mon Sep 25 20:44:49 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 Sep 2017 13:44:49 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
Message-ID: <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>

On 9/22/17 04:22, Alexey Ivanov wrote:
> There's no way of knowing in advance.
> Explorer does not restrict the size of icons (now), it's up to 
> developers of a particular file handler to provide icons. Usually, 
> there's only one icon with size larger than 255.
> 
> If there's the icon of the requested size, Explorer will give it to you, 
> otherwise it will scale the closest available to the requested size.
> 
> Windows documentation suggests the following sizes:
> https://msdn.microsoft.com/en-us/library/windows/desktop/dn742485(v=vs.85).aspx#size_requirements 

Ok, so it means that we will support 1-128 pixels 
natively(MAX_ICON_SIZE) and others via MRI.

> 
> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using Windows 
> API to retrieve the recommended size for small and large icon size 
> rather than defaulting to 16?16 and 32?32. If HiDPI is in effect, the 
> icons must be larger.

But this depends from the the DPI of the screen, we cannot just request 
default FILE_ICON_SMALL/FILE_ICON_LARGE. If these constants will be 
added then we should use something like this to get correct icons:

Icon icon = getSystemIcon(file, FILE_ICON_SMALL);
Icon hicon = getSystemIcon(file, icon.getIconWidth()*screenScale);
or
Icon icon = getSystemIcon(file);
Icon hicon = getSystemIcon(file, icon.getIconWidth()*screenScale);
Or we can do:
Icon hicon = getSystemIcon(file, FILE_ICON_LARGE);

This means that on HiDPI screen the FILE_ICON_LARGE works in similar way 
as FILE_ICON_SMALL on non-HiDPI screen, and the meaning of the 
FILE_ICON_SMALL on HiDPI is unclear, because it is half of the correct size.

For example one of the consumer of this new API is WindowsFileView.
How the code below should be changed to work on a different screens, and 
request the proper icon?
WindowsFileChooserUI.java
1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Mon Sep 25 21:26:10 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 25 Sep 2017 14:26:10 -0700
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
 <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
 <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>
Message-ID: <40da60db-5074-bc18-d4bf-09b6b3040353@oracle.com>

Hi Dmitry,


On 09/25/2017 01:09 PM, Dmitry Markov wrote:
> Hi Semyon,
>
> This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.
I couldn't get the test failed on 9 and 10. But I only tried it on 
Ubuntu. Is the issue a platform dependent?
>
> The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.
I see. What may prevent to set the input focus synchronously? Since the 
native window already has the focus this should be very deterministic.

--Semyon
>
> Thanks,
> Dmitry
>> On 25 Sep 2017, at 15:58, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
>>
>> Hi Dmitry,
>>
>> This issue was already fixed in 9. See 8139218 & 8159432.
>>
>> --Semyon
>>
>>
>> On 09/23/2017 08:25 AM, Dmitry Markov wrote:
>>> Hello,
>>>
>>> Could you review a fix for jdk10, please?
>>>
>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8155197
>>>    webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.00/
>>>
>>> Problem description:
>>> Currently we restore focus synchronously to a component if the window (which contains it) owns the focus. However if another window/dialog is displayed at the same time, the first window loses focus, (i.e. synchronous focus request failed) and the focus target is shifted to the next component in the focus traversal cycle.
>>>
>>> Fix:
>>> It is necessary to check the result of synchronous focus request for a component. If the focus request?s failed because the contained window lost focus, we should restore focus to this component next time when its parent window obtains focus.
>>>
>>> Testing:
>>> I ran corresponding JCK and regression tests and did not observe any new failures.
>>>
>>> Thanks,
>>> Dmitry


From Sergey.Bylokhov at oracle.com  Mon Sep 25 21:48:48 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 Sep 2017 14:48:48 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch
 keyboard is not shown for text components on a screen touch
In-Reply-To: <a4a2249f-3853-e3d1-ba35-df97b5c60b8e@oracle.com>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
 <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
 <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
 <6f3177ec-2915-0004-bbd2-11232e2338c6@oracle.com>
 <35aac19c-ee68-0d6b-319d-1343e59cb5c4@oracle.com>
 <a4a2249f-3853-e3d1-ba35-df97b5c60b8e@oracle.com>
Message-ID: <a86370ed-e0d0-0b21-64d0-1a59fb419bbc@oracle.com>

On 9/25/17 11:49, Anton Litvinov wrote:
> Hello Sergey,
> 
> Thank you for approval of the fix. Yes, sure, I will file a CSR. Do you 
> suggest to file a CSR about the new property 
> "awt.touchKeyboardAutoShowIsEnabled" or the whole functionality 
> implemented in this fix, particularly - support of automatic showing of 
> the touch keyboard without mentioning of this new system property?

It would be good to describe the whole feature.

> 
> Thank you,
> Anton
> 
> On 25/09/2017 17:30, Sergey Bylokhov wrote:
>> Looks fine.
>>
>> On 9/21/17 17:39, Anton Litvinov wrote:
>>> Could you please answer my question.
>>> - Should CCC request be filed for the new system property 
>>> "awt.touchKeyboardAutoShowIsEnable", whose value is considered as 
>>> "true" by default, if it is not specified by the user explicitly 
>>> while launching a Java application?
>>
>> I suggest to create a CSR, because this fix introduce some behavior 
>> change(it does not mean that we will make this property public).
>>
>>
> 


-- 
Best regards, Sergey.

From anton.litvinov at oracle.com  Tue Sep 26 01:24:39 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Tue, 26 Sep 2017 02:24:39 +0100
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <cddc59b7-0dec-4a33-9e38-e284ed1d8a4d@default>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
 <ccff0734-1ed5-8c88-d558-1b41a31a3477@oracle.com>
 <cddc59b7-0dec-4a33-9e38-e284ed1d8a4d@default>
Message-ID: <39e908a1-9083-2ab5-2dc2-fb5cc6df55b0@oracle.com>

Hi Shashi,

I am also reviewing your fix since last week. I built "jdk10/client" 
with your fix and was able to see, how the 1st and the 2nd versions of 
your fix work. I have the following remarks and questions to you:

1. The fix causes a rather significant regression, which is a loss of 
the drag functionality using the touch screen. To reproduce it you can 
use "SwingSet2" demo application, where try to move any of the internal 
frames on the first tab of the demo application using the touch screen. 
Also you can try to select text in JTextField in that demo application 
using the touch screen. I think that this regression is serious and 
should be addressed in this fix.

2. Why is it necessary for your fix to handle "WM_POINTERENTER", 
"WM_POINTERLEAVE" messages?

3. According to MSDN the used by you Win32 API function "GetPointerInfo" 
and "WM_POINTER*" messages are available on Windows 8 or later OS 
versions, what means that they are not available on older OS versions, 
for example on Windows 7, and what means that your fix will not resolve 
the bug for Windows 7.

Windows 7 is supported by JDK 9 
(http://www.oracle.com/technetwork/java/javase/jdk9certconfig-3761018.html), 
and obviously JDK 10 also supports Windows 7, therefore the bug should 
be fixed also for Windows 7, if it is reproducible on that OS.

Thank you,
Anton

On 25/09/2017 07:29, Shashidhara Veerabhadraiah wrote:
>
> Hi Alexey, Thank you for pointing that out. I misread the info that 
> EnableMouseInPointer() is a must call and would enable the WM_POINTER 
> messages being sent to the component. But actually it is not required 
> to be enabled and as you rightly pointed out that it would convert the 
> WM_MOUSE to the WM_POINTER messages.
>
> Below is the Webrev that does this change. Now since mouse in pointer 
> is disabled, the mouse behavior should /_not_/ have any effect at all 
> by this software updates.
>
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.01/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8178361/webrev.01/>
>
> For additional replies, please see below.
>
> Thanks and regards,
>
> Shashi
>
> *From:*Alexey Ivanov
> *Sent:* Friday, September 22, 2017 5:19 PM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; Sergey Bylokhov 
> <sergey.bylokhov at oracle.com>
> *Cc:* awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow 
> to open folders with a double tap when using the touch screen interface
>
> Hi Shashi,
>
> You use EnableMouseInPointer which converts classical WM_MOUSE events 
> to WM_POINTER events. This could have substantial effect on AWT 
> components behaviour. I am worried about High DPI support, 
> drag-and-drop functionality etc.
>
> */[Shashi] This is not required and hence removed./*
>
> Is there a simpler way to handle double-tap?
> Windows converts taps to clicks, i.e. the app receives WM_LBUTTONDOWN 
> and WM_LBUTTONUP.
> Have you tried to find out why double-tap is not converted to 
> double-click?
>
> */[Shashi] Since the mouse in pointer is disabled and a windows icon 
> behavior is different from a windows button behavior(Because the a 
> touch on the icon does not translate to a left button down event 
> whereas it does for a windows button(file name!!)), it is required to 
> bring in the WM_POINTER message type into the component message 
> handling routine./*
>
> Do right and middle mouse buttons continue to work as expected? Mouse 
> wheel? Any additional mouse buttons?
>
> */[Shashi] It should not have any effect after mouse in pointer is 
> disabled./*
>
> The documentation for EnableMouseInPointer [1] says: ?This function 
> can be called only once in the context of a process lifetime.? You 
> call it for every component created. It would have been enough to call 
> it once during Toolkit initialization.
>
>
> Regards,
> Alexey
>
> [1] 
> https://msdn.microsoft.com/en-us/library/windows/desktop/hh447467(v=vs.85).aspx 
> <https://msdn.microsoft.com/en-us/library/windows/desktop/hh447467%28v=vs.85%29.aspx>
>
> On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:
>
>     Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.
>
>     Thanks and regards,
>
>     Shashi
>
>     -----Original Message-----
>
>     From: Sergey Bylokhov
>
>     Sent: Tuesday, September 19, 2017 3:39 AM
>
>     To:shashidhara.veerabhadraiah at oracle.com
>     <mailto:shashidhara.veerabhadraiah at oracle.com>  >> Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>     <mailto:shashidhara.veerabhadraiah at oracle.com>
>
>     Cc:awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>
>     Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface
>
>     Hi, Shashi.
>
>     Why the bug is JFileChooser specific?
>
>     Does it means that it works for other elements(buttons/lists/menu/etc)?
>
>     On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
>
>         Hi All, Please review this software changes for the /_enhancement_/
>
>         JDK-8178361.
>
>         Issue: Request was filed to enable the touch event processing for Java
>
>         client applications.
>
>         Fix: Windows platform offers 'pointer' implementation thro' which one
>
>         can tap for the touch inputs as well. A typical 'pointer' function may
>
>         contain touch, pen, touch pad or mouse inputs. This allows for a
>
>         uniform input processing though the event source may defer. This fix
>
>         enables the 'touch' events(via TOUCH pointer) to be passed to the
>
>         components using the other type of pointer 'mouse'. Essentially there
>
>         is a conversion put in place to convert a touch event input into a
>
>         left click mouse event. I think this is the right thing to do
>
>         considering desktop scenarios to which the typical Java applications
>
>         that gets exposed to. This is also the same behavior on my touch
>
>         enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
>
>         Now touch event works as a typical mouse left click as in general. But
>
>         there is an issue because the icon size of the Java UI is typically
>
>         small, touching that icon exactly is sometimes difficult. This is
>
>         handled by an Windows application by having larger icon size or icon
>
>         view as a standard. Hence I believe this is outside the scope this
>
>         software update. Any changes to it would be done later as a new bug or
>
>         an enhancement.
>
>         Bug ID:https://bugs.openjdk.java.net/browse/JDK-8178361
>
>         Webrev:http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8178361/webrev.00/>
>
>         Thanks and regards,
>
>         Shashi
>
>     --
>
>     Best regards, Sergey.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170926/8f24b454/attachment-0001.html>

From alexander.zvegintsev at oracle.com  Tue Sep 26 04:11:16 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 26 Sep 2017 09:41:16 +0530
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch
 keyboard is not shown for text components on a screen touch
In-Reply-To: <6f3177ec-2915-0004-bbd2-11232e2338c6@oracle.com>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
 <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
 <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
 <6f3177ec-2915-0004-bbd2-11232e2338c6@oracle.com>
Message-ID: <c2bf3294-9baa-31ab-6b3d-2e3388ae1031@oracle.com>

+1

Thanks,
Alexander.

On 22/09/2017 06:09, Anton Litvinov wrote:
> Hello Sergey,
>
> Thank you very much for review of this fix. The second version of the 
> fix with minor changes in 3 places which address your remarks is 
> created. The new fix version applied to the today's version of the 
> consolidated repository "jdk10/client" was verified in my local 
> environment successfully. Could you please look at the new version of 
> the fix.
>
> Webrev (the 2nd version): 
> http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.01
>
> The 2nd version of the fix contains the next changes:
> 1.? "SunToolkit.java" file - Now "true" is used as the default value 
> for the system property "awt.touchKeyboardAutoShowIsEnable".
> 2.? The 1st version of the fix was not thread-safe, only in case, when 
> more than 1 EDT could exist in the process, in 2 places: 
> "WToolkit.java" file (access to the fields "compOnTouchDownEvent", 
> "compOnMousePressedEvent"), "awt_Toolkit.cpp" file (deletion and 
> assignment of "NULL" to the field "m_touchKbrdExeFilePath" in the 
> method "ShowTouchKeyboard()").
> ??? - "WToolkit.java" - The modifier "volatile" was added to the 
> fields "compOnTouchDownEvent", "compOnMousePressedEvent".
> ??? - "awt_Toolkit.cpp" - Code deleting and assigning NULL to 
> "m_touchKbrdExeFilePath" in the method "ShowTouchKeyboard()" was 
> substituted for the code which outputs into the trace message in case, 
> if launching the touch keyboard system application fails.
>
> Could you please answer my question.
> - Should CCC request be filed for the new system property 
> "awt.touchKeyboardAutoShowIsEnable", whose value is considered as 
> "true" by default, if it is not specified by the user explicitly while 
> launching a Java application?
>
> Thank you,
> Anton
>
> On 05/09/2017 18:15, Sergey Bylokhov wrote:
>> Hi, Anton.
>> The fix looks good.
>> ?- But can you please recheck that is is not necessary to use 
>> additional synchronization in showOrHideTouchKeyboard() if a few EDT 
>> will be used.
>> ?- I suggest to invert the awt.touchKeyboardAutoShowIsEnabled and use 
>> true as default value, we will have more coverage and feedback in 
>> this case. This property will be used as a workaround if some bugs 
>> will be found.
>>
>> On 8/30/17 11:51, Anton Litvinov wrote:
>>> Hello dear reviewers,
>>>
>>> Could anybody please look at this review request?
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 17/08/2017 13:20, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix for the bug.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166772
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00
>>>>
>>>> The bug is the fact that, when a user touches any Swing or AWT text 
>>>> component, for example "JTextField", "JTextArea", "TextField", 
>>>> "TextArea", by means of a touch screen on a host with MS Windows 
>>>> 10/8.1/8 OS, the system touch keyboard is not shown automatically. 
>>>> Please find a detailed description of the bug, screenshots 
>>>> depicting the touch keyboard and a compilable test case with 
>>>> Swing/AWT text components in JBS bug record. Also a summary of the 
>>>> done research of the issue with a description of identified 
>>>> approaches for its resolution are reported in my last comment in 
>>>> the bug record.
>>>>
>>>> THE FIX:
>>>> On a very abstract level the fix functioning can be presented by 
>>>> the next 3 stages:
>>>>
>>>> Stage 1.
>>>> The fix adds support of "WM_TOUCH" system window messages to AWT 
>>>> native peer windows through C++ class "AwtComponent". It 
>>>> "processes" "WM_TOUCH" message and marks 
>>>> "java.awt.event.MouseEvent", which is created as a result of 
>>>> handling of the further coming "WM_LBUTTONDOWN", "WM_LBUTTONUP" 
>>>> messages sent by the system in substitution for this "WM_TOUCH" 
>>>> message, by the new private field flag 
>>>> "MouseEvent.causedByTouchEvent".
>>>>
>>>> Stage 2.
>>>> Then on Java level the fix handles "MouseEvent", "FocusEvent" 
>>>> received only by the instances of "java.awt.TextComponent", 
>>>> "javax.swing.text.TextComponent" in 
>>>> "WToolkit.showOrHideTouchKeyboard()" called from 
>>>> "Component.dispatchEventImpl()" and shows or hides the touch 
>>>> keyboard on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" 
>>>> events by calling corresponding native methods of "WToolkit" class.
>>>>
>>>> Stage 3.
>>>> Showing of the touch keyboard is implemented in C++ class 
>>>> "AwtToolkit" and is done by launching the system application 
>>>> "TabTip.exe" which implements the system touch keyboard. This 
>>>> approach is described in the bug record.
>>>>
>>>> FEATURES OF THE FIX:
>>>> 1. By default all native and Java parts of the fix do not function 
>>>> at all - the fix is disabled. To enable the fix the application 
>>>> should be run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" 
>>>> option. Handling of this new property is implemented in 
>>>> "sun.awt.SunToolkit" class.
>>>>
>>>> 2. Native parts of the fix functions only on MS Window 8 or later.
>>>>
>>>> 3. The fix implements automatic showing of the touch keyboard for 
>>>> the following 2 use cases:
>>>> ??? a.? The user touches the text components using the touch screen.
>>>> ??? b.? The user does mouse clicks on the text components, while no 
>>>> any keyboard is attached to the host.
>>>>
>>>> FIX LOGICAL STRUCTURE BY SOURCE CODE:
>>>> 1. Core of the fix:
>>>> ??? Native code:? awt_Toolkit.[h/cpp], awt_Component.[h/cpp], 
>>>> awt_MouseEvent.[h/cpp], awt.h
>>>> ??? Java:? SunToolkit.java, WToolkit.java, Component.java, 
>>>> MouseEvent.java, AWTAccessor.java
>>>>
>>>> 2. Changes in all remaining Java files are connected with retaining 
>>>> of the flag value "MouseEvent.causedByTouchEvent" during creation 
>>>> of the new instances of "MouseEvent" class based on the original 
>>>> "MouseEvent" instances.
>>>>
>>>> Work of the fix was verified both in the environment with the real 
>>>> touch screen device and in the environment with the emulated touch 
>>>> screen.
>>>>
>>>> Thank you,
>>>> Anton
>>>
>>
>>
>


From mik3hall at gmail.com  Tue Sep 26 08:53:45 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 26 Sep 2017 03:53:45 -0500
Subject: <AWT Dev> Java 9 on OS X internal API com.apple.eio.FileManager
Message-ID: <776E1D20-FC0E-4533-A644-D847C046FF08@gmail.com>

I know JEP 272 covered the com.apple.eawt API?s. 
Is there nothing to cover the eio.FileManager?
I have code using it to try and determine platform specific location?s for files

	public static Path getFolder(DataTypes option) {
		File f = null;
		try {
			if (option == USER) {
				f = new File(FileManager.findFolder(FileManager.kUserDomain, FileManager.OSTypeToInt("asup")),app);
				if (!f.exists()) f.mkdir();
				return f.toPath();	
			}
?etc...

When I run jdeps against my application I get?

jdeps -jdkinternals halfpipe.jar
fhalfpipe.jar -> java.desktop
   us.hall.osx.OSXApplication                         -> com.apple.eio.FileManager                          JDK internal API (java.desktop)

recognizing it as a java.desktop internal API.
If I look at the web page suggested to find replacements I see only com.apple.eawt and not com.apple.eio?

If there is no ongoing intention to support this API in the JDK I had at some point included them with a GitHub project. 
Would there be any problems or licensing concerns with me providing them that way? I think all the Apple contributed was Classpath Exception but I?m not entirely sure what requirements that involves for my use of it?


From dmitry.markov at oracle.com  Tue Sep 26 08:56:20 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Tue, 26 Sep 2017 09:56:20 +0100
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <40da60db-5074-bc18-d4bf-09b6b3040353@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
 <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
 <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>
 <40da60db-5074-bc18-d4bf-09b6b3040353@oracle.com>
Message-ID: <8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com>

Hi Semyon,

Please find my answer inline.

Thanks,
Dmitry
> On 25 Sep 2017, at 22:26, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Dmitry,
> 
> 
> On 09/25/2017 01:09 PM, Dmitry Markov wrote:
>> Hi Semyon,
>> 
>> This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.
> I couldn't get the test failed on 9 and 10. But I only tried it on Ubuntu. Is the issue a platform dependent?
I was able to reproduce the issue on Windows and Mac OSX. I didn?t test Linux, but I guess it is present there too.
Note: if you use VirtualBoxVM, it is necessary to enable 3D acceleration to reproduce the issue.
>> 
>> The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.
> I see. What may prevent to set the input focus synchronously? Since the native window already has the focus this should be very deterministic.
The native window loses focus if another window or dialog is displayed. Proposed fix is intended for the following case:
The native window owns focus and we set the focus to one of its child components synchronously, (i.e. invoke doRestoreFocus() -> requestFocus()). At the same time another window/dialog pops up, requestFocus() fails because the native parent window is not the focus owner any more and we shift focus target to next component.

> 
> --Semyon
>> 
>> Thanks,
>> Dmitry
>>> On 25 Sep 2017, at 15:58, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
>>> 
>>> Hi Dmitry,
>>> 
>>> This issue was already fixed in 9. See 8139218 & 8159432.
>>> 
>>> --Semyon
>>> 
>>> 
>>> On 09/23/2017 08:25 AM, Dmitry Markov wrote:
>>>> Hello,
>>>> 
>>>> Could you review a fix for jdk10, please?
>>>> 
>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8155197
>>>>   webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.00/
>>>> 
>>>> Problem description:
>>>> Currently we restore focus synchronously to a component if the window (which contains it) owns the focus. However if another window/dialog is displayed at the same time, the first window loses focus, (i.e. synchronous focus request failed) and the focus target is shifted to the next component in the focus traversal cycle.
>>>> 
>>>> Fix:
>>>> It is necessary to check the result of synchronous focus request for a component. If the focus request?s failed because the contained window lost focus, we should restore focus to this component next time when its parent window obtains focus.
>>>> 
>>>> Testing:
>>>> I ran corresponding JCK and regression tests and did not observe any new failures.
>>>> 
>>>> Thanks,
>>>> Dmitry
> 


From semyon.sadetsky at oracle.com  Tue Sep 26 22:46:29 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 26 Sep 2017 15:46:29 -0700
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
 <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
 <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>
 <40da60db-5074-bc18-d4bf-09b6b3040353@oracle.com>
 <8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com>
Message-ID: <59CAD8C5.3040800@oracle.com>

Hi Dmitry,

On 9/26/2017 1:56 AM, Dmitry Markov wrote:
> Hi Semyon,
>
> Please find my answer inline.
>
> Thanks,
> Dmitry
>> On 25 Sep 2017, at 22:26, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
>>
>> Hi Dmitry,
>>
>>
>> On 09/25/2017 01:09 PM, Dmitry Markov wrote:
>>> Hi Semyon,
>>>
>>> This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.
>> I couldn't get the test failed on 9 and 10. But I only tried it on Ubuntu. Is the issue a platform dependent?
> I was able to reproduce the issue on Windows and Mac OSX. I didn?t test Linux, but I guess it is present there too.
> Note: if you use VirtualBoxVM, it is necessary to enable 3D acceleration to reproduce the issue.
Not sure that 3D may change focus behavior. But I did not uses physical 
Ubuntu to test.
I also couldn't get the test failed on Windows platform after 10 attempts:

ssadetsk at SSADETSK-LAP1 /data/projects/client10/jdk
$ for ((n=0;n<10;n++)); do `/data/jtreg/bin/jtreg 
-jdk:../build/windows-x86_64-normal-server-fastdebug/jdk -nr 
test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java`; done
Test: extra argument ?passed:?
Test: extra argument ?passed:?
Test: extra argument ?passed:?
Test: extra argument ?passed:?
Test: extra argument ?passed:?
Test: extra argument ?passed:?
Test: extra argument ?passed:?
Test: extra argument ?passed:?
Test: extra argument ?passed:?
Test: extra argument ?passed:?

>>> The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.
>> I see. What may prevent to set the input focus synchronously? Since the native window already has the focus this should be very deterministic.
> The native window loses focus if another window or dialog is displayed. Proposed fix is intended for the following case:
> The native window owns focus and we set the focus to one of its child components synchronously, (i.e. invoke doRestoreFocus() -> requestFocus()). At the same time another window/dialog pops up, requestFocus() fails because the native parent window is not the focus owner any more and we shift focus target to next component.

The requestFocus() calls the requestFocusHelper() which has several outcomes that returns "false". Which one of them should be involved?

--Semyon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170926/f6fb5fbb/attachment.html>

From dmitry.markov at oracle.com  Tue Sep 26 17:07:58 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Tue, 26 Sep 2017 18:07:58 +0100
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <59CAD8C5.3040800@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
 <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
 <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>
 <40da60db-5074-bc18-d4bf-09b6b3040353@oracle.com>
 <8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com>
 <59CAD8C5.3040800@oracle.com>
Message-ID: <9B267143-2778-4F30-AE0F-E7ABEF3B4917@oracle.com>

Hi Semyon,

> On 26 Sep 2017, at 23:46, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Dmitry,
> 
> On 9/26/2017 1:56 AM, Dmitry Markov wrote:
>> Hi Semyon,
>> 
>> Please find my answer inline.
>> 
>> Thanks,
>> Dmitry
>>> On 25 Sep 2017, at 22:26, Semyon Sadetsky <semyon.sadetsky at oracle.com> <mailto:semyon.sadetsky at oracle.com> wrote:
>>> 
>>> Hi Dmitry,
>>> 
>>> 
>>> On 09/25/2017 01:09 PM, Dmitry Markov wrote:
>>>> Hi Semyon,
>>>> 
>>>> This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.
>>> I couldn't get the test failed on 9 and 10. But I only tried it on Ubuntu. Is the issue a platform dependent?
>> I was able to reproduce the issue on Windows and Mac OSX. I didn?t test Linux, but I guess it is present there too.
>> Note: if you use VirtualBoxVM, it is necessary to enable 3D acceleration to reproduce the issue.
> Not sure that 3D may change focus behavior. But I did not uses physical Ubuntu to test.
> I also couldn't get the test failed on Windows platform after 10 attempts:
> 
> ssadetsk at SSADETSK-LAP1 /data/projects/client10/jdk
> $ for ((n=0;n<10;n++)); do `/data/jtreg/bin/jtreg -jdk:../build/windows-x86_64-normal-server-fastdebug/jdk -nr test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java`; done
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> 
I do not have Windows at hand now, but the problem is strictly reproducible for me on OSX.
>>>> The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.
>>> I see. What may prevent to set the input focus synchronously? Since the native window already has the focus this should be very deterministic.
>> The native window loses focus if another window or dialog is displayed. Proposed fix is intended for the following case:
>> The native window owns focus and we set the focus to one of its child components synchronously, (i.e. invoke doRestoreFocus() -> requestFocus()). At the same time another window/dialog pops up, requestFocus() fails because the native parent window is not the focus owner any more and we shift focus target to next component.
> The requestFocus() calls the requestFocusHelper() which has several outcomes that returns "false". Which one of them should be involved?
As far as I remember requestFocusHelper() calls peer.requestFocus() and this invocation failed because native parent window doesn?t own focus. As a result requestFocusHelper() returns false and ?Peer request failed? is printed out.

Thanks,
Dmitry
> 
> --Semyon
> 

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

From philip.race at oracle.com  Tue Sep 26 17:20:10 2017
From: philip.race at oracle.com (Phil Race)
Date: Tue, 26 Sep 2017 10:20:10 -0700
Subject: <AWT Dev> Java 9 on OS X internal API com.apple.eio.FileManager
In-Reply-To: <776E1D20-FC0E-4533-A644-D847C046FF08@gmail.com>
References: <776E1D20-FC0E-4533-A644-D847C046FF08@gmail.com>
Message-ID: <96c4264f-4871-88be-feb3-16fa6a21e594@oracle.com>

I didn't do the work here so I am answering as best I can.
FileManager is not directly exposed but is used in implementing
a couple of APIs on the java.awt.Desktop class.

If you think some important use case that is appropriate there is
missed then you can file an RFE on that.

The example below seems to be something that would be better
off in java.nio.files and so would not have been appropriate for the
desktop JEP and you may want to file an RFE against core-libs/java.nio

Unfortunately, I can't answer licensing questions for you.

-phil.

On 09/26/2017 01:53 AM, Michael Hall wrote:
> I know JEP 272 covered the com.apple.eawt API?s.
> Is there nothing to cover the eio.FileManager?
> I have code using it to try and determine platform specific location?s for files
>
> 	public static Path getFolder(DataTypes option) {
> 		File f = null;
> 		try {
> 			if (option == USER) {
> 				f = new File(FileManager.findFolder(FileManager.kUserDomain, FileManager.OSTypeToInt("asup")),app);
> 				if (!f.exists()) f.mkdir();
> 				return f.toPath();	
> 			}
> ?etc...
>
> When I run jdeps against my application I get?
>
> jdeps -jdkinternals halfpipe.jar
> fhalfpipe.jar -> java.desktop
>     us.hall.osx.OSXApplication                         -> com.apple.eio.FileManager                          JDK internal API (java.desktop)
>
> recognizing it as a java.desktop internal API.
> If I look at the web page suggested to find replacements I see only com.apple.eawt and not com.apple.eio?
>
> If there is no ongoing intention to support this API in the JDK I had at some point included them with a GitHub project.
> Would there be any problems or licensing concerns with me providing them that way? I think all the Apple contributed was Classpath Exception but I?m not entirely sure what requirements that involves for my use of it?
>


From anton.litvinov at oracle.com  Tue Sep 26 18:38:15 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Tue, 26 Sep 2017 19:38:15 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8166772: Touch
 keyboard is not shown for text components on a screen touch
In-Reply-To: <a86370ed-e0d0-0b21-64d0-1a59fb419bbc@oracle.com>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
 <04237368-d782-2e60-6c26-0835c2898346@oracle.com>
 <bbc6cb7d-cae9-b31e-c867-e2bc37062e6b@oracle.com>
 <6f3177ec-2915-0004-bbd2-11232e2338c6@oracle.com>
 <35aac19c-ee68-0d6b-319d-1343e59cb5c4@oracle.com>
 <a4a2249f-3853-e3d1-ba35-df97b5c60b8e@oracle.com>
 <a86370ed-e0d0-0b21-64d0-1a59fb419bbc@oracle.com>
Message-ID: <2eccbab1-efa0-0d4b-bdf1-40dc815a628c@oracle.com>

Hello Sergey,

Thank you for clarification. I have just filed a CSR.
CSR: https://bugs.openjdk.java.net/browse/JDK-8187970#

Thank you,
Anton

On 25/09/2017 22:48, Sergey Bylokhov wrote:
> On 9/25/17 11:49, Anton Litvinov wrote:
>> Hello Sergey,
>>
>> Thank you for approval of the fix. Yes, sure, I will file a CSR. Do 
>> you suggest to file a CSR about the new property 
>> "awt.touchKeyboardAutoShowIsEnabled" or the whole functionality 
>> implemented in this fix, particularly - support of automatic showing 
>> of the touch keyboard without mentioning of this new system property?
>
> It would be good to describe the whole feature.
>
>>
>> Thank you,
>> Anton
>>
>> On 25/09/2017 17:30, Sergey Bylokhov wrote:
>>> Looks fine.
>>>
>>> On 9/21/17 17:39, Anton Litvinov wrote:
>>>> Could you please answer my question.
>>>> - Should CCC request be filed for the new system property 
>>>> "awt.touchKeyboardAutoShowIsEnable", whose value is considered as 
>>>> "true" by default, if it is not specified by the user explicitly 
>>>> while launching a Java application?
>>>
>>> I suggest to create a CSR, because this fix introduce some behavior 
>>> change(it does not mean that we will make this property public).
>>>
>>>
>>
>
>


From alexey.ivanov at oracle.com  Tue Sep 26 19:29:06 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 26 Sep 2017 20:29:06 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <125d7526-1b85-d950-41c6-fbadebbde114@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
 <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
 <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>
 <125d7526-1b85-d950-41c6-fbadebbde114@oracle.com>
Message-ID: <9331b1e4-dea0-5f2e-3afd-a9e4a8010fc3@oracle.com>

Hi Semyon,

ShellFolder2.cpp

944 pIcon->Extract(szBuf, index, &hIcon, *0*, sz);

I think 0 should really be |NULL|.
The result of the call is ignored now. Is it intentional?

Win32ShellFolder2.java

1010 private static Image makeIcon(long hIcon, int bsize) {

|bsize| was called |baseSize| previously, and it conveyed the meaning 
better, didn't it?

1043 if(hIcon <= 0) {
1044 if (isDirectory()) {
1045 return getShell32Icon(4, size);
1046 } else {
1047 return getShell32Icon(1, size);
1048 }

I guess I understand what hides behind 4 and 1: generic folder and 
generic file icon ids. Would declaring these numbers as constants 
improve readability?

|getIcon(int size)| and |getIcon(boolean getLargeIcon)| are somewhat 
similar. The latter provides additional caching. Can it be simplified to 
re-use portions of new |getIcon(int size)|?


Regards,
Alexey

On 22/09/2017 22:05, Semyon Sadetsky wrote:
>
> Hi Alexey,
>
> On 09/22/2017 01:01 PM, Alexey Ivanov wrote:
>> Hi Semyon,
>>
>> On 22/09/2017 20:06, Semyon Sadetsky wrote:
>>>
>>> Hi Alexey,
>>>
>>> On 09/22/2017 10:53 AM, Alexey Ivanov wrote:
>>>> Hi Semyon,
>>>>
>>>> On 22/09/2017 18:29, Semyon Sadetsky wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> On 09/22/2017 09:43 AM, Alexey Ivanov wrote:
>>>>>> Hi Semyon,
>>>>>>
>>>>>> On 22/09/2017 17:13, Semyon Sadetsky wrote:
>>>>>>> Hi Alexey,
>>>>>>>
>>>>>>> Thank you for your exact clarification.
>>>>>>>
>>>>>>> On 09/22/2017 04:22 AM, Alexey Ivanov wrote:
>>>>>>>> <SNIP>
>>>>>>>>
>>>>>>>> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using 
>>>>>>>> Windows API to retrieve the recommended size for small and 
>>>>>>>> large icon size rather than defaulting to 16?16 and 32?32. If 
>>>>>>>> HiDPI is in effect, the icons must be larger.
>>>>>>> I also found this as most suitable approach for the moment.
>>>>>>> Later this may be changed, for example, if Swing JFC is 
>>>>>>> re-factored to support shell determined icon sizes at HiDPI.
>>>>>>
>>>>>> Swing UI scales to accommodate HiDPI settings. If fonts are 
>>>>>> larger then icons should be larger too. Otherwise icons are too 
>>>>>> small compared to surrounding text.
>>>>>>
>>>>>> Anyway it could be postponed to a later fix.
>>>>>>
>>>>>> Does it make sense to declare the standard sizes of 16?16 and 
>>>>>> 32?32 as constants at least in Java sources? This way, it would 
>>>>>> be easier to find the places in code where a change is necessary.
>>>>> This topic requires more investigations. At first, we need to keep 
>>>>> the API cross-platform and this requires comparing all supported 
>>>>> platforms in details. At the second, even for the existing windows 
>>>>> implementation there is an ambiguity in icons sizes received form 
>>>>> the OS shell. Windows platform has number of predefined constants 
>>>>> to query icon sizes (small, large, extra large, jumbo...) but 
>>>>> their actual size may differ depending on the shell preferences.
>>>>> Those icon sizes may be changed by Windows registry settings and 
>>>>> may depend on the hi-res scale. I did several experiments and 
>>>>> found that depending on the way of desktop scaling? in Windows 10 
>>>>> (it has two ways the new one and the old) at the same scale 2x the 
>>>>> returned large icon, for example,? may be 32 or 64 pixels in size 
>>>>> (this was the root cause of the 8151385? bug).
>>>>> I would postpone digging in this direction because we are not 
>>>>> planning to update Swing JFC dialog for better HiDPI view in the 
>>>>> nearest future. Also,we don't have statistics how users may use 
>>>>> the API. Since that, the most flexible API that leaves to the user 
>>>>> the decision about icon size to query seems more preferable.
>>>>
>>>> I totally agree with your points. And the new API provides means 
>>>> for app developer to choose better-suited size for icons.
>>>>
>>>> What about using constants, private ones, for the two standard 
>>>> sizes instead of using ?magic? numbers?
>>> Which constants do you mean? The next for large and small sizes?
>>>
>>> public static final int FILE_ICON_SMALL = -1;
>>> public static final int FILE_ICON_LARGE = -2;
>>> they cannot be private because they are part of the new API that is 
>>> requested in the bug. The bug asks enabling the query for the large 
>>> icon that ShellFolder had been providing before. The bug itself is 
>>> not related to HiDPI. The possibility to get arbitrary icon sizes 
>>> was added because after 9 this may be in demand for HiDPI UIs.
>>
>> I'm talking about these two numbers in Win32ShellFolder2.java as an 
>> example:
>>
>> ?? public Image getIcon(final boolean getLargeIcon) {
>> ?????? int size = getLargeIcon ? *32* : *16*;
>>
>> Does it make sense to declare constants for the size of 16 and 32. So 
>> that the places where they're used are more easily identified if 
>> someone decides to update the code later for supporting system icon size.
> I updated the fix.
>
> http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/
>
> --Semyon
>>
>>
>> Regards,
>> Alexey
>>
>>>
>>> --Semyon
>>>
>>>> Other than that, the fix looks good to me.
>>>>
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>>>
>>>>>
>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alexey
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> <SNIP>
>>>>>>>>>>>
>>>>>>>>>>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review fix for JDK10 (the changes involve AWT and 
>>>>>>>>>>>>>> Swing):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The fix? opens the part of the ShellFolder API for 
>>>>>>>>>>>>>> getting system icons which was decided to be left closed 
>>>>>>>>>>>>>> during the 8081722 enhancement review in 9.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also the fix extends the API by adding possibility to 
>>>>>>>>>>>>>> query file icons of arbitrary size and implements this 
>>>>>>>>>>>>>> extension for Windows platform.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Tue Sep 26 20:58:37 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 26 Sep 2017 13:58:37 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <9331b1e4-dea0-5f2e-3afd-a9e4a8010fc3@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
 <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
 <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>
 <125d7526-1b85-d950-41c6-fbadebbde114@oracle.com>
 <9331b1e4-dea0-5f2e-3afd-a9e4a8010fc3@oracle.com>
Message-ID: <59CABF7D.10201@oracle.com>

Hi Alexey,

On 9/26/2017 12:29 PM, Alexey Ivanov wrote:
> Hi Semyon,
>
> ShellFolder2.cpp
> 944 pIcon->Extract(szBuf, index, &hIcon, *0*, sz);
> I think 0 should really be |NULL|.
Ok, but both represent the null pointer in Win32.

> The result of the call is ignored now. Is it intentional?
Yes, it has been working the same way before the fix. The function 
returns the Icon reference which is 0 in case of OS API call error.

>
> Win32ShellFolder2.java
> 1010 private static Image makeIcon(long hIcon, int bsize) {
> |bsize| was called |baseSize| previously, and it conveyed the meaning 
> better, didn't it?
>
> 1043 if(hIcon <= 0) {
> 1044 if (isDirectory()) {
> 1045 return getShell32Icon(4, size);
> 1046 } else {
> 1047 return getShell32Icon(1, size);
> 1048 }
> I guess I understand what hides behind 4 and 1: generic folder and 
> generic file icon ids. Would declaring these numbers as constants 
> improve readability?
Ok.
>
> |getIcon(int size)| and |getIcon(boolean getLargeIcon)| are somewhat 
> similar. The latter provides additional caching. Can it be simplified 
> to re-use portions of new |getIcon(int size)|?
It has additional difference because of query for a fixed icon size from 
another API call.  It's better to leave it as it is.

http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.02/

--Semyon
>
>
> Regards,
> Alexey
>
> On 22/09/2017 22:05, Semyon Sadetsky wrote:
>>
>> Hi Alexey,
>>
>> On 09/22/2017 01:01 PM, Alexey Ivanov wrote:
>>> Hi Semyon,
>>>
>>> On 22/09/2017 20:06, Semyon Sadetsky wrote:
>>>>
>>>> Hi Alexey,
>>>>
>>>> On 09/22/2017 10:53 AM, Alexey Ivanov wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> On 22/09/2017 18:29, Semyon Sadetsky wrote:
>>>>>> Hi Alexey,
>>>>>>
>>>>>> On 09/22/2017 09:43 AM, Alexey Ivanov wrote:
>>>>>>> Hi Semyon,
>>>>>>>
>>>>>>> On 22/09/2017 17:13, Semyon Sadetsky wrote:
>>>>>>>> Hi Alexey,
>>>>>>>>
>>>>>>>> Thank you for your exact clarification.
>>>>>>>>
>>>>>>>> On 09/22/2017 04:22 AM, Alexey Ivanov wrote:
>>>>>>>>> <SNIP>
>>>>>>>>>
>>>>>>>>> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using 
>>>>>>>>> Windows API to retrieve the recommended size for small and 
>>>>>>>>> large icon size rather than defaulting to 16?16 and 32?32. If 
>>>>>>>>> HiDPI is in effect, the icons must be larger.
>>>>>>>> I also found this as most suitable approach for the moment.
>>>>>>>> Later this may be changed, for example, if Swing JFC is 
>>>>>>>> re-factored to support shell determined icon sizes at HiDPI.
>>>>>>>
>>>>>>> Swing UI scales to accommodate HiDPI settings. If fonts are 
>>>>>>> larger then icons should be larger too. Otherwise icons are too 
>>>>>>> small compared to surrounding text.
>>>>>>>
>>>>>>> Anyway it could be postponed to a later fix.
>>>>>>>
>>>>>>> Does it make sense to declare the standard sizes of 16?16 and 
>>>>>>> 32?32 as constants at least in Java sources? This way, it would 
>>>>>>> be easier to find the places in code where a change is necessary.
>>>>>> This topic requires more investigations. At first, we need to 
>>>>>> keep the API cross-platform and this requires comparing all 
>>>>>> supported platforms in details. At the second, even for the 
>>>>>> existing windows implementation there is an ambiguity in icons 
>>>>>> sizes received form the OS shell. Windows platform has number of 
>>>>>> predefined constants to query icon sizes (small, large, extra 
>>>>>> large, jumbo...) but their actual size may differ depending on 
>>>>>> the shell preferences.
>>>>>> Those icon sizes may be changed by Windows registry settings and 
>>>>>> may depend on the hi-res scale. I did several experiments and 
>>>>>> found that depending on the way of desktop scaling  in Windows 10 
>>>>>> (it has two ways the new one and the old) at the same scale 2x 
>>>>>> the returned large icon, for example,  may be 32 or 64 pixels in 
>>>>>> size (this was the root cause of the 8151385  bug).
>>>>>> I would postpone digging in this direction because we are not 
>>>>>> planning to update Swing JFC dialog for better HiDPI view in the 
>>>>>> nearest future. Also,we don't have statistics how users may use 
>>>>>> the API. Since that, the most flexible API that leaves to the 
>>>>>> user the decision about icon size to query seems more preferable.
>>>>>
>>>>> I totally agree with your points. And the new API provides means 
>>>>> for app developer to choose better-suited size for icons.
>>>>>
>>>>> What about using constants, private ones, for the two standard 
>>>>> sizes instead of using ?magic? numbers?
>>>> Which constants do you mean? The next for large and small sizes?
>>>>
>>>> public static final int FILE_ICON_SMALL = -1;
>>>> public static final int FILE_ICON_LARGE = -2;
>>>> they cannot be private because they are part of the new API that is 
>>>> requested in the bug. The bug asks enabling the query for the large 
>>>> icon that ShellFolder had been providing before. The bug itself is 
>>>> not related to HiDPI. The possibility to get arbitrary icon sizes 
>>>> was added because after 9 this may be in demand for HiDPI UIs.
>>>
>>> I'm talking about these two numbers in Win32ShellFolder2.java as an 
>>> example:
>>>
>>>    public Image getIcon(final boolean getLargeIcon) {
>>>        int size = getLargeIcon ? *32* : *16*;
>>>
>>> Does it make sense to declare constants for the size of 16 and 32. 
>>> So that the places where they're used are more easily identified if 
>>> someone decides to update the code later for supporting system icon 
>>> size.
>> I updated the fix.
>>
>> http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/
>>
>> --Semyon
>>>
>>>
>>> Regards,
>>> Alexey
>>>
>>>>
>>>> --Semyon
>>>>
>>>>> Other than that, the fix looks good to me.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>>>
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alexey
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> <SNIP>
>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/13/17 11:01, Semyon Sadetsky wrote:
>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please review fix for JDK10 (the changes involve AWT and 
>>>>>>>>>>>>>>> Swing):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The fix  opens the part of the ShellFolder API for 
>>>>>>>>>>>>>>> getting system icons which was decided to be left closed 
>>>>>>>>>>>>>>> during the 8081722 enhancement review in 9.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also the fix extends the API by adding possibility to 
>>>>>>>>>>>>>>> query file icons of arbitrary size and implements this 
>>>>>>>>>>>>>>> extension for Windows platform.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170926/d44ed4a3/attachment-0001.html>

From mik3hall at gmail.com  Tue Sep 26 21:10:58 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 26 Sep 2017 16:10:58 -0500
Subject: <AWT Dev> Java 9 on OS X internal API com.apple.eio.FileManager
In-Reply-To: <96c4264f-4871-88be-feb3-16fa6a21e594@oracle.com>
References: <776E1D20-FC0E-4533-A644-D847C046FF08@gmail.com>
 <96c4264f-4871-88be-feb3-16fa6a21e594@oracle.com>
Message-ID: <2E959165-4854-444E-B1EC-ACAE9171A70E@gmail.com>


> On Sep 26, 2017, at 12:20 PM, Phil Race <philip.race at oracle.com> wrote:
> 
> I didn't do the work here so I am answering as best I can.
> FileManager is not directly exposed but is used in implementing
> a couple of APIs on the java.awt.Desktop class.

This will not help developers who used this in their applications. If there are no direct Desktop replacements.

> 
> If you think some important use case that is appropriate there is
> missed then you can file an RFE on that.

I think this was discussed and this class mentioned on a couple different occasions. 
I can only assume the decision was to simply drop support without replacement.
I?m not sure an RFE would reverse that decision.

> 
> The example below seems to be something that would be better
> off in java.nio.files and so would not have been appropriate for the
> desktop JEP and you may want to file an RFE against core-libs/java.nio

I would agree this might not be the best fit to AWT/Desktop. It is however where jdeps indicates it should be.
The migration guide?
https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-3A71ECEF-5FC5-46FE-9BA9-88CBFCE828CB <https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-3A71ECEF-5FC5-46FE-9BA9-88CBFCE828CB>
suggests you first run jdeps against your code to be sure there are no internal api?s that will no longer be supported.
FileManager as I indicated is flagged as a java.desktop internal api. 

JDK internal API (java.desktop)

You might want to see that this is changed so you don?t get asked by others in the future what should be the java.desktop replacement.

> 
> Unfortunately, I can't answer licensing questions for you.

I guess I will try to take a closer look at Classpath exception myself. I just browsed it and it seems to be GPL2. 
I will have to take a closer look at that to see what it entails so I can use it or offer it myself. 
It might be better if the jdk clean disowned it. I think I tried compiling against it and it was indicated to be in the java.desktop module but
not exported. Hence, unavailable to compile? (OS X Eclipse Java 9 seems all right with compiling it? javac failed).  
Possibly I can rename. Somehow I will try to offer it off of my GitHub project. Anyone who cares to use it, can get it there, if they know about it.

> 
> -phil.
> 


Thanks for the answer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170926/33c02b42/attachment.html>

From mandy.chung at oracle.com  Tue Sep 26 21:22:01 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 26 Sep 2017 14:22:01 -0700
Subject: <AWT Dev> Java 9 on OS X internal API com.apple.eio.FileManager
In-Reply-To: <2E959165-4854-444E-B1EC-ACAE9171A70E@gmail.com>
References: <776E1D20-FC0E-4533-A644-D847C046FF08@gmail.com>
 <96c4264f-4871-88be-feb3-16fa6a21e594@oracle.com>
 <2E959165-4854-444E-B1EC-ACAE9171A70E@gmail.com>
Message-ID: <429ec721-730b-d15e-9c8d-15acfe85d401@oracle.com>



On 9/26/17 2:10 PM, Michael Hall wrote:
>>
>> The example below seems to be something that would be better
>> off in java.nio.files and so would not have been appropriate for the
>> desktop JEP and you may want to file an RFE against core-libs/java.nio
>
> I would agree this might not be the best fit to AWT/Desktop. It is 
> however where jdeps indicates it should be.
>
> The migration guide?
> https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-3A71ECEF-5FC5-46FE-9BA9-88CBFCE828CB
> suggests you first run jdeps against your code to be sure there are no 
> internal api?s that will no longer be supported.
> FileManager as I indicated is flagged as a java.desktop internal api.
>
> JDK internal API (java.desktop)
>
> You might want to see that this is changed so you don?t get asked by 
> others in the future what should be the java.desktop replacement.
com.apple.eio is encapsulated in java.desktop module.? jdeps correctly 
reports access to com.apple.eio.FileManager as an internal API.

Like Phil said, the best way is to file a RFE to describe the 
functionality that com.apple.eio.FileManager you depend on and no public 
API providing that in the platform.

Mandy

From semyon.sadetsky at oracle.com  Tue Sep 26 21:37:08 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 26 Sep 2017 14:37:08 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
Message-ID: <59CAC884.6070207@oracle.com>

Hi Sergey,

On 9/25/2017 1:44 PM, Sergey Bylokhov wrote:
> On 9/22/17 04:22, Alexey Ivanov wrote:
>> There's no way of knowing in advance.
>> Explorer does not restrict the size of icons (now), it's up to 
>> developers of a particular file handler to provide icons. Usually, 
>> there's only one icon with size larger than 255.
>>
>> If there's the icon of the requested size, Explorer will give it to 
>> you, otherwise it will scale the closest available to the requested 
>> size.
>>
>> Windows documentation suggests the following sizes:
>> https://msdn.microsoft.com/en-us/library/windows/desktop/dn742485(v=vs.85).aspx#size_requirements 
>
>
> Ok, so it means that we will support 1-128 pixels 
> natively(MAX_ICON_SIZE) and others via MRI.
We will support all sizes natively not only 1-128. Windows does the scaling.
>
>>
>> As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using Windows 
>> API to retrieve the recommended size for small and large icon size 
>> rather than defaulting to 16?16 and 32?32. If HiDPI is in effect, the 
>> icons must be larger.
>
> But this depends from the the DPI of the screen, we cannot just 
> request default FILE_ICON_SMALL/FILE_ICON_LARGE. If these constants 
> will be added then we should use something like this to get correct 
> icons:
>
> Icon icon = getSystemIcon(file, FILE_ICON_SMALL);
> Icon hicon = getSystemIcon(file, icon.getIconWidth()*screenScale);
> or
> Icon icon = getSystemIcon(file);
> Icon hicon = getSystemIcon(file, icon.getIconWidth()*screenScale);
> Or we can do:
> Icon hicon = getSystemIcon(file, FILE_ICON_LARGE);
>
> This means that on HiDPI screen the FILE_ICON_LARGE works in similar 
> way as FILE_ICON_SMALL on non-HiDPI screen, and the meaning of the 
> FILE_ICON_SMALL on HiDPI is unclear, because it is half of the correct 
> size.
Small and large don't have any special meanings for HiDPI. They are some 
conditional sizes established by the native platform for the current 
screen resolution.
Why is it half of the correct size? It is the same size as for non-HiDPI 
and that is the correct size because otherwise java UI component that is 
HiDPI unaware would paint icons 2 times bigger in size than it is 
required. But the resolution of small/large icons may differs in case of 
HiDPI because it is determined by the size of the images returned by the 
native platform by the small/large icon queries.
>
> For example one of the consumer of this new API is WindowsFileView.
> How the code below should be changed to work on a different screens, 
> and request the proper icon?
> WindowsFileChooserUI.java
> 1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);
Why it should be changed? The code is requesting the proper icon.


From mik3hall at gmail.com  Tue Sep 26 21:39:06 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 26 Sep 2017 16:39:06 -0500
Subject: <AWT Dev> Java 9 on OS X internal API com.apple.eio.FileManager
In-Reply-To: <429ec721-730b-d15e-9c8d-15acfe85d401@oracle.com>
References: <776E1D20-FC0E-4533-A644-D847C046FF08@gmail.com>
 <96c4264f-4871-88be-feb3-16fa6a21e594@oracle.com>
 <2E959165-4854-444E-B1EC-ACAE9171A70E@gmail.com>
 <429ec721-730b-d15e-9c8d-15acfe85d401@oracle.com>
Message-ID: <47F53B57-45B2-4F45-AA8C-B781E7FA1219@gmail.com>


> On Sep 26, 2017, at 4:22 PM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> 
> 
> On 9/26/17 2:10 PM, Michael Hall wrote:
>>> 
>>> The example below seems to be something that would be better
>>> off in java.nio.files and so would not have been appropriate for the
>>> desktop JEP and you may want to file an RFE against core-libs/java.nio
>> 
>> I would agree this might not be the best fit to AWT/Desktop. It is however where jdeps indicates it should be.
>> 
>> The migration guide?
>> https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-3A71ECEF-5FC5-46FE-9BA9-88CBFCE828CB
>> suggests you first run jdeps against your code to be sure there are no internal api?s that will no longer be supported.
>> FileManager as I indicated is flagged as a java.desktop internal api.
>> 
>> JDK internal API (java.desktop)
>> 
>> You might want to see that this is changed so you don?t get asked by others in the future what should be the java.desktop replacement.
> com.apple.eio is encapsulated in java.desktop module.  jdeps correctly reports access to com.apple.eio.FileManager as an internal API.
> 
> Like Phil said, the best way is to file a RFE to describe the functionality that com.apple.eio.FileManager you depend on and no public API providing that in the platform.
> 
> Mandy

All right. If RFE is in fact the correct way to go in resolving the status of the code I will try to figure out how to do that.

Thanks again. 

From Sergey.Bylokhov at oracle.com  Wed Sep 27 17:07:26 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Sep 2017 10:07:26 -0700
Subject: <AWT Dev> [10] Review Request: 8187639 TrayIcon is not properly
 supported on macOS in multi-screen environment
Message-ID: <c4a15854-8c2c-505d-64dc-de1454365d3e@oracle.com>


Hello,
Please review the fix for jdk10.

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

Since macOS 10.9(or even early) the main menubar is shown on all 
screens(not only on the main screen), which means that on both screens 
the trayIcons are visible.
Our code is not ready for this situation, because we create a custom 
notification window and tries to place it near the trayicon on the main 
screen.

Instead of updating the logic of showing the window, I migrated the code 
to the standard notification mechanism which is used in macOS.

Examples:
The old message: http://cr.openjdk.java.net/~serb/8187639/images/Old.png
The new(java -jar): 
http://cr.openjdk.java.net/~serb/8187639/images/Command%20line.png
The new(bundles application): 
http://cr.openjdk.java.net/~serb/8187639/images/Bundled%20applicateion.png


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Sep 27 19:22:03 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Sep 2017 12:22:03 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <59CAC884.6070207@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
 <59CAC884.6070207@oracle.com>
Message-ID: <c93cc11b-1dc7-17bd-0b50-a115af96579a@oracle.com>

On 9/26/17 14:37, Semyon Sadetsky wrote:
>> This means that on HiDPI screen the FILE_ICON_LARGE works in similar 
>> way as FILE_ICON_SMALL on non-HiDPI screen, and the meaning of the 
>> FILE_ICON_SMALL on HiDPI is unclear, because it is half of the correct 
>> size.
> Small and large don't have any special meanings for HiDPI. They are some 
> conditional sizes established by the native platform for the current 
> screen resolution.

The question what is the current screens resolution when you have two 
screens?

> Why is it half of the correct size? It is the same size as for non-HiDPI 
> and that is the correct size because otherwise java UI component that is 
> HiDPI unaware would paint icons 2 times bigger in size than it is 
> required. But the resolution of small/large icons may differs in case of 
> HiDPI because it is determined by the size of the images returned by the 
> native platform by the small/large icon queries.

It is half of the correct size because on HiDPI it is better to use 
hidpi icons instead of lowdpi. Will the HiDPI unaware apps draw x2 icons 
correctly or not depends from our implementation. If we will return the 
MRI then it will be drawn in correct size even if the bigger(HiDPI) 
image will be used.

>>
>> For example one of the consumer of this new API is WindowsFileView.
>> How the code below should be changed to work on a different screens, 
>> and request the proper icon?
>> WindowsFileChooserUI.java
>> 1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);
> Why it should be changed? The code is requesting the proper icon.

Because this method returns an icon of 16x16 pixels, which will be 
rescaled to 32x32 pixels in paint operation.


-- 
Best regards, Sergey.

From alexey.ivanov at oracle.com  Wed Sep 27 20:45:42 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 27 Sep 2017 21:45:42 +0100
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <59CAD8C5.3040800@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
 <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
 <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>
 <40da60db-5074-bc18-d4bf-09b6b3040353@oracle.com>
 <8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com>
 <59CAD8C5.3040800@oracle.com>
Message-ID: <66013f60-50d5-13cf-9e05-bce786295e9d@oracle.com>

Hi Semyon,

You're right: the test does not fail for me too on Windows 10 using 
jdk10. At the same time, I can reproduce the problem using 
focus8Test.jar attached to the bug [1]. However, it's harder to 
reproduce the issue using jdk10 or jdk9. It takes more attempts than 
with jdk8.


I could reproduce the problem on Windows 7 and Windows 10.

However, if I switch the theme to Windows Basic or Windows Classic in 
Windows 7, the issue cannot be reproduced any more. It looks as if it's 
related to window animation when a new dialog appears and disappears. If 
the dialog appears on the screen for a longer while, the test does not 
fail either.


Regards,
Alexey

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

On 26/09/2017 23:46, Semyon Sadetsky wrote:
> Hi Dmitry,
>
> On 9/26/2017 1:56 AM, Dmitry Markov wrote:
>> Hi Semyon,
>>
>> Please find my answer inline.
>>
>> Thanks,
>> Dmitry
>>> On 25 Sep 2017, at 22:26, Semyon Sadetsky<semyon.sadetsky at oracle.com>  wrote:
>>>
>>> Hi Dmitry,
>>>
>>>
>>> On 09/25/2017 01:09 PM, Dmitry Markov wrote:
>>>> Hi Semyon,
>>>>
>>>> This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.
>>> I couldn't get the test failed on 9 and 10. But I only tried it on Ubuntu. Is the issue a platform dependent?
>> I was able to reproduce the issue on Windows and Mac OSX. I didn?t test Linux, but I guess it is present there too.
>> Note: if you use VirtualBoxVM, it is necessary to enable 3D acceleration to reproduce the issue.
> Not sure that 3D may change focus behavior. But I did not uses 
> physical Ubuntu to test.
> I also couldn't get the test failed on Windows platform after 10 attempts:
>
> ssadetsk at SSADETSK-LAP1 /data/projects/client10/jdk
> $ for ((n=0;n<10;n++)); do `/data/jtreg/bin/jtreg 
> -jdk:../build/windows-x86_64-normal-server-fastdebug/jdk -nr 
> test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java`; done
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
> Test: extra argument ?passed:?
>
>>>> The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.
>>> I see. What may prevent to set the input focus synchronously? Since the native window already has the focus this should be very deterministic.
>> The native window loses focus if another window or dialog is displayed. Proposed fix is intended for the following case:
>> The native window owns focus and we set the focus to one of its child components synchronously, (i.e. invoke doRestoreFocus() -> requestFocus()). At the same time another window/dialog pops up, requestFocus() fails because the native parent window is not the focus owner any more and we shift focus target to next component.
> The requestFocus() calls the requestFocusHelper() which has several outcomes that returns "false". Which one of them should be involved?
>
> --Semyon
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170927/82e16629/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Thu Sep 28 02:11:13 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Wed, 27 Sep 2017 19:11:13 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open
 folders with a double tap when using the touch screen interface
In-Reply-To: <39e908a1-9083-2ab5-2dc2-fb5cc6df55b0@oracle.com>
References: <be5b3f7d-76c9-4fb6-815f-8b53572d432d@default>
 <544c4a49-22fe-da1d-4831-d2b3fa8eca7d@oracle.com>
 <512430b9-ab4f-48f4-b724-8dd8cef39f24@default>
 <ccff0734-1ed5-8c88-d558-1b41a31a3477@oracle.com>
 <cddc59b7-0dec-4a33-9e38-e284ed1d8a4d@default>
 <39e908a1-9083-2ab5-2dc2-fb5cc6df55b0@oracle.com>
Message-ID: <61d21012-85c3-4369-9c11-22151f1f8277@default>

Hi Anton, Thank you for your review comments. Please see below for my replies.

?

Thanks and regards,

Shashi

?

From: Anton Litvinov 
Sent: Tuesday, September 26, 2017 6:55 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Alexey Ivanov <alexey.ivanov at oracle.com>; Sergey Bylokhov <sergey.bylokhov at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

?

Hi Shashi,

I am also reviewing your fix since last week. I built "jdk10/client" with your fix and was able to see, how the 1st and the 2nd versions of your fix work. I have the following remarks and questions to you:

1. The fix causes a rather significant regression, which is a loss of the drag functionality using the touch screen. To reproduce it you can use "SwingSet2" demo application, where try to move any of the internal frames on the first tab of the demo application using the touch screen. Also you can try to select text in JTextField in that demo application using the touch screen. I think that this regression is serious and should be addressed in this fix.

[Shashi] I found the problem that was causing this issue. It is to do with the drag capture/release implemented in the WmMouseDown() and WmMouseUp() functions. This does not handles the touch drag as such and we need to implement a new touch gesture to enable the same functionality.

2. Why is it necessary for your fix to handle "WM_POINTERENTER", "WM_POINTERLEAVE" messages?

[Shashi] Currently we are mapping the touch input to mouse input and the mouse input follows a protocol of sending a mouse enter to and exit from a window event before processing further events. This same is implemented thro? Pointer enter and pointer leave messages.

3. According to MSDN the used by you Win32 API function "GetPointerInfo" and "WM_POINTER*" messages are available on Windows 8 or later OS versions, what means that they are not available on older OS versions, for example on Windows 7, and what means that your fix will not resolve the bug for Windows 7.

Windows 7 is supported by JDK 9 (http://www.oracle.com/technetwork/java/javase/jdk9certconfig-3761018.html), and obviously JDK 10 also supports Windows 7, therefore the bug should be fixed also for Windows 7, if it is reproducible on that OS.

[Shashi] Thanks for pointing this out. Windows 7 offers a different touch input method via the WM_GESTURE and here is the link for it: https://msdn.microsoft.com/en-us/library/windows/desktop/dd940543(v=vs.85).aspx. I am exploring a way to implement the same in the coming update.

As one can see, there are a lot of major updates that needs to be done for this feature to be complete. It will take some more days to do this, hence please wait for some time till I produce a new update.

Thank you,
Anton

On 25/09/2017 07:29, Shashidhara Veerabhadraiah wrote:

Hi Alexey, Thank you for pointing that out. I misread the info that EnableMouseInPointer() is a must call and would enable the WM_POINTER messages being sent to the component. But actually it is not required to be enabled and as you rightly pointed out that it would convert the WM_MOUSE to the WM_POINTER messages.

?

Below is the Webrev that does this change. Now since mouse in pointer is disabled, the mouse behavior should not have any effect at all by this software updates.

?

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8178361/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.01/

?

For additional replies, please see below.

?

Thanks and regards,

Shashi

?

From: Alexey Ivanov 
Sent: Friday, September 22, 2017 5:19 PM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

?

Hi Shashi,

You use EnableMouseInPointer which converts classical WM_MOUSE events to WM_POINTER events. This could have substantial effect on AWT components behaviour. I am worried about High DPI support, drag-and-drop functionality etc.

[Shashi] This is not required and hence removed.

Is there a simpler way to handle double-tap?
Windows converts taps to clicks, i.e. the app receives WM_LBUTTONDOWN and WM_LBUTTONUP.
Have you tried to find out why double-tap is not converted to double-click?

[Shashi] Since the mouse in pointer is disabled and a windows icon behavior is different from a windows button behavior(Because the a touch on the icon does not translate to a left button down event whereas it does for a windows button(file name!!)), it is required to bring in the WM_POINTER message type into the component message handling routine.

Do right and middle mouse buttons continue to work as expected? Mouse wheel? Any additional mouse buttons?

[Shashi] It should not have any effect after mouse in pointer is disabled.

The documentation for EnableMouseInPointer [1] says: ?This function can be called only once in the context of a process lifetime.? You call it for every component created. It would have been enough to call it once during Toolkit initialization.


Regards,
Alexey

[1] HYPERLINK "https://msdn.microsoft.com/en-us/library/windows/desktop/hh447467%28v=vs.85%29.aspx"https://msdn.microsoft.com/en-us/library/windows/desktop/hh447467(v=vs.85).aspx

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:

Hi Sergey, When I checked it was not working on the Java applications. None of the controls could take touch click events but it used to highlight because when we touch on the touch screen interface the system moves the cursor over to the touch point thereby enabling mouse focus events being sent.
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, September 19, 2017 3:39 AM
To: HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com >> Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface
?
Hi, Shashi.
Why the bug is JFileChooser specific?
Does it means that it works for other elements(buttons/lists/menu/etc)?
?
On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:

Hi All, Please review this software changes for the /_enhancement_/ 
JDK-8178361.
?
Issue: Request was filed to enable the touch event processing for Java 
client applications.
?
Fix: Windows platform offers 'pointer' implementation thro' which one 
can tap for the touch inputs as well. A typical 'pointer' function may 
contain touch, pen, touch pad or mouse inputs. This allows for a 
uniform input processing though the event source may defer. This fix 
enables the 'touch' events(via TOUCH pointer) to be passed to the 
components using the other type of pointer 'mouse'. Essentially there 
is a conversion put in place to convert a touch event input into a 
left click mouse event. I think this is the right thing to do 
considering desktop scenarios to which the typical Java applications 
that gets exposed to. This is also the same behavior on my touch 
enabled windows 10 laptop as well. Please let me know if a different behavior is expected. Below is the output:
?
Now touch event works as a typical mouse left click as in general. But 
there is an issue because the icon size of the Java UI is typically 
small, touching that icon exactly is sometimes difficult. This is 
handled by an Windows application by having larger icon size or icon 
view as a standard. Hence I believe this is outside the scope this 
software update. Any changes to it would be done later as a new bug or 
an enhancement.
?
Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361
?
Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8178361/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/
?
Thanks and regards,
?
Shashi
?

?
--
Best regards, Sergey.

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170927/113244e7/attachment-0001.html>

From semyon.sadetsky at oracle.com  Thu Sep 28 03:02:45 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 27 Sep 2017 20:02:45 -0700
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <66013f60-50d5-13cf-9e05-bce786295e9d@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
 <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
 <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>
 <40da60db-5074-bc18-d4bf-09b6b3040353@oracle.com>
 <8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com>
 <59CAD8C5.3040800@oracle.com>
 <66013f60-50d5-13cf-9e05-bce786295e9d@oracle.com>
Message-ID: <59CC6655.9070405@oracle.com>

Hi Alexey & Dmitry,

The bug may be a Mac specific issue.
Can you try to replace in the LWComponentPeer::requestFocus

960                boolean res = parentPeer.requestWindowFocus(cause);
with
                 KeyboardFocusManagerPeer kfmPeer = 
LWKeyboardFocusManagerPeer.getInstance();
                 Component focusOwner = kfmPeer.getCurrentFocusedWindow();
                 boolean res = parentPeer.getTarget() == focusOwner || 
parentPeer.requestWindowFocus(cause);

and run the test without the current fix on jdk10?

--Semyon

On 9/27/2017 1:45 PM, Alexey Ivanov wrote:
> Hi Semyon,
>
> You're right: the test does not fail for me too on Windows 10 using 
> jdk10. At the same time, I can reproduce the problem using 
> focus8Test.jar attached to the bug [1]. However, it's harder to 
> reproduce the issue using jdk10 or jdk9. It takes more attempts than 
> with jdk8.
>
>
> I could reproduce the problem on Windows 7 and Windows 10.
>
> However, if I switch the theme to Windows Basic or Windows Classic in 
> Windows 7, the issue cannot be reproduced any more. It looks as if 
> it's related to window animation when a new dialog appears and 
> disappears. If the dialog appears on the screen for a longer while, 
> the test does not fail either.
>
>
> Regards,
> Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8155197
>
> On 26/09/2017 23:46, Semyon Sadetsky wrote:
>> Hi Dmitry,
>>
>> On 9/26/2017 1:56 AM, Dmitry Markov wrote:
>>> Hi Semyon,
>>>
>>> Please find my answer inline.
>>>
>>> Thanks,
>>> Dmitry
>>>> On 25 Sep 2017, at 22:26, Semyon Sadetsky<semyon.sadetsky at oracle.com>  wrote:
>>>>
>>>> Hi Dmitry,
>>>>
>>>>
>>>> On 09/25/2017 01:09 PM, Dmitry Markov wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.
>>>> I couldn't get the test failed on 9 and 10. But I only tried it on Ubuntu. Is the issue a platform dependent?
>>> I was able to reproduce the issue on Windows and Mac OSX. I didn?t test Linux, but I guess it is present there too.
>>> Note: if you use VirtualBoxVM, it is necessary to enable 3D acceleration to reproduce the issue.
>> Not sure that 3D may change focus behavior. But I did not uses 
>> physical Ubuntu to test.
>> I also couldn't get the test failed on Windows platform after 10 
>> attempts:
>>
>> ssadetsk at SSADETSK-LAP1 /data/projects/client10/jdk
>> $ for ((n=0;n<10;n++)); do `/data/jtreg/bin/jtreg 
>> -jdk:../build/windows-x86_64-normal-server-fastdebug/jdk -nr 
>> test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java`; done
>> Test: extra argument ?passed:?
>> Test: extra argument ?passed:?
>> Test: extra argument ?passed:?
>> Test: extra argument ?passed:?
>> Test: extra argument ?passed:?
>> Test: extra argument ?passed:?
>> Test: extra argument ?passed:?
>> Test: extra argument ?passed:?
>> Test: extra argument ?passed:?
>> Test: extra argument ?passed:?
>>
>>>>> The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.
>>>> I see. What may prevent to set the input focus synchronously? Since the native window already has the focus this should be very deterministic.
>>> The native window loses focus if another window or dialog is displayed. Proposed fix is intended for the following case:
>>> The native window owns focus and we set the focus to one of its child components synchronously, (i.e. invoke doRestoreFocus() -> requestFocus()). At the same time another window/dialog pops up, requestFocus() fails because the native parent window is not the focus owner any more and we shift focus target to next component.
>> The requestFocus() calls the requestFocusHelper() which has several outcomes that returns "false". Which one of them should be involved?
>>
>> --Semyon
>>
>

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

From alexey.ivanov at oracle.com  Thu Sep 28 14:28:29 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 28 Sep 2017 15:28:29 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <59CABF7D.10201@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
 <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
 <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>
 <125d7526-1b85-d950-41c6-fbadebbde114@oracle.com>
 <9331b1e4-dea0-5f2e-3afd-a9e4a8010fc3@oracle.com> <59CABF7D.10201@oracle.com>
Message-ID: <151a2195-b6b0-5de0-237c-76c439e9df3d@oracle.com>

Hi Semyon,

On 26/09/2017 21:58, Semyon Sadetsky wrote:
> Hi Alexey,
>
> On 9/26/2017 12:29 PM, Alexey Ivanov wrote:
>> Hi Semyon,
>>
>> ShellFolder2.cpp
>> 944 pIcon->Extract(szBuf, index, &hIcon, *0*, sz);
>> I think 0 should really be |NULL|.
> Ok, but both represent the null pointer in Win32.

Yes, I know. Yet NULL makes it clear that it's a null-pointer rather 
than an index, size?
It's still zero in the latest review.

>
>> The result of the call is ignored now. Is it intentional?
> Yes, it has been working the same way before the fix. The function 
> returns the Icon reference which is 0 in case of OS API call error.
>
>>
>> Win32ShellFolder2.java
>> 1010 private static Image makeIcon(long hIcon, int bsize) {
>> |bsize| was called |baseSize| previously, and it conveyed the meaning 
>> better, didn't it?
>>
>> 1043 if(hIcon <= 0) {
>> 1044 if (isDirectory()) {
>> 1045 return getShell32Icon(4, size);
>> 1046 } else {
>> 1047 return getShell32Icon(1, size);
>> 1048 }
>> I guess I understand what hides behind 4 and 1: generic folder and 
>> generic file icon ids. Would declaring these numbers as constants 
>> improve readability?
> Ok.
>>
>> |getIcon(int size)| and |getIcon(boolean getLargeIcon)| are somewhat 
>> similar. The latter provides additional caching. Can it be simplified 
>> to re-use portions of new |getIcon(int size)|?
> It has additional difference because of query for a fixed icon size 
> from another API call.? It's better to leave it as it is.

Okay.


Regards,
Alexey

>
> http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.02/
>
> --Semyon
>>
>>
>> Regards,
>> Alexey
>>
>> On 22/09/2017 22:05, Semyon Sadetsky wrote:
>>>
>>> <SNIP>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170928/1ae71498/attachment.html>

From dmitry.markov at oracle.com  Thu Sep 28 15:14:04 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 28 Sep 2017 16:14:04 +0100
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <59CC6655.9070405@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
 <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
 <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>
 <40da60db-5074-bc18-d4bf-09b6b3040353@oracle.com>
 <8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com>
 <59CAD8C5.3040800@oracle.com>
 <66013f60-50d5-13cf-9e05-bce786295e9d@oracle.com>
 <59CC6655.9070405@oracle.com>
Message-ID: <616C9EA2-8C5B-4A23-AEFD-ED00E74C401B@oracle.com>

I have updated the regression test for the fix. The new version is located at http://cr.openjdk.java.net/~dmarkov/8155197/webrev.01/
Now the test is failed on the build without fix and passed on the build with the fix. Tested on Mac and Windows.

Many thanks to Alexey for his help with testing and valuable advice regarding test modifications.

Semyon,
I performed the test, you requested, (i.e. replaced the code in LWComponentPeer and ran the regression test on jdk10 build w/o the fix). Both versions of the regression test were failed. It looks like that result is quite expected, isn?t it?

Thanks,
Dmitry
> On 28 Sep 2017, at 04:02, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Alexey & Dmitry,
> 
> The bug may be a Mac specific issue.
> Can you try to replace in the LWComponentPeer::requestFocus
> 
> 960                boolean res = parentPeer.requestWindowFocus(cause);
> with
>                 KeyboardFocusManagerPeer kfmPeer = LWKeyboardFocusManagerPeer.getInstance();
>                 Component focusOwner = kfmPeer.getCurrentFocusedWindow();
>                 boolean res = parentPeer.getTarget() == focusOwner || parentPeer.requestWindowFocus(cause); 
> 
> and run the test without the current fix on jdk10?
> 
> --Semyon  
> 
> On 9/27/2017 1:45 PM, Alexey Ivanov wrote:
>> Hi Semyon,
>> 
>> You're right: the test does not fail for me too on Windows 10 using jdk10. At the same time, I can reproduce the problem using focus8Test.jar attached to the bug [1]. However, it's harder to reproduce the issue using jdk10 or jdk9. It takes more attempts than with jdk8.
>> 
>> 
>> I could reproduce the problem on Windows 7 and Windows 10.
>> 
>> However, if I switch the theme to Windows Basic or Windows Classic in Windows 7, the issue cannot be reproduced any more. It looks as if it's related to window animation when a new dialog appears and disappears. If the dialog appears on the screen for a longer while, the test does not fail either.
>> 
>> 
>> Regards,
>> Alexey
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8155197 <https://bugs.openjdk.java.net/browse/JDK-8155197>
>> 
>> On 26/09/2017 23:46, Semyon Sadetsky wrote:
>>> Hi Dmitry,
>>> 
>>> On 9/26/2017 1:56 AM, Dmitry Markov wrote:
>>>> Hi Semyon,
>>>> 
>>>> Please find my answer inline.
>>>> 
>>>> Thanks,
>>>> Dmitry
>>>>> On 25 Sep 2017, at 22:26, Semyon Sadetsky <semyon.sadetsky at oracle.com> <mailto:semyon.sadetsky at oracle.com> wrote:
>>>>> 
>>>>> Hi Dmitry,
>>>>> 
>>>>> 
>>>>> On 09/25/2017 01:09 PM, Dmitry Markov wrote:
>>>>>> Hi Semyon,
>>>>>> 
>>>>>> This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.
>>>>> I couldn't get the test failed on 9 and 10. But I only tried it on Ubuntu. Is the issue a platform dependent?
>>>> I was able to reproduce the issue on Windows and Mac OSX. I didn?t test Linux, but I guess it is present there too.
>>>> Note: if you use VirtualBoxVM, it is necessary to enable 3D acceleration to reproduce the issue.
>>> Not sure that 3D may change focus behavior. But I did not uses physical Ubuntu to test.
>>> I also couldn't get the test failed on Windows platform after 10 attempts:
>>> 
>>> ssadetsk at SSADETSK-LAP1 /data/projects/client10/jdk
>>> $ for ((n=0;n<10;n++)); do `/data/jtreg/bin/jtreg -jdk:../build/windows-x86_64-normal-server-fastdebug/jdk -nr test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java`; done
>>> Test: extra argument ?passed:?
>>> Test: extra argument ?passed:?
>>> Test: extra argument ?passed:?
>>> Test: extra argument ?passed:?
>>> Test: extra argument ?passed:?
>>> Test: extra argument ?passed:?
>>> Test: extra argument ?passed:?
>>> Test: extra argument ?passed:?
>>> Test: extra argument ?passed:?
>>> Test: extra argument ?passed:?
>>> 
>>>>>> The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.
>>>>> I see. What may prevent to set the input focus synchronously? Since the native window already has the focus this should be very deterministic.
>>>> The native window loses focus if another window or dialog is displayed. Proposed fix is intended for the following case:
>>>> The native window owns focus and we set the focus to one of its child components synchronously, (i.e. invoke doRestoreFocus() -> requestFocus()). At the same time another window/dialog pops up, requestFocus() fails because the native parent window is not the focus owner any more and we shift focus target to next component.
>>> The requestFocus() calls the requestFocusHelper() which has several outcomes that returns "false". Which one of them should be involved?
>>> 
>>> --Semyon
>>> 
>> 
> 

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

From semyon.sadetsky at oracle.com  Thu Sep 28 17:34:02 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 28 Sep 2017 10:34:02 -0700
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <616C9EA2-8C5B-4A23-AEFD-ED00E74C401B@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
 <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
 <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>
 <40da60db-5074-bc18-d4bf-09b6b3040353@oracle.com>
 <8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com>
 <59CAD8C5.3040800@oracle.com>
 <66013f60-50d5-13cf-9e05-bce786295e9d@oracle.com>
 <59CC6655.9070405@oracle.com>
 <616C9EA2-8C5B-4A23-AEFD-ED00E74C401B@oracle.com>
Message-ID: <59CD328A.7040009@oracle.com>

Hi Dmitry and Alexey,

On 9/28/2017 8:14 AM, Dmitry Markov wrote:
> I have updated the regression test for the fix. The new version is 
> located at http://cr.openjdk.java.net/~dmarkov/8155197/webrev.01/ 
> <http://cr.openjdk.java.net/%7Edmarkov/8155197/webrev.01/>
> Now the test is failed on the build without fix and passed on the 
> build with the fix. Tested on Mac and Windows.
>
> Many thanks to Alexey for his help with testing and valuable advice 
> regarding test modifications.
Now I can reproduce the issue. Thanks Alexey!
>
> Semyon,
> I performed the test, you requested, (i.e. replaced the code in 
> LWComponentPeer and ran the regression test on jdk10 build w/o the 
> fix). Both versions of the regression test were failed. It looks like 
> that result is quite expected, isn?t it?
Could be. I have my Mac env not ready yet and couldn't run your test 
there. So I followed the root cause you've suggested but it doesn't seem 
right.

Actually the parent frame doesn't own the input focus when the issue 
happens. The focus is on the dialog already and when FOCUS_GAINED event 
comes for the dialog the KFM discovers that the dialog should not have 
the focus and rejects it in line 588 of the DefaultKeyboardFocusManager:

                             restoreFocus(fe, newFocusedWindow);

This happens when the dialog became non-focusable (non-visible) after 
the focus request is sent, but before the corresponding FOCUS_GAINED 
event is handled on the EDT. In this case the focus is directly restored 
to the previously focused window which doesn't have the focus at this 
moment and input focus cannot be requested to one of its components 
synchronously.
Please confirm whether you agree on the root cause of the bug.

--Semyon
>
> Thanks,
> Dmitry
>> On 28 Sep 2017, at 04:02, Semyon Sadetsky <semyon.sadetsky at oracle.com 
>> <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> Hi Alexey & Dmitry,
>>
>> The bug may be a Mac specific issue.
>> Can you try to replace in the LWComponentPeer::requestFocus
>>
>> 960                boolean res = parentPeer.requestWindowFocus(cause);
>> with
>>                 KeyboardFocusManagerPeer kfmPeer = 
>> LWKeyboardFocusManagerPeer.getInstance();
>>                 Component focusOwner = kfmPeer.getCurrentFocusedWindow();
>>                 boolean res = parentPeer.getTarget() == focusOwner || 
>> parentPeer.requestWindowFocus(cause);
>>
>> and run the test without the current fix on jdk10?
>>
>> --Semyon
>>
>> On 9/27/2017 1:45 PM, Alexey Ivanov wrote:
>>> Hi Semyon,
>>>
>>> You're right: the test does not fail for me too on Windows 10 using 
>>> jdk10. At the same time, I can reproduce the problem using 
>>> focus8Test.jar attached to the bug [1]. However, it's harder to 
>>> reproduce the issue using jdk10 or jdk9. It takes more attempts than 
>>> with jdk8.
>>>
>>>
>>> I could reproduce the problem on Windows 7 and Windows 10.
>>>
>>> However, if I switch the theme to Windows Basic or Windows Classic 
>>> in Windows 7, the issue cannot be reproduced any more. It looks as 
>>> if it's related to window animation when a new dialog appears and 
>>> disappears. If the dialog appears on the screen for a longer while, 
>>> the test does not fail either.
>>>
>>>
>>> Regards,
>>> Alexey
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8155197
>>>
>>> On 26/09/2017 23:46, Semyon Sadetsky wrote:
>>>> Hi Dmitry,
>>>>
>>>> On 9/26/2017 1:56 AM, Dmitry Markov wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> Please find my answer inline.
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>>> On 25 Sep 2017, at 22:26, Semyon Sadetsky<semyon.sadetsky at oracle.com>  wrote:
>>>>>>
>>>>>> Hi Dmitry,
>>>>>>
>>>>>>
>>>>>> On 09/25/2017 01:09 PM, Dmitry Markov wrote:
>>>>>>> Hi Semyon,
>>>>>>>
>>>>>>> This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.
>>>>>> I couldn't get the test failed on 9 and 10. But I only tried it on Ubuntu. Is the issue a platform dependent?
>>>>> I was able to reproduce the issue on Windows and Mac OSX. I didn?t test Linux, but I guess it is present there too.
>>>>> Note: if you use VirtualBoxVM, it is necessary to enable 3D acceleration to reproduce the issue.
>>>> Not sure that 3D may change focus behavior. But I did not uses 
>>>> physical Ubuntu to test.
>>>> I also couldn't get the test failed on Windows platform after 10 
>>>> attempts:
>>>>
>>>> ssadetsk at SSADETSK-LAP1 /data/projects/client10/jdk
>>>> $ for ((n=0;n<10;n++)); do `/data/jtreg/bin/jtreg 
>>>> -jdk:../build/windows-x86_64-normal-server-fastdebug/jdk -nr 
>>>> test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java`; done
>>>> Test: extra argument ?passed:?
>>>> Test: extra argument ?passed:?
>>>> Test: extra argument ?passed:?
>>>> Test: extra argument ?passed:?
>>>> Test: extra argument ?passed:?
>>>> Test: extra argument ?passed:?
>>>> Test: extra argument ?passed:?
>>>> Test: extra argument ?passed:?
>>>> Test: extra argument ?passed:?
>>>> Test: extra argument ?passed:?
>>>>
>>>>>>> The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.
>>>>>> I see. What may prevent to set the input focus synchronously? Since the native window already has the focus this should be very deterministic.
>>>>> The native window loses focus if another window or dialog is displayed. Proposed fix is intended for the following case:
>>>>> The native window owns focus and we set the focus to one of its child components synchronously, (i.e. invoke doRestoreFocus() -> requestFocus()). At the same time another window/dialog pops up, requestFocus() fails because the native parent window is not the focus owner any more and we shift focus target to next component.
>>>> The requestFocus() calls the requestFocusHelper() which has several outcomes that returns "false". Which one of them should be involved?
>>>>
>>>> --Semyon
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170928/f6bf3e9a/attachment-0001.html>

From semyon.sadetsky at oracle.com  Thu Sep 28 17:41:13 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 28 Sep 2017 10:41:13 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <151a2195-b6b0-5de0-237c-76c439e9df3d@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
 <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
 <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>
 <125d7526-1b85-d950-41c6-fbadebbde114@oracle.com>
 <9331b1e4-dea0-5f2e-3afd-a9e4a8010fc3@oracle.com> <59CABF7D.10201@oracle.com>
 <151a2195-b6b0-5de0-237c-76c439e9df3d@oracle.com>
Message-ID: <59CD3439.2050906@oracle.com>

Hi Alexey,

On 9/28/2017 7:28 AM, Alexey Ivanov wrote:
> I think 0 should really be |NULL|.
>> Ok, but both represent the null pointer in Win32.
>
> Yes, I know. Yet NULL makes it clear that it's a null-pointer rather 
> than an index, size?
> It's still zero in the latest review.
Agh... I will fix it inline when push if you don't mind.

--Semyon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170928/adeea9ee/attachment.html>

From philip.race at oracle.com  Thu Sep 28 17:51:13 2017
From: philip.race at oracle.com (Philip Race)
Date: Thu, 28 Sep 2017 10:51:13 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <59CD3439.2050906@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
 <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
 <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>
 <125d7526-1b85-d950-41c6-fbadebbde114@oracle.com>
 <9331b1e4-dea0-5f2e-3afd-a9e4a8010fc3@oracle.com> <59CABF7D.10201@oracle.com>
 <151a2195-b6b0-5de0-237c-76c439e9df3d@oracle.com>
 <59CD3439.2050906@oracle.com>
Message-ID: <59CD3691.6050505@oracle.com>

If this is up for consideration for backporting - as appears to be the 
case - then
I think you should post an updated webrev.

-phil.

On 9/28/17, 10:41 AM, Semyon Sadetsky wrote:
> Hi Alexey,
>
> On 9/28/2017 7:28 AM, Alexey Ivanov wrote:
>> I think 0 should really be |NULL|.
>>> Ok, but both represent the null pointer in Win32.
>>
>> Yes, I know. Yet NULL makes it clear that it's a null-pointer rather 
>> than an index, size?
>> It's still zero in the latest review.
> Agh... I will fix it inline when push if you don't mind.
>
> --Semyon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170928/294d5024/attachment.html>

From alexey.ivanov at oracle.com  Thu Sep 28 17:51:37 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 28 Sep 2017 18:51:37 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <59CD3439.2050906@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
 <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
 <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>
 <125d7526-1b85-d950-41c6-fbadebbde114@oracle.com>
 <9331b1e4-dea0-5f2e-3afd-a9e4a8010fc3@oracle.com> <59CABF7D.10201@oracle.com>
 <151a2195-b6b0-5de0-237c-76c439e9df3d@oracle.com>
 <59CD3439.2050906@oracle.com>
Message-ID: <5bdf1232-7b90-8158-bfff-b82e203782ca@oracle.com>

Sure!

--
Alexey

On 28/09/2017 18:41, Semyon Sadetsky wrote:
> Hi Alexey,
>
> On 9/28/2017 7:28 AM, Alexey Ivanov wrote:
>> I think 0 should really be |NULL|.
>>> Ok, but both represent the null pointer in Win32.
>>
>> Yes, I know. Yet NULL makes it clear that it's a null-pointer rather 
>> than an index, size?
>> It's still zero in the latest review.
> Agh... I will fix it inline when push if you don't mind.
>
> --Semyon
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170928/bfe3e4b3/attachment.html>

From semyon.sadetsky at oracle.com  Thu Sep 28 17:57:14 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 28 Sep 2017 10:57:14 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <c93cc11b-1dc7-17bd-0b50-a115af96579a@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
 <59CAC884.6070207@oracle.com>
 <c93cc11b-1dc7-17bd-0b50-a115af96579a@oracle.com>
Message-ID: <59CD37FA.8010805@oracle.com>

Hi Sergey,

On 9/27/2017 12:22 PM, Sergey Bylokhov wrote:
> On 9/26/17 14:37, Semyon Sadetsky wrote:
>>> This means that on HiDPI screen the FILE_ICON_LARGE works in similar 
>>> way as FILE_ICON_SMALL on non-HiDPI screen, and the meaning of the 
>>> FILE_ICON_SMALL on HiDPI is unclear, because it is half of the 
>>> correct size.
>> Small and large don't have any special meanings for HiDPI. They are 
>> some conditional sizes established by the native platform for the 
>> current screen resolution.
>
> The question what is the current screens resolution when you have two 
> screens?
We should relay on the native platform always. So, the icon size 
returned by the native API is the correct approach. And possibility to 
use any other sizes is provided as well.
>
>> Why is it half of the correct size? It is the same size as for 
>> non-HiDPI and that is the correct size because otherwise java UI 
>> component that is HiDPI unaware would paint icons 2 times bigger in 
>> size than it is required. But the resolution of small/large icons may 
>> differs in case of HiDPI because it is determined by the size of the 
>> images returned by the native platform by the small/large icon queries.
>
> It is half of the correct size because on HiDPI it is better to use 
> hidpi icons instead of lowdpi. Will the HiDPI unaware apps draw x2 
> icons correctly or not depends from our implementation. If we will 
> return the MRI then it will be drawn in correct size even if the 
> bigger(HiDPI) image will be used.
This is not true. MRI has a basic size which uniquely determines its 
painted size in component coordinates. The size painted in component 
will be the same for all scales this is how HiDPI works in java.
>
>>>
>>> For example one of the consumer of this new API is WindowsFileView.
>>> How the code below should be changed to work on a different screens, 
>>> and request the proper icon?
>>> WindowsFileChooserUI.java
>>> 1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);
>> Why it should be changed? The code is requesting the proper icon.
>
> Because this method returns an icon of 16x16 pixels, which will be 
> rescaled to 32x32 pixels in paint operation.
The size should be equal 16x16 otherwise the component view will be 
distorted. But painted resolution is determined by native platform. The 
native platform may return icon of any size. If the size of the icon 
differs from 16x16 (32x32 for example) then it will be wrapped by MRI of 
16x16 size.

--Semyon



From semyon.sadetsky at oracle.com  Thu Sep 28 18:02:56 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 28 Sep 2017 11:02:56 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <59CD3691.6050505@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
 <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
 <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>
 <125d7526-1b85-d950-41c6-fbadebbde114@oracle.com>
 <9331b1e4-dea0-5f2e-3afd-a9e4a8010fc3@oracle.com> <59CABF7D.10201@oracle.com>
 <151a2195-b6b0-5de0-237c-76c439e9df3d@oracle.com>
 <59CD3439.2050906@oracle.com> <59CD3691.6050505@oracle.com>
Message-ID: <59CD3950.5080808@oracle.com>

On 9/28/2017 10:51 AM, Philip Race wrote:
> If this is up for consideration for backporting - as appears to be the 
> case - then
> I think you should post an updated webrev.
Not sure that we can backport it because this would change the API.

--Semyon
>
> -phil.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170928/ea14cc5f/attachment.html>

From philip.race at oracle.com  Thu Sep 28 18:21:56 2017
From: philip.race at oracle.com (Philip Race)
Date: Thu, 28 Sep 2017 11:21:56 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <59CD3950.5080808@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <fe279dfc-7748-49ea-0d71-be416c2ab2eb@oracle.com>
 <f21c95f2-b787-8a2b-390b-54625f6b064b@oracle.com>
 <cc2d0e78-f174-d697-8eb6-f8424ad33fbc@oracle.com>
 <bdc6eba7-92c1-b5c3-d2bf-4557487f50e5@oracle.com>
 <904ab740-1ac3-cf14-280e-bfa78e9d908d@oracle.com>
 <d0f15f7b-70d1-4f44-5984-ea073e8535d9@oracle.com>
 <125d7526-1b85-d950-41c6-fbadebbde114@oracle.com>
 <9331b1e4-dea0-5f2e-3afd-a9e4a8010fc3@oracle.com> <59CABF7D.10201@oracle.com>
 <151a2195-b6b0-5de0-237c-76c439e9df3d@oracle.com>
 <59CD3439.2050906@oracle.com> <59CD3691.6050505@oracle.com>
 <59CD3950.5080808@oracle.com>
Message-ID: <59CD3DC4.8060509@oracle.com>

We definitely can't backport an API change.
Reading the bug report it seems they have been doing this by using 
internal APIs.
For JDK 9, since illegal-access is allowed by default, they can continue 
to do that,
so perhaps we can just not worry about the backport and solve this only 
for 10 +
They can add reflective code to look for the 10 solution so it can run 
on all releases
and automatically take advantage of the new API when it appears.
Of course they should also re-work the existing code to be reflective 
and defer
to the new API. If they do this then it would also be safe when illegal 
access is denied by default ..
since it should be in a later release than the new API.

-phil

On 9/28/17, 11:02 AM, Semyon Sadetsky wrote:
> On 9/28/2017 10:51 AM, Philip Race wrote:
>> If this is up for consideration for backporting - as appears to be 
>> the case - then
>> I think you should post an updated webrev.
> Not sure that we can backport it because this would change the API.
>
> --Semyon
>>
>> -phil.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170928/09630f99/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Thu Sep 28 18:49:22 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 28 Sep 2017 11:49:22 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <59CD37FA.8010805@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
 <59CAC884.6070207@oracle.com>
 <c93cc11b-1dc7-17bd-0b50-a115af96579a@oracle.com>
 <59CD37FA.8010805@oracle.com>
Message-ID: <0ee0bd28-bf23-b726-97b4-8bbde57e65bc@oracle.com>

On 9/28/17 10:57, Semyon Sadetsky wrote:
>>> Small and large don't have any special meanings for HiDPI. They are 
>>> some conditional sizes established by the native platform for the 
>>> current screen resolution.
>>
>> The question what is the current screens resolution when you have two 
>> screens?
> We should relay on the native platform always. So, the icon size 
> returned by the native API is the correct approach. And possibility to 
> use any other sizes is provided as well.

On windows and Linux we cannot rely on the native system because all 
HiDPI support is implemented on our(jdk) side, the native system does 
not know how this icons are used.

>> It is half of the correct size because on HiDPI it is better to use 
>> hidpi icons instead of lowdpi. Will the HiDPI unaware apps draw x2 
>> icons correctly or not depends from our implementation. If we will 
>> return the MRI then it will be drawn in correct size even if the 
>> bigger(HiDPI) image will be used.
> This is not true. MRI has a basic size which uniquely determines its 
> painted size in component coordinates. The size painted in component 
> will be the same for all scales this is how HiDPI works in java.

The size in a component coordinates will be the same, but if HiDPI image 
is used the real number of pixels to be drawn will be 4 times bigger, 
because low-dpi images will be scaled x2 and HiDPI images will be drawn 
as is.

>>>> For example one of the consumer of this new API is WindowsFileView.
>>>> How the code below should be changed to work on a different screens, 
>>>> and request the proper icon?
>>>> WindowsFileChooserUI.java
>>>> 1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);
>>> Why it should be changed? The code is requesting the proper icon.
>>
>> Because this method returns an icon of 16x16 pixels, which will be 
>> rescaled to 32x32 pixels in paint operation.
> The size should be equal 16x16 otherwise the component view will be 
> distorted. But painted resolution is determined by native platform. The 
> native platform may return icon of any size. If the size of the icon 
> differs from 16x16 (32x32 for example) then it will be wrapped by MRI of 
> 16x16 size.

The draw resolution cannot be calculated by the native platform for each 
window in java. The windows provide a set of icons for each resolution, 
and we should select correct one depending from the scalefactor of our 
window. And we should draw bigger icons when the bigger dpi is in use.

from the example above the code in WindowsFileChooserUI will use low-dpi 
icons on a HiDPI screen:
1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);

How we should rewrite this code using a new API to support the icons 
which are large than default?

-- 
Best regards, Sergey.

From alexey.ivanov at oracle.com  Fri Sep 29 14:11:36 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 29 Sep 2017 15:11:36 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <0ee0bd28-bf23-b726-97b4-8bbde57e65bc@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
 <59CAC884.6070207@oracle.com>
 <c93cc11b-1dc7-17bd-0b50-a115af96579a@oracle.com>
 <59CD37FA.8010805@oracle.com>
 <0ee0bd28-bf23-b726-97b4-8bbde57e65bc@oracle.com>
Message-ID: <e85f8743-8c06-b847-a0a4-a7fb94098759@oracle.com>

Hi Sergey and Semyon,

On 28/09/2017 19:49, Sergey Bylokhov wrote:
> On 9/28/17 10:57, Semyon Sadetsky wrote:
>>>> Small and large don't have any special meanings for HiDPI. They are 
>>>> some conditional sizes established by the native platform for the 
>>>> current screen resolution.
>>>
>>> The question what is the current screens resolution when you have 
>>> two screens?
>> We should relay on the native platform always. So, the icon size 
>> returned by the native API is the correct approach. And possibility 
>> to use any other sizes is provided as well.
>
> On windows and Linux we cannot rely on the native system because all 
> HiDPI support is implemented on our(jdk) side, the native system does 
> not know how this icons are used.
>
>>> It is half of the correct size because on HiDPI it is better to use 
>>> hidpi icons instead of lowdpi. Will the HiDPI unaware apps draw x2 
>>> icons correctly or not depends from our implementation. If we will 
>>> return the MRI then it will be drawn in correct size even if the 
>>> bigger(HiDPI) image will be used.
>> This is not true. MRI has a basic size which uniquely determines its 
>> painted size in component coordinates. The size painted in component 
>> will be the same for all scales this is how HiDPI works in java.
>
> The size in a component coordinates will be the same, but if HiDPI 
> image is used the real number of pixels to be drawn will be 4 times 
> bigger, because low-dpi images will be scaled x2 and HiDPI images will 
> be drawn as is.
>
>>>>> For example one of the consumer of this new API is WindowsFileView.
>>>>> How the code below should be changed to work on a different 
>>>>> screens, and request the proper icon?
>>>>> WindowsFileChooserUI.java
>>>>> 1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);
>>>> Why it should be changed? The code is requesting the proper icon.
>>>
>>> Because this method returns an icon of 16x16 pixels, which will be 
>>> rescaled to 32x32 pixels in paint operation.
>> The size should be equal 16x16 otherwise the component view will be 
>> distorted. But painted resolution is determined by native platform. 
>> The native platform may return icon of any size. If the size of the 
>> icon differs from 16x16 (32x32 for example) then it will be wrapped 
>> by MRI of 16x16 size.
>
> The draw resolution cannot be calculated by the native platform for 
> each window in java. The windows provide a set of icons for each 
> resolution, and we should select correct one depending from the 
> scalefactor of our window. And we should draw bigger icons when the 
> bigger dpi is in use.
>
> from the example above the code in WindowsFileChooserUI will use 
> low-dpi icons on a HiDPI screen:
> 1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);
>
> How we should rewrite this code using a new API to support the icons 
> which are large than default?

If I understand correctly, the introduction of the new API does not 
change the behaviour in this case, does it?

The icon extracted from Windows was 16?16 and will continue to be used.
That is the icon will be scaled when painted.

To support HiDPI displays the implementation of 
|getFileChooser().getFileSystemView().getSystemIcon(f)| should be 
enhanced to fetch the icon at the appropriate size according to the 
current rendering scale. I mean in standard resolution, get 16?16 icon, 
for 125% scale factor, get 20?20 icon, for 150% scale factor, get icon 
24?24. (As far as I know, |IExtractIcon::Extract| does not perform any 
scaling to account for HiDPI rendering. And it really can't because 
different displays can have different DPI settings. Thus if you request 
icon size of 16?16, you'll get 16?16 icon, not 32?32 even if this size 
is more appropriate to the current HiDPI scaling.)

Different icon sizes could be combined into MRI lazily.
To support it, we could use different APIs to extract the icons. For 
example, we can get the list of icon sizes for a file type, and extract 
only ?native? size. If larger size is required for HiDPI and the icon 
has it, then get the larger version and use it for rendering rather than 
scaling the one we already have.

However, it looks to be out of the scope for this particular fix. Yet 
this approach will make UI look crispier at higher resolutions.


Regards,
Alexey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170929/d1bfbaa9/attachment.html>

From alexey.ivanov at oracle.com  Fri Sep 29 14:34:04 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 29 Sep 2017 15:34:04 +0100
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
Message-ID: <c6d0e691-4122-0840-e7b6-299df5198011@oracle.com>

Hi Sergey,

On 25/09/2017 21:44, Sergey Bylokhov wrote:
> On 9/22/17 04:22, Alexey Ivanov wrote:
>> There's no way of knowing in advance.
>> Explorer does not restrict the size of icons (now), it's up to 
>> developers of a particular file handler to provide icons. Usually, 
>> there's only one icon with size larger than 255.
>>
>> If there's the icon of the requested size, Explorer will give it to 
>> you, otherwise it will scale the closest available to the requested 
>> size.
>>
>> Windows documentation suggests the following sizes:
>> https://msdn.microsoft.com/en-us/library/windows/desktop/dn742485(v=vs.85).aspx#size_requirements 
>
>
> Ok, so it means that we will support 1-128 pixels 
> natively(MAX_ICON_SIZE) and others via MRI.

Why 128 pixels? Windows shell usually provides icons up to 256 pixels, 
for example there are 256?256 icons for folders and generic file type.

Since |IExtractIcon::Extract| gives you the requested size, performing 
scaling if required, then MRI will never be created.


As for sizes, 16 seems to be the minimum icon size (Windows shell 
overlay icons are 10?10). The reasonable maximum size seems to be 256.


Regards,
Alexey

> <SNIP>

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

From dmitry.markov at oracle.com  Fri Sep 29 16:57:25 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Fri, 29 Sep 2017 17:57:25 +0100
Subject: <AWT Dev> [10] Review request for 8155197: Focus transition
	issue
In-Reply-To: <59CD328A.7040009@oracle.com>
References: <0F11EB94-359A-4639-A13E-A1F65F792B3E@oracle.com>
 <f1784845-d103-232e-32a2-93ed49f5a9e7@oracle.com>
 <AF31D9B9-F169-4B5D-AF18-861CA32A0E5B@oracle.com>
 <40da60db-5074-bc18-d4bf-09b6b3040353@oracle.com>
 <8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com>
 <59CAD8C5.3040800@oracle.com>
 <66013f60-50d5-13cf-9e05-bce786295e9d@oracle.com>
 <59CC6655.9070405@oracle.com>
 <616C9EA2-8C5B-4A23-AEFD-ED00E74C401B@oracle.com>
 <59CD328A.7040009@oracle.com>
Message-ID: <0EAF6541-6965-4D8C-BB72-16A547751676@oracle.com>

Hi Semyon,

> On 28 Sep 2017, at 18:34, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Dmitry and Alexey,
> 
> On 9/28/2017 8:14 AM, Dmitry Markov wrote:
>> I have updated the regression test for the fix. The new version is located at http://cr.openjdk.java.net/~dmarkov/8155197/webrev.01/ <http://cr.openjdk.java.net/%7Edmarkov/8155197/webrev.01/>
>> Now the test is failed on the build without fix and passed on the build with the fix. Tested on Mac and Windows.
>> 
>> Many thanks to Alexey for his help with testing and valuable advice regarding test modifications.
> Now I can reproduce the issue. Thanks Alexey!
>> 
>> Semyon,
>> I performed the test, you requested, (i.e. replaced the code in LWComponentPeer and ran the regression test on jdk10 build w/o the fix). Both versions of the regression test were failed. It looks like that result is quite expected, isn?t it?
> Could be. I have my Mac env not ready yet and couldn't run your test there. So I followed the root cause you've suggested but it doesn't seem right.
> 
> Actually the parent frame doesn't own the input focus when the issue happens. The focus is on the dialog already and when FOCUS_GAINED event comes for the dialog the KFM discovers that the dialog should not have the focus and rejects it in line 588 of the DefaultKeyboardFocusManager:
> 
>                             restoreFocus(fe, newFocusedWindow);
> 
> This happens when the dialog became non-focusable (non-visible) after the focus request is sent, but before the corresponding FOCUS_GAINED event is handled on the EDT. In this case the focus is directly restored to the previously focused window which doesn't have the focus at this moment and input focus cannot be requested to one of its components synchronously.
> Please confirm whether you agree on the root cause of the bug.
> 
You are right. I agree with your evaluation.

Thanks,
Dmitry
> --Semyon
>> 
>> Thanks,
>> Dmitry
>>> On 28 Sep 2017, at 04:02, Semyon Sadetsky < <mailto:semyon.sadetsky at oracle.com>semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>> 
>>> Hi Alexey & Dmitry,
>>> 
>>> The bug may be a Mac specific issue.
>>> Can you try to replace in the LWComponentPeer::requestFocus
>>> 
>>> 960                boolean res = parentPeer.requestWindowFocus(cause);
>>> with
>>>                 KeyboardFocusManagerPeer kfmPeer = LWKeyboardFocusManagerPeer.getInstance();
>>>                 Component focusOwner = kfmPeer.getCurrentFocusedWindow();
>>>                 boolean res = parentPeer.getTarget() == focusOwner || parentPeer.requestWindowFocus(cause); 
>>> 
>>> and run the test without the current fix on jdk10?
>>> 
>>> --Semyon  
>>> 
>>> On 9/27/2017 1:45 PM, Alexey Ivanov wrote:
>>>> Hi Semyon,
>>>> 
>>>> You're right: the test does not fail for me too on Windows 10 using jdk10. At the same time, I can reproduce the problem using focus8Test.jar attached to the bug [1]. However, it's harder to reproduce the issue using jdk10 or jdk9. It takes more attempts than with jdk8.
>>>> 
>>>> 
>>>> I could reproduce the problem on Windows 7 and Windows 10.
>>>> 
>>>> However, if I switch the theme to Windows Basic or Windows Classic in Windows 7, the issue cannot be reproduced any more. It looks as if it's related to window animation when a new dialog appears and disappears. If the dialog appears on the screen for a longer while, the test does not fail either.
>>>> 
>>>> 
>>>> Regards,
>>>> Alexey
>>>> 
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8155197 <https://bugs.openjdk.java.net/browse/JDK-8155197>
>>>> 
>>>> On 26/09/2017 23:46, Semyon Sadetsky wrote:
>>>>> Hi Dmitry,
>>>>> 
>>>>> On 9/26/2017 1:56 AM, Dmitry Markov wrote:
>>>>>> Hi Semyon,
>>>>>> 
>>>>>> Please find my answer inline.
>>>>>> 
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>>> On 25 Sep 2017, at 22:26, Semyon Sadetsky <semyon.sadetsky at oracle.com> <mailto:semyon.sadetsky at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Dmitry,
>>>>>>> 
>>>>>>> 
>>>>>>> On 09/25/2017 01:09 PM, Dmitry Markov wrote:
>>>>>>>> Hi Semyon,
>>>>>>>> 
>>>>>>>> This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.
>>>>>>> I couldn't get the test failed on 9 and 10. But I only tried it on Ubuntu. Is the issue a platform dependent?
>>>>>> I was able to reproduce the issue on Windows and Mac OSX. I didn?t test Linux, but I guess it is present there too.
>>>>>> Note: if you use VirtualBoxVM, it is necessary to enable 3D acceleration to reproduce the issue.
>>>>> Not sure that 3D may change focus behavior. But I did not uses physical Ubuntu to test.
>>>>> I also couldn't get the test failed on Windows platform after 10 attempts:
>>>>> 
>>>>> ssadetsk at SSADETSK-LAP1 /data/projects/client10/jdk
>>>>> $ for ((n=0;n<10;n++)); do `/data/jtreg/bin/jtreg -jdk:../build/windows-x86_64-normal-server-fastdebug/jdk -nr test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java`; done
>>>>> Test: extra argument ?passed:?
>>>>> Test: extra argument ?passed:?
>>>>> Test: extra argument ?passed:?
>>>>> Test: extra argument ?passed:?
>>>>> Test: extra argument ?passed:?
>>>>> Test: extra argument ?passed:?
>>>>> Test: extra argument ?passed:?
>>>>> Test: extra argument ?passed:?
>>>>> Test: extra argument ?passed:?
>>>>> Test: extra argument ?passed:?
>>>>> 
>>>>>>>> The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.
>>>>>>> I see. What may prevent to set the input focus synchronously? Since the native window already has the focus this should be very deterministic.
>>>>>> The native window loses focus if another window or dialog is displayed. Proposed fix is intended for the following case:
>>>>>> The native window owns focus and we set the focus to one of its child components synchronously, (i.e. invoke doRestoreFocus() -> requestFocus()). At the same time another window/dialog pops up, requestFocus() fails because the native parent window is not the focus owner any more and we shift focus target to next component.
>>>>> The requestFocus() calls the requestFocusHelper() which has several outcomes that returns "false". Which one of them should be involved?
>>>>> 
>>>>> --Semyon
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170929/01ab6934/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Fri Sep 29 19:29:54 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 29 Sep 2017 12:29:54 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <c6d0e691-4122-0840-e7b6-299df5198011@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
 <c6d0e691-4122-0840-e7b6-299df5198011@oracle.com>
Message-ID: <ad702cb9-f4b3-3b90-fbdc-5fdb652d1e28@oracle.com>

On 9/29/17 07:34, Alexey Ivanov wrote:
>> Ok, so it means that we will support 1-128 pixels 
>> natively(MAX_ICON_SIZE) and others via MRI.
> 
> Why 128 pixels? Windows shell usually provides icons up to 256 pixels, 
> for example there are 256?256 icons for folders and generic file type.

It is limitation of our implementation:
https://bugs.openjdk.java.net/browse/JDK-8151385
http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html

> 
> Since |IExtractIcon::Extract| gives you the requested size, performing 
> scaling if required, then MRI will never be crea

As far as I understand the bug above, it is possible that OS returns 
some other size.


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 29 19:39:35 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 29 Sep 2017 12:39:35 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <ad702cb9-f4b3-3b90-fbdc-5fdb652d1e28@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
 <c6d0e691-4122-0840-e7b6-299df5198011@oracle.com>
 <ad702cb9-f4b3-3b90-fbdc-5fdb652d1e28@oracle.com>
Message-ID: <59CEA177.5010305@oracle.com>



On 9/29/2017 12:29 PM, Sergey Bylokhov wrote:
> On 9/29/17 07:34, Alexey Ivanov wrote:
>>> Ok, so it means that we will support 1-128 pixels 
>>> natively(MAX_ICON_SIZE) and others via MRI.
>>
>> Why 128 pixels? Windows shell usually provides icons up to 256 
>> pixels, for example there are 256?256 icons for folders and generic 
>> file type.
>
> It is limitation of our implementation:
> https://bugs.openjdk.java.net/browse/JDK-8151385
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html
>
Sergey, it is not clear how those links are related to the icon size 
returned by Windows?
>>
>> Since |IExtractIcon::Extract| gives you the requested size, 
>> performing scaling if required, then MRI will never be crea
>
> As far as I understand the bug above, it is possible that OS returns 
> some other size.
You've probably didn't understand what Alexey meant. The Extract call 
may return any size you request (it does scaling internally if there are 
no suitable image). But the bug above is about queering the fixed size 
(small or long) which size is determined by OS shell according to the 
current scale. For those fixed sizes we use SHGetFileInfo not the Extract.

--Semyon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170929/af087e56/attachment.html>

From Sergey.Bylokhov at oracle.com  Fri Sep 29 21:06:46 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 29 Sep 2017 14:06:46 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <e85f8743-8c06-b847-a0a4-a7fb94098759@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
 <59CAC884.6070207@oracle.com>
 <c93cc11b-1dc7-17bd-0b50-a115af96579a@oracle.com>
 <59CD37FA.8010805@oracle.com>
 <0ee0bd28-bf23-b726-97b4-8bbde57e65bc@oracle.com>
 <e85f8743-8c06-b847-a0a4-a7fb94098759@oracle.com>
Message-ID: <33b00e0b-5b67-4a32-a4ee-fcdc32099071@oracle.com>

On 9/29/17 07:11, Alexey Ivanov wrote:
> If I understand correctly, the introduction of the new API does not 
> change the behaviour in this case, does it?
> 
> The icon extracted from Windows was 16?16 and will continue to be used.
> That is the icon will be scaled when painted.
> 
> To support HiDPI displays the implementation of 
> |getFileChooser().getFileSystemView().getSystemIcon(f)| should be 
> enhanced to fetch the icon at the appropriate size according to the 
> current rendering scale. I mean in standard resolution, get 16?16 icon, 
> for 125% scale factor, get 20?20 icon, for 150% scale factor, get icon 
> 24?24. (As far as I know, |IExtractIcon::Extract| does not perform any 
> scaling to account for HiDPI rendering. And it really can't because 
> different displays can have different DPI settings. Thus if you request 
> icon size of 16?16, you'll get 16?16 icon, not 32?32 even if this size 
> is more appropriate to the current HiDPI scaling.)

Yes, the old getSystemIcon(f) can be enhanced to support MRI and this 
will fix all its usages. But my point was for a new API and how this new 
API can solve the problem of access to different dpi icons.
  - We cannot use FILE_ICON_SMALL because it does not depend from the 
screen, and it is unclear what the small icons means.
  - We cannot use FILE_ICON_LARGE by the same reason.
  - We cannot request some specific size because we know the scale which 
should be applied to the default icon, but we do not know the size of 
the default icon.
So everywhere we should do something like this:
Icon icon = getSystemIcon(file);
Icon hicon = getSystemIcon(file, icon.getIconWidth()*screenScale);


> Different icon sizes could be combined into MRI lazily.
> To support it, we could use different APIs to extract the icons. For 
> example, we can get the list of icon sizes for a file type, and extract 
> only ?native? size. If larger size is required for HiDPI and the icon 
> has it, then get the larger version and use it for rendering rather than 
> scaling the one we already have.

It is not necessary to update other parts of the Swing right now, but it 
should be possible to update it later and use the new API which will be 
added in this fix, since this fix is a about access to a good quality 
icons, some comments here:
https://bugs.openjdk.java.net/browse/JDK-8156183

> 
> However, it looks to be out of the scope for this particular fix. Yet 
> this approach will make UI look crispier at higher resolutions.



-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Sep 29 22:15:16 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 29 Sep 2017 15:15:16 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <59CEA177.5010305@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
 <c6d0e691-4122-0840-e7b6-299df5198011@oracle.com>
 <ad702cb9-f4b3-3b90-fbdc-5fdb652d1e28@oracle.com>
 <59CEA177.5010305@oracle.com>
Message-ID: <6b4d35b9-2d1f-0010-a7b6-ed2e17dfa661@oracle.com>

On 9/29/17 12:39, Semyon Sadetsky wrote:
>>> Why 128 pixels? Windows shell usually provides icons up to 256 
>>> pixels, for example there are 256?256 icons for folders and generic 
>>> file type.
>>
>> It is limitation of our implementation:
>> https://bugs.openjdk.java.net/browse/JDK-8151385
>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html
>>
> Sergey, it is not clear how those links are related to the icon size 
> returned by Windows?

It was a fix where the MAX_ICON_SIZE=128 was added.

>> As far as I understand the bug above, it is possible that OS returns 
>> some other size.
> You've probably didn't understand what Alexey meant. The Extract call 
> may return any size you request (it does scaling internally if there are 
> no suitable image) > But the bug above is about queering the fixed size
> (small or long) which size is determined by OS shell according to the 
> current scale. For those fixed sizes we use SHGetFileInfo not the Extract.

And every time we will try to make an icon it will be limited to 
128x128. But it is not critical.

The issue is that this api, as you said, will depends from some general 
"current scale". which is unrelated to the transform of the screen in java.

If the user will want to use FILE_ICON_LARGE, then to work properly he 
will need to use this code every time in the the paint():
Icon icon = getSystemIcon(file, FILE_ICON_LARGE);
Icon hicon = getSystemIcon(file, icon.getIconWidth()*currentScreenScale);


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 29 23:08:19 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 29 Sep 2017 16:08:19 -0700
Subject: <AWT Dev> <Swing Dev> [10] Review request for 8182043: Access
 to Windows Large Icons
In-Reply-To: <6b4d35b9-2d1f-0010-a7b6-ed2e17dfa661@oracle.com>
References: <cc98aff9-0a3c-e259-9667-b5fd9a38c912@oracle.com>
 <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com>
 <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com>
 <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com>
 <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com>
 <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com>
 <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com>
 <d35d8d7d-cd83-c136-b349-4fc6da0da611@oracle.com>
 <c6d0e691-4122-0840-e7b6-299df5198011@oracle.com>
 <ad702cb9-f4b3-3b90-fbdc-5fdb652d1e28@oracle.com>
 <59CEA177.5010305@oracle.com>
 <6b4d35b9-2d1f-0010-a7b6-ed2e17dfa661@oracle.com>
Message-ID: <59CED263.4000104@oracle.com>



On 9/29/2017 3:15 PM, Sergey Bylokhov wrote:
> On 9/29/17 12:39, Semyon Sadetsky wrote:
>>>> Why 128 pixels? Windows shell usually provides icons up to 256 
>>>> pixels, for example there are 256?256 icons for folders and generic 
>>>> file type.
>>>
>>> It is limitation of our implementation:
>>> https://bugs.openjdk.java.net/browse/JDK-8151385
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html
>>>
>> Sergey, it is not clear how those links are related to the icon size 
>> returned by Windows?
>
> It was a fix where the MAX_ICON_SIZE=128 was added.
Actually it limits nothing. We told about the Extract call which may 
return any size.
>
>>> As far as I understand the bug above, it is possible that OS returns 
>>> some other size.
>> You've probably didn't understand what Alexey meant. The Extract call 
>> may return any size you request (it does scaling internally if there 
>> are no suitable image) > But the bug above is about queering the 
>> fixed size
>> (small or long) which size is determined by OS shell according to the 
>> current scale. For those fixed sizes we use SHGetFileInfo not the 
>> Extract.
>
> And every time we will try to make an icon it will be limited to 
> 128x128. But it is not critical.
>
> The issue is that this api, as you said, will depends from some 
> general "current scale". which is unrelated to the transform of the 
> screen in java.
>
> If the user will want to use FILE_ICON_LARGE, then to work properly he 
> will need to use this code every time in the the paint():
> Icon icon = getSystemIcon(file, FILE_ICON_LARGE);
> Icon hicon = getSystemIcon(file, icon.getIconWidth()*currentScreenScale);
This is just wrong. The first line is the correct one for both HiDPI and 
nonHiDPI. If you want to have icons like in native apps. For custom 
behavior - please use the second line.