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: <Swing 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 Sergey.Bylokhov at oracle.com  Sun Sep  3 01:31:49 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 2 Sep 2017 18:31:49 -0700
Subject: <Swing Dev> [10] RFR JDK-8175968: The
 javax.swing.filechooser.FileSystemView constructor consumes memory by
 adding a PropertyChangeListener that is never removed.
In-Reply-To: <632a6d41-29ab-4838-b0ee-61fbfd0a7d86@default>
References: <632a6d41-29ab-4838-b0ee-61fbfd0a7d86@default>
Message-ID: <0e3d6cfb-290b-be27-0702-218febd67126@oracle.com>

Any volunteers to review?
Thank you =)

On 8/27/17 14:19, Sergey Bylokhov wrote:
> Hi,
> I would like to propose a new review as a solution which I think should solve the problem:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8175968
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8175968/webrev.00
> 
> ----- ldubox-coding101 at yahoo.co.uk wrote:
> 
>> Hi all,
>>
>>   > but imho it still beats adding an extra method to the API
>>   > and shifting the burden to the API user.
>>
>> Just a question, would you be an "API user" of this method
>> directly? It seems to me that dispose() could be called somewhere
>> knowing more about the lifetime of this object (possibly from
>> BasicFileChooserUI) so that it remains an implementation
>> detail to most users of JFileChooser.
>>
>> The WeakReference trick would then just be a (poor) fallback
>> mechanism.
>>
>> So this trick (introduced somewhere between Java 6 and 8)
>> never worked. As mentioned, the key is to ensure the listeneris
>> a static inner class. For example, this works:
>>
>>       private PropertyChangeListener pcl;
>>
>>       public FileSystemView() {
>>           pcl = createPropertyChangeListener();
>>       }
>>
>>       private static createPropertyChangeListener() {
>>            // current content of constructor goes here
>>       }
>>
>> The 'static' is all-important, so that the anonymous listener class
>> becomes static also, and doesn't have a synthetic reference to
>> the outer class.
>>
>>
>>   > Thanks to the weak listener, the FileSystemView will get GC-ed as
>>   > the listener no longer keeps a hard reference to it.
>>
>> I don't think a Weak Listener helps - the code you referenced earlier
>> suffers the same limitation as the current code: The reference
>> isn't freedunless a new property change event comes along. Property
>> changeevents are very infrequent from UIManager - typically never.
>>
>>
>> I've also been struggling to see a good alternative to dispose().
>> Finalizers came to mind also but ... (UPDATE: deprecated now huh?
>> OK forget it then.)
>>
>> An alternative could be a timer, but that's a lot of extra baggage.
>>
>> IF THIS WERE APPLICATION CODE a trick like this might work,
>> removing the need for both the listener and dispose():
>>
>>       private Boolean useSystemExtensionHiding = null;
>>
>>       private boolean getUseSystemExtensionHiding() {
>>
>>           assert SwingUtilities.isEventDispatchThread();
>>
>>           if (useSystemExtensionHiding == null) {
>>               useSystemExtensionHiding =
>>                  
>> UIManager.getDefaults().getBoolean("FileChooser.useSystemExtensionHiding");
>>
>>               SwingUtilities.invokeLater(() -> useSystemExtensionHiding
>> = null);
>>           }
>>
>>           return useSystemExtensionHiding;
>>       }
>>
>> After all, the caching is just an optimisation to avoid repeated
>> map-lookups during painting (right?) The above reduces it to
>> once per full component paint, which is a small cost.
>>
>> But being library code I'm not sure if it's safe to make such
>> assumptions (that the EDT event loop is running, for example).
>> (Expert opinion?)
>>
>>
>> ACTUALLY if avoiding dispose() is preferred - then I wonder if the
>> optimisation is "past its expiry date"? The "free lunch may be
>> over" now, but it was still being delivered since Java 1.1 :-)
>>
>> What is the cost of one map lookup (per file) compared to the cost
>> of painting an icon for each file, for example? I'd guess they're
>> about on-par.
>>
>> Would it be so bad to just drop the caching of this boolean
>> altogether?
>>
>> Kind regards,
>> Luke
>>
>>
>>
>> On 07/07/2017 09:21, Robin Stevens wrote:
>>> I still do not think you need a public dispose method.
>>> If you use the weak listener (the correct implementation), the
>>> FileSystemView instance can be GC-ed, even when the
>>> PropertyChangeListener is still attached to the UIManager.
>>>
>>> What you can do is:
>>> - Store a reference to the PropertyChangeListener in the
>>> FileSystemView class as a field.
>>> - Override the finalize method of the FileSystemView class to
>>> de-register the PropertyChangeListener from the UIManager. Thanks to
>>
>>> the weak listener, the FileSystemView will get GC-ed as the listener
>>
>>> no longer keeps a hard reference to it.
>>>
>>> Not the nicest way to do such cleanup (which should probably happen
>> on
>>> the EDT) in a finalizer, but imho it still beats adding an extra
>>> method to the API and shifting the burden to the API user.
>>>
>>> Robin
>>>
>>> On Thu, Jul 6, 2017 at 3:15 PM, Prasanta Sadhukhan
>>> <prasanta.sadhukhan at oracle.com
>>> <mailto:prasanta.sadhukhan at oracle.com>>wrote:
>>>
>>>      Hi Sergey,
>>>
>>>      I tried with the proposed WeakPropertyChangeListener but as far
>> I
>>>      understand & tested, it seems also to rely on propertyChange()
>> API
>>>      to be called, so the scenario mentioned in the bug will still
>> fail.
>>>      I cannot find any other way rather than calling dispose() for
>> the
>>>      scenario mentioned there.
>>>
>>>      Regards
>>>      Prasanta
>>>
>>>      On 7/5/2017 4:35 AM, Sergey Bylokhov wrote:
>>>
>>>          Hi, Prasanta.
>>>          Probably it is possible to implement it without users
>>>          interaction and new api?
>>>
>>>          ----- prasanta.sadhukhan at oracle.com
>>>          <mailto:prasanta.sadhukhan at oracle.com>wrote:
>>>
>>>              Hi All,
>>>
>>>              Please review a fix for a memory leak issue where
>>>              PropertyChangeListener
>>>              object added by FileSystemView constructor is never
>> removed.
>>>              Proposed fix is to add dispose() method to be called by
>>>              app when they
>>>
>>>              want to remove this resource.
>>>
>>>              Bug: https://bugs.openjdk.java.net/browse/JDK-8175968
>>>              <https://bugs.openjdk.java.net/browse/JDK-8175968>
>>>              webrev:
>>>             
>> http://cr.openjdk.java.net/~psadhukhan/8175968/webrev.00/
>>>             
>> <http://cr.openjdk.java.net/%7Epsadhukhan/8175968/webrev.00/>
>>>
>>>              Regards
>>>              Prasanta
>>>
>>>
>>>


-- 
Best regards, Sergey.


From alexander.zvegintsev at oracle.com  Mon Sep  4 05:03:42 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 4 Sep 2017 10:33:42 +0530
Subject: <Swing Dev> [10] Review Request: 8186967 Unused methods in
 MotifGraphicsUtils can be removed
In-Reply-To: <a7faf5ac-6ea4-4264-8534-ff118b0e1593@default>
References: <a7faf5ac-6ea4-4264-8534-ff118b0e1593@default>
Message-ID: <424364a1-c36a-39d0-3bb6-8a7630295465@oracle.com>

Looks fine.

Thanks,
Alexander.

On 30/08/2017 12:10, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk10.
>
> The MotifGraphicsUtils is an internal utility class, it have some unused methods.
> These methods were removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8186967
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8186967/webrev.00



From alexander.zvegintsev at oracle.com  Mon Sep  4 05:21:16 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 4 Sep 2017 10:51:16 +0530
Subject: <Swing Dev> [10] RFR JDK-8175968: The
 javax.swing.filechooser.FileSystemView constructor consumes memory by
 adding a PropertyChangeListener that is never removed.
In-Reply-To: <0e3d6cfb-290b-be27-0702-218febd67126@oracle.com>
References: <632a6d41-29ab-4838-b0ee-61fbfd0a7d86@default>
 <0e3d6cfb-290b-be27-0702-218febd67126@oracle.com>
Message-ID: <aafaf351-781c-0926-a6ba-1c07ec26ed43@oracle.com>

Looks fine.

Thanks,
Alexander.

On 03/09/2017 07:01, Sergey Bylokhov wrote:
> Any volunteers to review?
> Thank you =)
>
> On 8/27/17 14:19, Sergey Bylokhov wrote:
>> Hi,
>> I would like to propose a new review as a solution which I think 
>> should solve the problem:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175968
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8175968/webrev.00
>>
>> ----- ldubox-coding101 at yahoo.co.uk wrote:
>>
>>> Hi all,
>>>
>>> ? > but imho it still beats adding an extra method to the API
>>> ? > and shifting the burden to the API user.
>>>
>>> Just a question, would you be an "API user" of this method
>>> directly? It seems to me that dispose() could be called somewhere
>>> knowing more about the lifetime of this object (possibly from
>>> BasicFileChooserUI) so that it remains an implementation
>>> detail to most users of JFileChooser.
>>>
>>> The WeakReference trick would then just be a (poor) fallback
>>> mechanism.
>>>
>>> So this trick (introduced somewhere between Java 6 and 8)
>>> never worked. As mentioned, the key is to ensure the listeneris
>>> a static inner class. For example, this works:
>>>
>>> ????? private PropertyChangeListener pcl;
>>>
>>> ????? public FileSystemView() {
>>> ????????? pcl = createPropertyChangeListener();
>>> ????? }
>>>
>>> ????? private static createPropertyChangeListener() {
>>> ?????????? // current content of constructor goes here
>>> ????? }
>>>
>>> The 'static' is all-important, so that the anonymous listener class
>>> becomes static also, and doesn't have a synthetic reference to
>>> the outer class.
>>>
>>>
>>> ? > Thanks to the weak listener, the FileSystemView will get GC-ed as
>>> ? > the listener no longer keeps a hard reference to it.
>>>
>>> I don't think a Weak Listener helps - the code you referenced earlier
>>> suffers the same limitation as the current code: The reference
>>> isn't freedunless a new property change event comes along. Property
>>> changeevents are very infrequent from UIManager - typically never.
>>>
>>>
>>> I've also been struggling to see a good alternative to dispose().
>>> Finalizers came to mind also but ... (UPDATE: deprecated now huh?
>>> OK forget it then.)
>>>
>>> An alternative could be a timer, but that's a lot of extra baggage.
>>>
>>> IF THIS WERE APPLICATION CODE a trick like this might work,
>>> removing the need for both the listener and dispose():
>>>
>>> ????? private Boolean useSystemExtensionHiding = null;
>>>
>>> ????? private boolean getUseSystemExtensionHiding() {
>>>
>>> ????????? assert SwingUtilities.isEventDispatchThread();
>>>
>>> ????????? if (useSystemExtensionHiding == null) {
>>> ????????????? useSystemExtensionHiding =
>>> UIManager.getDefaults().getBoolean("FileChooser.useSystemExtensionHiding");
>>>
>>> ????????????? SwingUtilities.invokeLater(() -> useSystemExtensionHiding
>>> = null);
>>> ????????? }
>>>
>>> ????????? return useSystemExtensionHiding;
>>> ????? }
>>>
>>> After all, the caching is just an optimisation to avoid repeated
>>> map-lookups during painting (right?) The above reduces it to
>>> once per full component paint, which is a small cost.
>>>
>>> But being library code I'm not sure if it's safe to make such
>>> assumptions (that the EDT event loop is running, for example).
>>> (Expert opinion?)
>>>
>>>
>>> ACTUALLY if avoiding dispose() is preferred - then I wonder if the
>>> optimisation is "past its expiry date"? The "free lunch may be
>>> over" now, but it was still being delivered since Java 1.1 :-)
>>>
>>> What is the cost of one map lookup (per file) compared to the cost
>>> of painting an icon for each file, for example? I'd guess they're
>>> about on-par.
>>>
>>> Would it be so bad to just drop the caching of this boolean
>>> altogether?
>>>
>>> Kind regards,
>>> Luke
>>>
>>>
>>>
>>> On 07/07/2017 09:21, Robin Stevens wrote:
>>>> I still do not think you need a public dispose method.
>>>> If you use the weak listener (the correct implementation), the
>>>> FileSystemView instance can be GC-ed, even when the
>>>> PropertyChangeListener is still attached to the UIManager.
>>>>
>>>> What you can do is:
>>>> - Store a reference to the PropertyChangeListener in the
>>>> FileSystemView class as a field.
>>>> - Override the finalize method of the FileSystemView class to
>>>> de-register the PropertyChangeListener from the UIManager. Thanks to
>>>
>>>> the weak listener, the FileSystemView will get GC-ed as the listener
>>>
>>>> no longer keeps a hard reference to it.
>>>>
>>>> Not the nicest way to do such cleanup (which should probably happen
>>> on
>>>> the EDT) in a finalizer, but imho it still beats adding an extra
>>>> method to the API and shifting the burden to the API user.
>>>>
>>>> Robin
>>>>
>>>> On Thu, Jul 6, 2017 at 3:15 PM, Prasanta Sadhukhan
>>>> <prasanta.sadhukhan at oracle.com
>>>> <mailto:prasanta.sadhukhan at oracle.com>>wrote:
>>>>
>>>> ???? Hi Sergey,
>>>>
>>>> ???? I tried with the proposed WeakPropertyChangeListener but as far
>>> I
>>>> ???? understand & tested, it seems also to rely on propertyChange()
>>> API
>>>> ???? to be called, so the scenario mentioned in the bug will still
>>> fail.
>>>> ???? I cannot find any other way rather than calling dispose() for
>>> the
>>>> ???? scenario mentioned there.
>>>>
>>>> ???? Regards
>>>> ???? Prasanta
>>>>
>>>> ???? On 7/5/2017 4:35 AM, Sergey Bylokhov wrote:
>>>>
>>>> ???????? Hi, Prasanta.
>>>> ???????? Probably it is possible to implement it without users
>>>> ???????? interaction and new api?
>>>>
>>>> ???????? ----- prasanta.sadhukhan at oracle.com
>>>> ???????? <mailto:prasanta.sadhukhan at oracle.com>wrote:
>>>>
>>>> ???????????? Hi All,
>>>>
>>>> ???????????? Please review a fix for a memory leak issue where
>>>> ???????????? PropertyChangeListener
>>>> ???????????? object added by FileSystemView constructor is never
>>> removed.
>>>> ???????????? Proposed fix is to add dispose() method to be called by
>>>> ???????????? app when they
>>>>
>>>> ???????????? want to remove this resource.
>>>>
>>>> ???????????? Bug: https://bugs.openjdk.java.net/browse/JDK-8175968
>>>> <https://bugs.openjdk.java.net/browse/JDK-8175968>
>>>> ???????????? webrev:
>>> http://cr.openjdk.java.net/~psadhukhan/8175968/webrev.00/
>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8175968/webrev.00/>
>>>>
>>>> ???????????? Regards
>>>> ???????????? Prasanta
>>>>
>>>>
>>>>
>
>



From shashidhara.veerabhadraiah at oracle.com  Mon Sep  4 09:33:41 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 4 Sep 2017 02:33:41 -0700 (PDT)
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
Message-ID: <c843a091-d96a-46a8-b528-0fd37b8045f7@default>

Hi All, Please find the updated Webrev at the below link.

 

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

 

I have added a new test that would go through different laf's and runs the test of the tab titles. Previously this test had been a single default laf test with appletviewer and now replaced for multi laf testing along with the normal java execution. There are instances of inaccurate rendering of the titles with respect to the tab pane component like clipping, starting offset and going beyond the tab pane size as shown below in some of the examples:

 



 

This requires a different thread to really understand why this variation across the multiple laf representation and needs more proper bounding the title to fit properly within the tab pane space. Hence I will be raising multiple bugs to indicate these current issues and will be resolved later. Please note that this issue is not because of the clipping of the text that these current changes that are done under this bug fix.

 

Thanks and regards,

Shashi

 

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, August 24, 2017 4:24 AM
To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.

 

I am not sure is it possible to prove, but I think that we need to pass tabPane as a component to ClipStrinUfNecessary.

 

On 17.08.2017 3:48, Prasanta Sadhukhan wrote:

> Fix looks good.

> 

> But, can you update 

> test/javax/swing/JTabbedPane/4310381/bug4310381.java

> to include the test for all installed l&fs so that we can see if there 

> is problem in any other l&fs?

> 

> Regards

> Prasanta

> On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah wrote:

>> 

>> Hi All, Please review a fix for the JDK- 8004029 where the long tab 

>> titles were not clipped with the dots at the end to indicate a 

>> lengthy title. The aqua look and feel which is the default laf for 

>> mac does the title clipping only leading to an ambiguous UI where in 

>> the clipped title would look like the /_complete_/ title though it is not.

>> Hence it is good to show dots at the end indicating a much bigger 

>> title exists though the tab does not have enough real estate to 

>> display the complete title.

>> 

>> _Solution and fix:_ I have updated the aqua laf module to clip the 

>> title text and put the dots at the end if the text size is larger 

>> than the tab size. Below is the picture /_after_/ the fix.

>> 

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

>> 

>> Webrev: 

>> http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/

>> <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>

>> 

>> Thanks and regards,

>> 

>> Shashi

>> 

> 

 

 

--

Best regards, Sergey.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170904/86c71ed8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 7912 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170904/86c71ed8/image002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 7429 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170904/86c71ed8/image006.jpg>

From krishna.addepalli at oracle.com  Mon Sep  4 10:16:33 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 4 Sep 2017 03:16:33 -0700 (PDT)
Subject: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize()
 returns a width of 0
In-Reply-To: <29aa476c-ad54-f98c-7048-015815cf602a@oracle.com>
References: <3d254bda-e09a-4dd4-801f-0b8f4d160eb3@default>
 <29aa476c-ad54-f98c-7048-015815cf602a@oracle.com>
Message-ID: <95dff71a-d730-402e-b5ed-bbd37ec64003@default>

Hi Prasanta,

 

Thanks for bringing that up. I have updated the webrev with the test case. 

 

JDK 10 Webrev: http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev.01/

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Thursday, August 24, 2017 1:50 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize() returns a width of 0

 

You can add a regression test with the fix as JBS already has one.

Regards
Prasanta

On 8/24/2017 12:37 PM, Krishna Addepalli wrote:

Hi All, 

 

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

JDK 10 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev00/"http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev00/

 

The issue is that when a text label is added to JRootPane and query the maximumLayoutSize, it is returning 0. The root cause is because, JRootPane decides to provide the Minimum width of Menubar (which in this case is 0) and the content pane (which contains the JLabel). Actually, it should return the maximum of the two, since that is what is the layout size needed.

 

Thanks,

Krishna

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

From prasanta.sadhukhan at oracle.com  Mon Sep  4 12:14:57 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 4 Sep 2017 17:44:57 +0530
Subject: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize()
 returns a width of 0
In-Reply-To: <95dff71a-d730-402e-b5ed-bbd37ec64003@default>
References: <3d254bda-e09a-4dd4-801f-0b8f4d160eb3@default>
 <29aa476c-ad54-f98c-7048-015815cf602a@oracle.com>
 <95dff71a-d730-402e-b5ed-bbd37ec64003@default>
Message-ID: <6660d6cf-171a-5320-4cf7-76c366ff1a62@oracle.com>

Looks fine. But, remove @author tag as we do not use it anymore. Also, 
@modules tag is used to add some internal modules if test needs one, 
here it is not needed, so you remove that too. Add @run tag.

Regards
Prasanta
On 9/4/2017 3:46 PM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> Thanks for bringing that up. I have updated the webrev with the test 
> case.
>
> JDK 10 Webrev: 
> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev.01/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev.01/>
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Thursday, August 24, 2017 1:50 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-6714836] 
> JRootPane.getMaximumSize() returns a width of 0
>
> You can add a regression test with the fix as JBS already has one.
>
> Regards
> Prasanta
>
> On 8/24/2017 12:37 PM, Krishna Addepalli wrote:
>
>     Hi All,
>
>     Bug : JDK- 6714836
>     <https://bugs.openjdk.java.net/browse/JDK-6714836>
>     <%3chttps:/bugs.openjdk.java.net/browse/JDK-6714836%3e>
>
>     JDK 10 Webrev:
>     http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev00/
>     <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev00/>
>
>     The issue is that when a text label is added to JRootPane and
>     query the maximumLayoutSize, it is returning 0. The root cause is
>     because, JRootPane decides to provide the Minimum width of Menubar
>     (which in this case is 0) and the content pane (which contains the
>     JLabel). Actually, it should return the maximum of the two, since
>     that is what is the layout size needed.
>
>     Thanks,
>
>     Krishna
>

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

From krishna.addepalli at oracle.com  Tue Sep  5 09:56:49 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 5 Sep 2017 02:56:49 -0700 (PDT)
Subject: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize()
 returns a width of 0
In-Reply-To: <6660d6cf-171a-5320-4cf7-76c366ff1a62@oracle.com>
References: <3d254bda-e09a-4dd4-801f-0b8f4d160eb3@default>
 <29aa476c-ad54-f98c-7048-015815cf602a@oracle.com>
 <95dff71a-d730-402e-b5ed-bbd37ec64003@default>
 <6660d6cf-171a-5320-4cf7-76c366ff1a62@oracle.com>
Message-ID: <c0b9e1af-6943-4f12-bc2b-64f7ece05dca@default>

Done that!

 

http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev02/  is the updated webrev.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, September 4, 2017 5:45 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize() returns a width of 0

 

Looks fine. But, remove @author tag as we do not use it anymore. Also, @modules tag is used to add some internal modules if test needs one, here it is not needed, so you remove that too. Add @run tag.

Regards
Prasanta

On 9/4/2017 3:46 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for bringing that up. I have updated the webrev with the test case. 

 

JDK 10 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev.01/

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Thursday, August 24, 2017 1:50 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize() returns a width of 0

 

You can add a regression test with the fix as JBS already has one.

Regards
Prasanta

On 8/24/2017 12:37 PM, Krishna Addepalli wrote:

Hi All, 

 

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

JDK 10 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev00/"http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev00/

 

The issue is that when a text label is added to JRootPane and query the maximumLayoutSize, it is returning 0. The root cause is because, JRootPane decides to provide the Minimum width of Menubar (which in this case is 0) and the content pane (which contains the JLabel). Actually, it should return the maximum of the two, since that is what is the layout size needed.

 

Thanks,

Krishna

 

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

From prasanta.sadhukhan at oracle.com  Tue Sep  5 10:26:38 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 5 Sep 2017 15:56:38 +0530
Subject: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize()
 returns a width of 0
In-Reply-To: <c0b9e1af-6943-4f12-bc2b-64f7ece05dca@default>
References: <3d254bda-e09a-4dd4-801f-0b8f4d160eb3@default>
 <29aa476c-ad54-f98c-7048-015815cf602a@oracle.com>
 <95dff71a-d730-402e-b5ed-bbd37ec64003@default>
 <6660d6cf-171a-5320-4cf7-76c366ff1a62@oracle.com>
 <c0b9e1af-6943-4f12-bc2b-64f7ece05dca@default>
Message-ID: <b855f641-505f-2aaf-36b6-240f15dd1670@oracle.com>

+1. Just one thing, you can modify the testcase to use specific imports 
rather that wildcard imports.

Regards
Prasanta
On 9/5/2017 3:26 PM, Krishna Addepalli wrote:
>
> Done that!
>
> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev02/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev02/>? is 
> the updated webrev.
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Monday, September 4, 2017 5:45 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-6714836] 
> JRootPane.getMaximumSize() returns a width of 0
>
> Looks fine. But, remove @author tag as we do not use it anymore. Also, 
> @modules tag is used to add some internal modules if test needs one, 
> here it is not needed, so you remove that too. Add @run tag.
>
> Regards
> Prasanta
>
> On 9/4/2017 3:46 PM, Krishna Addepalli wrote:
>
>     Hi Prasanta,
>
>     Thanks for bringing that up. I have updated the webrev with the
>     test case.
>
>     JDK 10 Webrev:
>     http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev.01/
>     <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev.01/>
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Thursday, August 24, 2017 1:50 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][JDK-6714836]
>     JRootPane.getMaximumSize() returns a width of 0
>
>     You can add a regression test with the fix as JBS already has one.
>
>     Regards
>     Prasanta
>
>     On 8/24/2017 12:37 PM, Krishna Addepalli wrote:
>
>         Hi All,
>
>         Bug : JDK- 6714836
>         <https://bugs.openjdk.java.net/browse/JDK-6714836>
>         <%3chttps:/bugs.openjdk.java.net/browse/JDK-6714836%3e>
>
>         JDK 10 Webrev:
>         http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev00/
>         <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev00/>
>
>         The issue is that when a text label is added to JRootPane and
>         query the maximumLayoutSize, it is returning 0. The root cause
>         is because, JRootPane decides to provide the Minimum width of
>         Menubar (which in this case is 0) and the content pane (which
>         contains the JLabel). Actually, it should return the maximum
>         of the two, since that is what is the layout size needed.
>
>         Thanks,
>
>         Krishna
>

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

From Sergey.Bylokhov at oracle.com  Tue Sep  5 14:33:32 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Sep 2017 07:33:32 -0700
Subject: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize()
 returns a width of 0
In-Reply-To: <b855f641-505f-2aaf-36b6-240f15dd1670@oracle.com>
References: <3d254bda-e09a-4dd4-801f-0b8f4d160eb3@default>
 <29aa476c-ad54-f98c-7048-015815cf602a@oracle.com>
 <95dff71a-d730-402e-b5ed-bbd37ec64003@default>
 <6660d6cf-171a-5320-4cf7-76c366ff1a62@oracle.com>
 <c0b9e1af-6943-4f12-bc2b-64f7ece05dca@default>
 <b855f641-505f-2aaf-36b6-240f15dd1670@oracle.com>
Message-ID: <7f201ea1-86a7-4204-48eb-8732e399446c@oracle.com>

One more note: the Swing components should be accessed on EDT.

On 9/5/17 03:26, Prasanta Sadhukhan wrote:
> +1. Just one thing, you can modify the testcase to use specific imports 
> rather that wildcard imports.
> 
> Regards
> Prasanta
> On 9/5/2017 3:26 PM, Krishna Addepalli wrote:
>>
>> Done that!
>>
>> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev02/ 
>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev02/>? is 
>> the updated webrev.
>>
>> Thanks,
>>
>> Krishna
>>
>> *From:*Prasanta Sadhukhan
>> *Sent:* Monday, September 4, 2017 5:45 PM
>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> swing-dev at openjdk.java.net
>> *Subject:* Re: <Swing Dev> [10][JDK-6714836] 
>> JRootPane.getMaximumSize() returns a width of 0
>>
>> Looks fine. But, remove @author tag as we do not use it anymore. Also, 
>> @modules tag is used to add some internal modules if test needs one, 
>> here it is not needed, so you remove that too. Add @run tag.
>>
>> Regards
>> Prasanta
>>
>> On 9/4/2017 3:46 PM, Krishna Addepalli wrote:
>>
>>     Hi Prasanta,
>>
>>     Thanks for bringing that up. I have updated the webrev with the
>>     test case.
>>
>>     JDK 10 Webrev:
>>     http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev.01/
>>     <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev.01/>
>>
>>     Krishna
>>
>>     *From:*Prasanta Sadhukhan
>>     *Sent:* Thursday, August 24, 2017 1:50 PM
>>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>>     <mailto:swing-dev at openjdk.java.net>
>>     *Subject:* Re: <Swing Dev> [10][JDK-6714836]
>>     JRootPane.getMaximumSize() returns a width of 0
>>
>>     You can add a regression test with the fix as JBS already has one.
>>
>>     Regards
>>     Prasanta
>>
>>     On 8/24/2017 12:37 PM, Krishna Addepalli wrote:
>>
>>         Hi All,
>>
>>         Bug : JDK- 6714836
>>         <https://bugs.openjdk.java.net/browse/JDK-6714836>
>>         <%3chttps:/bugs.openjdk.java.net/browse/JDK-6714836%3e>
>>
>>         JDK 10 Webrev:
>>         http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev00/
>>         <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev00/>
>>
>>         The issue is that when a text label is added to JRootPane and
>>         query the maximumLayoutSize, it is returning 0. The root cause
>>         is because, JRootPane decides to provide the Minimum width of
>>         Menubar (which in this case is 0) and the content pane (which
>>         contains the JLabel). Actually, it should return the maximum
>>         of the two, since that is what is the layout size needed.
>>
>>         Thanks,
>>
>>         Krishna
>>
> 


-- 
Best regards, Sergey.


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: <Swing 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/swing-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: <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  Sat Sep  9 02:03:18 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 8 Sep 2017 19:03:18 -0700
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
Message-ID: <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>

Hi, Shashi.
The fix looks fine, but it looks like bug4310381.html should be removed 
because it is not used?

On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote:
> Hi All, Please find the updated Webrev at the below link.
> 
> http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.01/
> 
> I have added a new test that would go through different laf's and runs 
> the test of the tab titles. Previously this test had been a single 
> default laf test with appletviewer and now replaced for multi laf 
> testing along with the normal java execution. There are instances of 
> inaccurate rendering of the titles with respect to the tab pane 
> component like clipping, starting offset and going beyond the tab pane 
> size as shown below in some of the examples:
> 
> This requires a different thread to really understand why this variation 
> across the multiple laf representation and needs more proper bounding 
> the title to fit properly within the tab pane space. Hence I will be 
> raising multiple bugs to indicate these current issues and will be 
> resolved later. Please note that this issue is /_not_/ because of the 
> clipping of the text that these current changes that are done under this 
> bug fix.
> 
> Thanks and regards,
> 
> Shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Thursday, August 24, 2017 4:24 AM
> To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Shashidhara 
> Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; 
> swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles 
> are not clipped with dots at the end.
> 
> I am not sure is it possible to prove, but I think that we need to pass 
> tabPane as a component to ClipStrinUfNecessary.
> 
> On 17.08.2017 3:48, Prasanta Sadhukhan wrote:
> 
>  > Fix looks good.
> 
>  >
> 
>  > But, can you update
> 
>  > test/javax/swing/JTabbedPane/4310381/bug4310381.java
> 
>  > to include the test for all installed l&fs so that we can see if there
> 
>  > is problem in any other l&fs?
> 
>  >
> 
>  > Regards
> 
>  > Prasanta
> 
>  > On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah wrote:
> 
>  >>
> 
>  >> Hi All, Please review a fix for the JDK- 8004029 where the long tab
> 
>  >> titles were not clipped with the dots at the end to indicate a
> 
>  >> lengthy title. The aqua look and feel which is the default laf for
> 
>  >> mac does the title clipping only leading to an ambiguous UI where in
> 
>  >> the clipped title would look like the /_complete_/ title though it 
> is not.
> 
>  >> Hence it is good to show dots at the end indicating a much bigger
> 
>  >> title exists though the tab does not have enough real estate to
> 
>  >> display the complete title.
> 
>  >>
> 
>  >> _Solution and fix:_ I have updated the aqua laf module to clip the
> 
>  >> title text and put the dots at the end if the text size is larger
> 
>  >> than the tab size. Below is the picture /_after_/ the fix.
> 
>  >>
> 
>  >> Bug: https://bugs.openjdk.java.net/browse/JDK-8004029
> 
>  >>
> 
>  >> Webrev:
> 
>  >> http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/
> 
>  >> <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>
> 
>  >>
> 
>  >> Thanks and regards,
> 
>  >>
> 
>  >> Shashi
> 
>  >>
> 
>  >
> 
> --
> 
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.


From shashidhara.veerabhadraiah at oracle.com  Mon Sep 11 04:06:54 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 11 Sep 2017 04:06:54 +0000 (UTC)
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
 <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
Message-ID: <82ac9212-d59e-4368-ad4e-89d210bbb204@default>

Right Sergey. I was not sure on how to represent it under this Webrev. I will update the Webrev if need be.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, September 9, 2017 7:33 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.

Hi, Shashi.
The fix looks fine, but it looks like bug4310381.html should be removed because it is not used?

On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote:
> Hi All, Please find the updated Webrev at the below link.
> 
> http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.01/
> 
> I have added a new test that would go through different laf's and runs 
> the test of the tab titles. Previously this test had been a single 
> default laf test with appletviewer and now replaced for multi laf 
> testing along with the normal java execution. There are instances of 
> inaccurate rendering of the titles with respect to the tab pane 
> component like clipping, starting offset and going beyond the tab pane 
> size as shown below in some of the examples:
> 
> This requires a different thread to really understand why this 
> variation across the multiple laf representation and needs more proper 
> bounding the title to fit properly within the tab pane space. Hence I 
> will be raising multiple bugs to indicate these current issues and 
> will be resolved later. Please note that this issue is /_not_/ because 
> of the clipping of the text that these current changes that are done 
> under this bug fix.
> 
> Thanks and regards,
> 
> Shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Thursday, August 24, 2017 4:24 AM
> To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Shashidhara 
> Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>;
> swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab 
> titles are not clipped with dots at the end.
> 
> I am not sure is it possible to prove, but I think that we need to 
> pass tabPane as a component to ClipStrinUfNecessary.
> 
> On 17.08.2017 3:48, Prasanta Sadhukhan wrote:
> 
>  > Fix looks good.
> 
>  >
> 
>  > But, can you update
> 
>  > test/javax/swing/JTabbedPane/4310381/bug4310381.java
> 
>  > to include the test for all installed l&fs so that we can see if 
> there
> 
>  > is problem in any other l&fs?
> 
>  >
> 
>  > Regards
> 
>  > Prasanta
> 
>  > On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah wrote:
> 
>  >>
> 
>  >> Hi All, Please review a fix for the JDK- 8004029 where the long 
> tab
> 
>  >> titles were not clipped with the dots at the end to indicate a
> 
>  >> lengthy title. The aqua look and feel which is the default laf for
> 
>  >> mac does the title clipping only leading to an ambiguous UI where 
> in
> 
>  >> the clipped title would look like the /_complete_/ title though it 
> is not.
> 
>  >> Hence it is good to show dots at the end indicating a much bigger
> 
>  >> title exists though the tab does not have enough real estate to
> 
>  >> display the complete title.
> 
>  >>
> 
>  >> _Solution and fix:_ I have updated the aqua laf module to clip the
> 
>  >> title text and put the dots at the end if the text size is larger
> 
>  >> than the tab size. Below is the picture /_after_/ the fix.
> 
>  >>
> 
>  >> Bug: https://bugs.openjdk.java.net/browse/JDK-8004029
> 
>  >>
> 
>  >> Webrev:
> 
>  >> http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/
> 
>  >> <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>
> 
>  >>
> 
>  >> Thanks and regards,
> 
>  >>
> 
>  >> Shashi
> 
>  >>
> 
>  >
> 
> --
> 
> Best regards, Sergey.
> 


--
Best regards, Sergey.


From krishna.addepalli at oracle.com  Mon Sep 11 05:03:44 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 11 Sep 2017 05:03:44 +0000 (UTC)
Subject: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize()
 returns a width of 0
In-Reply-To: <7f201ea1-86a7-4204-48eb-8732e399446c@oracle.com>
References: <3d254bda-e09a-4dd4-801f-0b8f4d160eb3@default>
 <29aa476c-ad54-f98c-7048-015815cf602a@oracle.com>
 <95dff71a-d730-402e-b5ed-bbd37ec64003@default>
 <6660d6cf-171a-5320-4cf7-76c366ff1a62@oracle.com>
 <c0b9e1af-6943-4f12-bc2b-64f7ece05dca@default>
 <b855f641-505f-2aaf-36b6-240f15dd1670@oracle.com>
 <7f201ea1-86a7-4204-48eb-8732e399446c@oracle.com>
Message-ID: <24469b72-0680-4687-9eb7-da0978adf374@default>

Hi Prasanta/Sergey,

I have updated the webrev based on your recommendations:

http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev03/

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, September 5, 2017 8:04 PM
To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize() returns a width of 0

One more note: the Swing components should be accessed on EDT.

On 9/5/17 03:26, Prasanta Sadhukhan wrote:
> +1. Just one thing, you can modify the testcase to use specific 
> +imports
> rather that wildcard imports.
> 
> Regards
> Prasanta
> On 9/5/2017 3:26 PM, Krishna Addepalli wrote:
>>
>> Done that!
>>
>> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev02/
>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev02/>? 
>> is the updated webrev.
>>
>> Thanks,
>>
>> Krishna
>>
>> *From:*Prasanta Sadhukhan
>> *Sent:* Monday, September 4, 2017 5:45 PM
>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> swing-dev at openjdk.java.net
>> *Subject:* Re: <Swing Dev> [10][JDK-6714836]
>> JRootPane.getMaximumSize() returns a width of 0
>>
>> Looks fine. But, remove @author tag as we do not use it anymore. 
>> Also, @modules tag is used to add some internal modules if test needs 
>> one, here it is not needed, so you remove that too. Add @run tag.
>>
>> Regards
>> Prasanta
>>
>> On 9/4/2017 3:46 PM, Krishna Addepalli wrote:
>>
>>     Hi Prasanta,
>>
>>     Thanks for bringing that up. I have updated the webrev with the
>>     test case.
>>
>>     JDK 10 Webrev:
>>     http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev.01/
>>     
>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev.01/>
>>
>>     Krishna
>>
>>     *From:*Prasanta Sadhukhan
>>     *Sent:* Thursday, August 24, 2017 1:50 PM
>>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>>     <mailto:swing-dev at openjdk.java.net>
>>     *Subject:* Re: <Swing Dev> [10][JDK-6714836]
>>     JRootPane.getMaximumSize() returns a width of 0
>>
>>     You can add a regression test with the fix as JBS already has one.
>>
>>     Regards
>>     Prasanta
>>
>>     On 8/24/2017 12:37 PM, Krishna Addepalli wrote:
>>
>>         Hi All,
>>
>>         Bug : JDK- 6714836
>>         <https://bugs.openjdk.java.net/browse/JDK-6714836>
>>         <%3chttps:/bugs.openjdk.java.net/browse/JDK-6714836%3e>
>>
>>         JDK 10 Webrev:
>>         http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev00/
>>         
>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev00/>
>>
>>         The issue is that when a text label is added to JRootPane and
>>         query the maximumLayoutSize, it is returning 0. The root cause
>>         is because, JRootPane decides to provide the Minimum width of
>>         Menubar (which in this case is 0) and the content pane (which
>>         contains the JLabel). Actually, it should return the maximum
>>         of the two, since that is what is the layout size needed.
>>
>>         Thanks,
>>
>>         Krishna
>>
> 


--
Best regards, Sergey.


From shashidhara.veerabhadraiah at oracle.com  Mon Sep 11 08:34:45 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 11 Sep 2017 08:34:45 +0000 (UTC)
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <82ac9212-d59e-4368-ad4e-89d210bbb204@default>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
 <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
 <82ac9212-d59e-4368-ad4e-89d210bbb204@default>
Message-ID: <fae37d24-4d62-49c4-b0dd-fcc1df18e64f@default>

Hi, I have updated the webrev to indicate the removal of a file which is not required anymore owing to the change in test from appletviewer based to standard java execution. This is only for the reference.

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

Thanks and regards,
Shashi

-----Original Message-----
From: Shashidhara Veerabhadraiah 
Sent: Monday, September 11, 2017 9:37 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.

Right Sergey. I was not sure on how to represent it under this Webrev. I will update the Webrev if need be.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov
Sent: Saturday, September 9, 2017 7:33 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.

Hi, Shashi.
The fix looks fine, but it looks like bug4310381.html should be removed because it is not used?

On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote:
> Hi All, Please find the updated Webrev at the below link.
> 
> http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.01/
> 
> I have added a new test that would go through different laf's and runs 
> the test of the tab titles. Previously this test had been a single 
> default laf test with appletviewer and now replaced for multi laf 
> testing along with the normal java execution. There are instances of 
> inaccurate rendering of the titles with respect to the tab pane 
> component like clipping, starting offset and going beyond the tab pane 
> size as shown below in some of the examples:
> 
> This requires a different thread to really understand why this 
> variation across the multiple laf representation and needs more proper 
> bounding the title to fit properly within the tab pane space. Hence I 
> will be raising multiple bugs to indicate these current issues and 
> will be resolved later. Please note that this issue is /_not_/ because 
> of the clipping of the text that these current changes that are done 
> under this bug fix.
> 
> Thanks and regards,
> 
> Shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Thursday, August 24, 2017 4:24 AM
> To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Shashidhara 
> Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>;
> swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab 
> titles are not clipped with dots at the end.
> 
> I am not sure is it possible to prove, but I think that we need to 
> pass tabPane as a component to ClipStrinUfNecessary.
> 
> On 17.08.2017 3:48, Prasanta Sadhukhan wrote:
> 
>  > Fix looks good.
> 
>  >
> 
>  > But, can you update
> 
>  > test/javax/swing/JTabbedPane/4310381/bug4310381.java
> 
>  > to include the test for all installed l&fs so that we can see if 
> there
> 
>  > is problem in any other l&fs?
> 
>  >
> 
>  > Regards
> 
>  > Prasanta
> 
>  > On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah wrote:
> 
>  >>
> 
>  >> Hi All, Please review a fix for the JDK- 8004029 where the long 
> tab
> 
>  >> titles were not clipped with the dots at the end to indicate a
> 
>  >> lengthy title. The aqua look and feel which is the default laf for
> 
>  >> mac does the title clipping only leading to an ambiguous UI where 
> in
> 
>  >> the clipped title would look like the /_complete_/ title though it 
> is not.
> 
>  >> Hence it is good to show dots at the end indicating a much bigger
> 
>  >> title exists though the tab does not have enough real estate to
> 
>  >> display the complete title.
> 
>  >>
> 
>  >> _Solution and fix:_ I have updated the aqua laf module to clip the
> 
>  >> title text and put the dots at the end if the text size is larger
> 
>  >> than the tab size. Below is the picture /_after_/ the fix.
> 
>  >>
> 
>  >> Bug: https://bugs.openjdk.java.net/browse/JDK-8004029
> 
>  >>
> 
>  >> Webrev:
> 
>  >> http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/
> 
>  >> <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>
> 
>  >>
> 
>  >> Thanks and regards,
> 
>  >>
> 
>  >> Shashi
> 
>  >>
> 
>  >
> 
> --
> 
> Best regards, Sergey.
> 


--
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Sep 11 19:24:07 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 11 Sep 2017 12:24:07 -0700
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <fae37d24-4d62-49c4-b0dd-fcc1df18e64f@default>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
 <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
 <82ac9212-d59e-4368-ad4e-89d210bbb204@default>
 <fae37d24-4d62-49c4-b0dd-fcc1df18e64f@default>
Message-ID: <2cb8f671-4a48-827c-504d-62ba4d9ff7f5@oracle.com>

Looks fine.

On 9/11/17 01:34, Shashidhara Veerabhadraiah wrote:
> Hi, I have updated the webrev to indicate the removal of a file which is not required anymore owing to the change in test from appletviewer based to standard java execution. This is only for the reference.
> 
> http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.02/
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Shashidhara Veerabhadraiah
> Sent: Monday, September 11, 2017 9:37 AM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.
> 
> Right Sergey. I was not sure on how to represent it under this Webrev. I will update the Webrev if need be.
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, September 9, 2017 7:33 AM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.
> 
> Hi, Shashi.
> The fix looks fine, but it looks like bug4310381.html should be removed because it is not used?
> 
> On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please find the updated Webrev at the below link.
>>
>> http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.01/
>>
>> I have added a new test that would go through different laf's and runs
>> the test of the tab titles. Previously this test had been a single
>> default laf test with appletviewer and now replaced for multi laf
>> testing along with the normal java execution. There are instances of
>> inaccurate rendering of the titles with respect to the tab pane
>> component like clipping, starting offset and going beyond the tab pane
>> size as shown below in some of the examples:
>>
>> This requires a different thread to really understand why this
>> variation across the multiple laf representation and needs more proper
>> bounding the title to fit properly within the tab pane space. Hence I
>> will be raising multiple bugs to indicate these current issues and
>> will be resolved later. Please note that this issue is /_not_/ because
>> of the clipping of the text that these current changes that are done
>> under this bug fix.
>>
>> Thanks and regards,
>>
>> Shashi
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Thursday, August 24, 2017 4:24 AM
>> To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Shashidhara
>> Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>;
>> swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab
>> titles are not clipped with dots at the end.
>>
>> I am not sure is it possible to prove, but I think that we need to
>> pass tabPane as a component to ClipStrinUfNecessary.
>>
>> On 17.08.2017 3:48, Prasanta Sadhukhan wrote:
>>
>>   > Fix looks good.
>>
>>   >
>>
>>   > But, can you update
>>
>>   > test/javax/swing/JTabbedPane/4310381/bug4310381.java
>>
>>   > to include the test for all installed l&fs so that we can see if
>> there
>>
>>   > is problem in any other l&fs?
>>
>>   >
>>
>>   > Regards
>>
>>   > Prasanta
>>
>>   > On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah wrote:
>>
>>   >>
>>
>>   >> Hi All, Please review a fix for the JDK- 8004029 where the long
>> tab
>>
>>   >> titles were not clipped with the dots at the end to indicate a
>>
>>   >> lengthy title. The aqua look and feel which is the default laf for
>>
>>   >> mac does the title clipping only leading to an ambiguous UI where
>> in
>>
>>   >> the clipped title would look like the /_complete_/ title though it
>> is not.
>>
>>   >> Hence it is good to show dots at the end indicating a much bigger
>>
>>   >> title exists though the tab does not have enough real estate to
>>
>>   >> display the complete title.
>>
>>   >>
>>
>>   >> _Solution and fix:_ I have updated the aqua laf module to clip the
>>
>>   >> title text and put the dots at the end if the text size is larger
>>
>>   >> than the tab size. Below is the picture /_after_/ the fix.
>>
>>   >>
>>
>>   >> Bug: https://bugs.openjdk.java.net/browse/JDK-8004029
>>
>>   >>
>>
>>   >> Webrev:
>>
>>   >> http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/
>>
>>   >> <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>
>>
>>   >>
>>
>>   >> Thanks and regards,
>>
>>   >>
>>
>>   >> Shashi
>>
>>   >>
>>
>>   >
>>
>> --
>>
>> Best regards, Sergey.
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Sep 11 19:32:38 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 11 Sep 2017 12:32:38 -0700
Subject: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize()
 returns a width of 0
In-Reply-To: <24469b72-0680-4687-9eb7-da0978adf374@default>
References: <3d254bda-e09a-4dd4-801f-0b8f4d160eb3@default>
 <29aa476c-ad54-f98c-7048-015815cf602a@oracle.com>
 <95dff71a-d730-402e-b5ed-bbd37ec64003@default>
 <6660d6cf-171a-5320-4cf7-76c366ff1a62@oracle.com>
 <c0b9e1af-6943-4f12-bc2b-64f7ece05dca@default>
 <b855f641-505f-2aaf-36b6-240f15dd1670@oracle.com>
 <7f201ea1-86a7-4204-48eb-8732e399446c@oracle.com>
 <24469b72-0680-4687-9eb7-da0978adf374@default>
Message-ID: <382ced26-55e1-6687-dc82-4ea447ca80b2@oracle.com>

Hi, Krishna
Please use SwingUtilities.invokeAndWait() instead of invokeLater().
  - invokeAndWait() will wait while code is executed.
  - invokeLater() can start execution when the main() method is ended, 
so the jtreg will kill EDT before the test will do something useful.

On 9/10/17 22:03, Krishna Addepalli wrote:
> Hi Prasanta/Sergey,
> 
> I have updated the webrev based on your recommendations:
> 
> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev03/
> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 5, 2017 8:04 PM
> To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize() returns a width of 0
> 
> One more note: the Swing components should be accessed on EDT.
> 
> On 9/5/17 03:26, Prasanta Sadhukhan wrote:
>> +1. Just one thing, you can modify the testcase to use specific
>> +imports
>> rather that wildcard imports.
>>
>> Regards
>> Prasanta
>> On 9/5/2017 3:26 PM, Krishna Addepalli wrote:
>>>
>>> Done that!
>>>
>>> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev02/
>>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev02/>
>>> is the updated webrev.
>>>
>>> Thanks,
>>>
>>> Krishna
>>>
>>> *From:*Prasanta Sadhukhan
>>> *Sent:* Monday, September 4, 2017 5:45 PM
>>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>;
>>> swing-dev at openjdk.java.net
>>> *Subject:* Re: <Swing Dev> [10][JDK-6714836]
>>> JRootPane.getMaximumSize() returns a width of 0
>>>
>>> Looks fine. But, remove @author tag as we do not use it anymore.
>>> Also, @modules tag is used to add some internal modules if test needs
>>> one, here it is not needed, so you remove that too. Add @run tag.
>>>
>>> Regards
>>> Prasanta
>>>
>>> On 9/4/2017 3:46 PM, Krishna Addepalli wrote:
>>>
>>>      Hi Prasanta,
>>>
>>>      Thanks for bringing that up. I have updated the webrev with the
>>>      test case.
>>>
>>>      JDK 10 Webrev:
>>>      http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev.01/
>>>      
>>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev.01/>
>>>
>>>      Krishna
>>>
>>>      *From:*Prasanta Sadhukhan
>>>      *Sent:* Thursday, August 24, 2017 1:50 PM
>>>      *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>>      <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>>>      <mailto:swing-dev at openjdk.java.net>
>>>      *Subject:* Re: <Swing Dev> [10][JDK-6714836]
>>>      JRootPane.getMaximumSize() returns a width of 0
>>>
>>>      You can add a regression test with the fix as JBS already has one.
>>>
>>>      Regards
>>>      Prasanta
>>>
>>>      On 8/24/2017 12:37 PM, Krishna Addepalli wrote:
>>>
>>>          Hi All,
>>>
>>>          Bug : JDK- 6714836
>>>          <https://bugs.openjdk.java.net/browse/JDK-6714836>
>>>          <%3chttps:/bugs.openjdk.java.net/browse/JDK-6714836%3e>
>>>
>>>          JDK 10 Webrev:
>>>          http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev00/
>>>          
>>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev00/>
>>>
>>>          The issue is that when a text label is added to JRootPane and
>>>          query the maximumLayoutSize, it is returning 0. The root cause
>>>          is because, JRootPane decides to provide the Minimum width of
>>>          Menubar (which in this case is 0) and the content pane (which
>>>          contains the JLabel). Actually, it should return the maximum
>>>          of the two, since that is what is the layout size needed.
>>>
>>>          Thanks,
>>>
>>>          Krishna
>>>
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Tue Sep 12 06:15:14 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 12 Sep 2017 11:45:14 +0530
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <2cb8f671-4a48-827c-504d-62ba4d9ff7f5@oracle.com>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
 <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
 <82ac9212-d59e-4368-ad4e-89d210bbb204@default>
 <fae37d24-4d62-49c4-b0dd-fcc1df18e64f@default>
 <2cb8f671-4a48-827c-504d-62ba4d9ff7f5@oracle.com>
Message-ID: <4fd8f3e1-1a16-95bb-c68e-d572bf85a087@oracle.com>

Few observations on test:

init() needs to be called under EDT
you are calling disposeUI() in line 233, so it seems there is no need 
calling again in line122

Regards
Prasanta
On 9/12/2017 12:54 AM, Sergey Bylokhov wrote:
> Looks fine.
>
> On 9/11/17 01:34, Shashidhara Veerabhadraiah wrote:
>> Hi, I have updated the webrev to indicate the removal of a file which 
>> is not required anymore owing to the change in test from appletviewer 
>> based to standard java execution. This is only for the reference.
>>
>> http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.02/
>>
>> Thanks and regards,
>> Shashi
>>
>> -----Original Message-----
>> From: Shashidhara Veerabhadraiah
>> Sent: Monday, September 11, 2017 9:37 AM
>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Prasanta Sadhukhan 
>> <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab 
>> titles are not clipped with dots at the end.
>>
>> Right Sergey. I was not sure on how to represent it under this 
>> Webrev. I will update the Webrev if need be.
>>
>> Thanks and regards,
>> Shashi
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Saturday, September 9, 2017 7:33 AM
>> To: Shashidhara Veerabhadraiah 
>> <shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan 
>> <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab 
>> titles are not clipped with dots at the end.
>>
>> Hi, Shashi.
>> The fix looks fine, but it looks like bug4310381.html should be 
>> removed because it is not used?
>>
>> On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote:
>>> Hi All, Please find the updated Webrev at the below link.
>>>
>>> http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.01/
>>>
>>> I have added a new test that would go through different laf's and runs
>>> the test of the tab titles. Previously this test had been a single
>>> default laf test with appletviewer and now replaced for multi laf
>>> testing along with the normal java execution. There are instances of
>>> inaccurate rendering of the titles with respect to the tab pane
>>> component like clipping, starting offset and going beyond the tab pane
>>> size as shown below in some of the examples:
>>>
>>> This requires a different thread to really understand why this
>>> variation across the multiple laf representation and needs more proper
>>> bounding the title to fit properly within the tab pane space. Hence I
>>> will be raising multiple bugs to indicate these current issues and
>>> will be resolved later. Please note that this issue is /_not_/ because
>>> of the clipping of the text that these current changes that are done
>>> under this bug fix.
>>>
>>> Thanks and regards,
>>>
>>> Shashi
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Thursday, August 24, 2017 4:24 AM
>>> To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Shashidhara
>>> Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>;
>>> swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab
>>> titles are not clipped with dots at the end.
>>>
>>> I am not sure is it possible to prove, but I think that we need to
>>> pass tabPane as a component to ClipStrinUfNecessary.
>>>
>>> On 17.08.2017 3:48, Prasanta Sadhukhan wrote:
>>>
>>> ? > Fix looks good.
>>>
>>> ? >
>>>
>>> ? > But, can you update
>>>
>>> ? > test/javax/swing/JTabbedPane/4310381/bug4310381.java
>>>
>>> ? > to include the test for all installed l&fs so that we can see if
>>> there
>>>
>>> ? > is problem in any other l&fs?
>>>
>>> ? >
>>>
>>> ? > Regards
>>>
>>> ? > Prasanta
>>>
>>> ? > On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah wrote:
>>>
>>> ? >>
>>>
>>> ? >> Hi All, Please review a fix for the JDK- 8004029 where the long
>>> tab
>>>
>>> ? >> titles were not clipped with the dots at the end to indicate a
>>>
>>> ? >> lengthy title. The aqua look and feel which is the default laf for
>>>
>>> ? >> mac does the title clipping only leading to an ambiguous UI where
>>> in
>>>
>>> ? >> the clipped title would look like the /_complete_/ title though it
>>> is not.
>>>
>>> ? >> Hence it is good to show dots at the end indicating a much bigger
>>>
>>> ? >> title exists though the tab does not have enough real estate to
>>>
>>> ? >> display the complete title.
>>>
>>> ? >>
>>>
>>> ? >> _Solution and fix:_ I have updated the aqua laf module to clip the
>>>
>>> ? >> title text and put the dots at the end if the text size is larger
>>>
>>> ? >> than the tab size. Below is the picture /_after_/ the fix.
>>>
>>> ? >>
>>>
>>> ? >> Bug: https://bugs.openjdk.java.net/browse/JDK-8004029
>>>
>>> ? >>
>>>
>>> ? >> Webrev:
>>>
>>> ? >> http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/
>>>
>>> ? >> <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/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/swing-dev/attachments/20170912/26b08945/attachment.html>

From krishna.addepalli at oracle.com  Tue Sep 12 12:09:24 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 12 Sep 2017 12:09:24 +0000 (UTC)
Subject: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize()
 returns a width of 0
In-Reply-To: <382ced26-55e1-6687-dc82-4ea447ca80b2@oracle.com>
References: <3d254bda-e09a-4dd4-801f-0b8f4d160eb3@default>
 <29aa476c-ad54-f98c-7048-015815cf602a@oracle.com>
 <95dff71a-d730-402e-b5ed-bbd37ec64003@default>
 <6660d6cf-171a-5320-4cf7-76c366ff1a62@oracle.com>
 <c0b9e1af-6943-4f12-bc2b-64f7ece05dca@default>
 <b855f641-505f-2aaf-36b6-240f15dd1670@oracle.com>
 <7f201ea1-86a7-4204-48eb-8732e399446c@oracle.com>
 <24469b72-0680-4687-9eb7-da0978adf374@default>
 <382ced26-55e1-6687-dc82-4ea447ca80b2@oracle.com>
Message-ID: <5ba6116e-df48-4f79-ac3b-5832ed801541@default>

Hi Sergey,

Point taken. Did the relevant changes and created a new webrev:

http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev04/

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, September 12, 2017 1:03 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize() returns a width of 0

Hi, Krishna
Please use SwingUtilities.invokeAndWait() instead of invokeLater().
  - invokeAndWait() will wait while code is executed.
  - invokeLater() can start execution when the main() method is ended, so the jtreg will kill EDT before the test will do something useful.

On 9/10/17 22:03, Krishna Addepalli wrote:
> Hi Prasanta/Sergey,
> 
> I have updated the webrev based on your recommendations:
> 
> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev03/
> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 5, 2017 8:04 PM
> To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Krishna 
> Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize() 
> returns a width of 0
> 
> One more note: the Swing components should be accessed on EDT.
> 
> On 9/5/17 03:26, Prasanta Sadhukhan wrote:
>> +1. Just one thing, you can modify the testcase to use specific 
>> +imports
>> rather that wildcard imports.
>>
>> Regards
>> Prasanta
>> On 9/5/2017 3:26 PM, Krishna Addepalli wrote:
>>>
>>> Done that!
>>>
>>> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev02/
>>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev02/>
>>> is the updated webrev.
>>>
>>> Thanks,
>>>
>>> Krishna
>>>
>>> *From:*Prasanta Sadhukhan
>>> *Sent:* Monday, September 4, 2017 5:45 PM
>>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>> swing-dev at openjdk.java.net
>>> *Subject:* Re: <Swing Dev> [10][JDK-6714836]
>>> JRootPane.getMaximumSize() returns a width of 0
>>>
>>> Looks fine. But, remove @author tag as we do not use it anymore.
>>> Also, @modules tag is used to add some internal modules if test 
>>> needs one, here it is not needed, so you remove that too. Add @run tag.
>>>
>>> Regards
>>> Prasanta
>>>
>>> On 9/4/2017 3:46 PM, Krishna Addepalli wrote:
>>>
>>>      Hi Prasanta,
>>>
>>>      Thanks for bringing that up. I have updated the webrev with the
>>>      test case.
>>>
>>>      JDK 10 Webrev:
>>>      http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev.01/
>>>      
>>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev.01/>
>>>
>>>      Krishna
>>>
>>>      *From:*Prasanta Sadhukhan
>>>      *Sent:* Thursday, August 24, 2017 1:50 PM
>>>      *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>>      <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>>>      <mailto:swing-dev at openjdk.java.net>
>>>      *Subject:* Re: <Swing Dev> [10][JDK-6714836]
>>>      JRootPane.getMaximumSize() returns a width of 0
>>>
>>>      You can add a regression test with the fix as JBS already has one.
>>>
>>>      Regards
>>>      Prasanta
>>>
>>>      On 8/24/2017 12:37 PM, Krishna Addepalli wrote:
>>>
>>>          Hi All,
>>>
>>>          Bug : JDK- 6714836
>>>          <https://bugs.openjdk.java.net/browse/JDK-6714836>
>>>          <%3chttps:/bugs.openjdk.java.net/browse/JDK-6714836%3e>
>>>
>>>          JDK 10 Webrev:
>>>          
>>> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev00/
>>>          
>>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev00/>
>>>
>>>          The issue is that when a text label is added to JRootPane and
>>>          query the maximumLayoutSize, it is returning 0. The root cause
>>>          is because, JRootPane decides to provide the Minimum width of
>>>          Menubar (which in this case is 0) and the content pane (which
>>>          contains the JLabel). Actually, it should return the maximum
>>>          of the two, since that is what is the layout size needed.
>>>
>>>          Thanks,
>>>
>>>          Krishna
>>>
>>
> 
> 
> --
> Best regards, Sergey.
> 


--
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Sep 12 19:23:00 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Sep 2017 12:23:00 -0700
Subject: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize()
 returns a width of 0
In-Reply-To: <5ba6116e-df48-4f79-ac3b-5832ed801541@default>
References: <3d254bda-e09a-4dd4-801f-0b8f4d160eb3@default>
 <29aa476c-ad54-f98c-7048-015815cf602a@oracle.com>
 <95dff71a-d730-402e-b5ed-bbd37ec64003@default>
 <6660d6cf-171a-5320-4cf7-76c366ff1a62@oracle.com>
 <c0b9e1af-6943-4f12-bc2b-64f7ece05dca@default>
 <b855f641-505f-2aaf-36b6-240f15dd1670@oracle.com>
 <7f201ea1-86a7-4204-48eb-8732e399446c@oracle.com>
 <24469b72-0680-4687-9eb7-da0978adf374@default>
 <382ced26-55e1-6687-dc82-4ea447ca80b2@oracle.com>
 <5ba6116e-df48-4f79-ac3b-5832ed801541@default>
Message-ID: <ee35d9b6-fb14-6390-0930-7f0105ec9e7d@oracle.com>

Looks fine.

On 9/12/17 05:09, Krishna Addepalli wrote:
> Hi Sergey,
> 
> Point taken. Did the relevant changes and created a new webrev:
> 
> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev04/
> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 12, 2017 1:03 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize() returns a width of 0
> 
> Hi, Krishna
> Please use SwingUtilities.invokeAndWait() instead of invokeLater().
>    - invokeAndWait() will wait while code is executed.
>    - invokeLater() can start execution when the main() method is ended, so the jtreg will kill EDT before the test will do something useful.
> 
> On 9/10/17 22:03, Krishna Addepalli wrote:
>> Hi Prasanta/Sergey,
>>
>> I have updated the webrev based on your recommendations:
>>
>> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev03/
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Tuesday, September 5, 2017 8:04 PM
>> To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Krishna
>> Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [10][JDK-6714836] JRootPane.getMaximumSize()
>> returns a width of 0
>>
>> One more note: the Swing components should be accessed on EDT.
>>
>> On 9/5/17 03:26, Prasanta Sadhukhan wrote:
>>> +1. Just one thing, you can modify the testcase to use specific
>>> +imports
>>> rather that wildcard imports.
>>>
>>> Regards
>>> Prasanta
>>> On 9/5/2017 3:26 PM, Krishna Addepalli wrote:
>>>>
>>>> Done that!
>>>>
>>>> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev02/
>>>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev02/>
>>>> is the updated webrev.
>>>>
>>>> Thanks,
>>>>
>>>> Krishna
>>>>
>>>> *From:*Prasanta Sadhukhan
>>>> *Sent:* Monday, September 4, 2017 5:45 PM
>>>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>> swing-dev at openjdk.java.net
>>>> *Subject:* Re: <Swing Dev> [10][JDK-6714836]
>>>> JRootPane.getMaximumSize() returns a width of 0
>>>>
>>>> Looks fine. But, remove @author tag as we do not use it anymore.
>>>> Also, @modules tag is used to add some internal modules if test
>>>> needs one, here it is not needed, so you remove that too. Add @run tag.
>>>>
>>>> Regards
>>>> Prasanta
>>>>
>>>> On 9/4/2017 3:46 PM, Krishna Addepalli wrote:
>>>>
>>>>       Hi Prasanta,
>>>>
>>>>       Thanks for bringing that up. I have updated the webrev with the
>>>>       test case.
>>>>
>>>>       JDK 10 Webrev:
>>>>       http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev.01/
>>>>       
>>>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev.01/>
>>>>
>>>>       Krishna
>>>>
>>>>       *From:*Prasanta Sadhukhan
>>>>       *Sent:* Thursday, August 24, 2017 1:50 PM
>>>>       *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>>>       <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>>>>       <mailto:swing-dev at openjdk.java.net>
>>>>       *Subject:* Re: <Swing Dev> [10][JDK-6714836]
>>>>       JRootPane.getMaximumSize() returns a width of 0
>>>>
>>>>       You can add a regression test with the fix as JBS already has one.
>>>>
>>>>       Regards
>>>>       Prasanta
>>>>
>>>>       On 8/24/2017 12:37 PM, Krishna Addepalli wrote:
>>>>
>>>>           Hi All,
>>>>
>>>>           Bug : JDK- 6714836
>>>>           <https://bugs.openjdk.java.net/browse/JDK-6714836>
>>>>           <%3chttps:/bugs.openjdk.java.net/browse/JDK-6714836%3e>
>>>>
>>>>           JDK 10 Webrev:
>>>>           
>>>> http://cr.openjdk.java.net/~pkbalakr/Krishna/6714836/webrev00/
>>>>           
>>>> <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/6714836/webrev00/>
>>>>
>>>>           The issue is that when a text label is added to JRootPane and
>>>>           query the maximumLayoutSize, it is returning 0. The root cause
>>>>           is because, JRootPane decides to provide the Minimum width of
>>>>           Menubar (which in this case is 0) and the content pane (which
>>>>           contains the JLabel). Actually, it should return the maximum
>>>>           of the two, since that is what is the layout size needed.
>>>>
>>>>           Thanks,
>>>>
>>>>           Krishna
>>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.


From georg.kratz-kummetz at uniklinik-freiburg.de  Wed Sep 13 12:13:23 2017
From: georg.kratz-kummetz at uniklinik-freiburg.de (Dr. Georg Kratz-Kummetz)
Date: Wed, 13 Sep 2017 12:13:23 +0000
Subject: <Swing Dev> Swing: NPE after calling JTable.updateUI() when using a
 header renderer + Windows L&F
Message-ID: <49c9bb6140454fc995577da7dcb6ad70@UKL-EX02.ad.uniklinik-freiburg.de>

The Error occurs for example in Windows 10 when changing theme in Windows while an extended TableHeaderRenderer is working.
System is: Windows 10 (10.0.10240)
Java is: 1.8.0_60

Stacktrace is

java.lang.NullPointerException

com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.paint

(Unknown Source)

javax.swing.CellRendererPane.paintComponent(Unknown Source)

javax.swing.plaf.basic.BasicTableHeaderUI.paintCell(Unknown Source)

javax.swing.plaf.basic.BasicTableHeaderUI.paint(Unknown Source)

javax.swing.plaf.ComponentUI.update(Unknown Source)

javax.swing.JComponent.paintComponent(Unknown Source)

javax.swing.JComponent.paint(Unknown Source)

javax.swing.JComponent.paintChildren(Unknown Source)

javax.swing.JComponent.paint(Unknown Source)

javax.swing.JViewport.paint(Unknown Source)

javax.swing.JComponent.paintChildren(Unknown Source)

javax.swing.JComponent.paint(Unknown Source)

javax.swing.JComponent.paintChildren(Unknown Source)

javax.swing.JComponent.paint(Unknown Source)

javax.swing.JComponent.paintChildren(Unknown Source)

javax.swing.JComponent.paint(Unknown Source)

javax.swing.JComponent.paintChildren(Unknown Source)

javax.swing.JComponent.paint(Unknown Source)

javax.swing.JComponent.paintChildren(Unknown Source)

javax.swing.JComponent.paint(Unknown Source)

javax.swing.JLayeredPane.paint(Unknown Source)

javax.swing.JComponent.paintChildren(Unknown Source)

javax.swing.JComponent.paintToOffscreen(Unknown Source)

javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown Source)

javax.swing.RepaintManager$PaintManager.paint(Unknown Source)

javax.swing.RepaintManager.paint(Unknown Source)

javax.swing.JComponent.paint(Unknown Source)

java.awt.GraphicsCallback$PaintCallback.run(Unknown Source)

sun.awt.SunGraphicsCallback.runOneComponent(Unknown Source)

sun.awt.SunGraphicsCallback.runComponents(Unknown Source)

java.awt.Container.paint(Unknown Source)

java.awt.Window.paint(Unknown Source)

javax.swing.RepaintManager$4.run(Unknown Source)

javax.swing.RepaintManager$4.run(Unknown Source)

java.security.AccessController.doPrivileged(Native Method)

java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivileg

e(Unknown Source)

javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)

javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)

javax.swing.RepaintManager.prePaintDirtyRegions(Unknown Source)

javax.swing.RepaintManager.access$1200(Unknown Source)

javax.swing.RepaintManager$ProcessingRunnable.run(Unknown Source)

java.awt.event.InvocationEvent.dispatch(Unknown Source)

java.awt.EventQueue.dispatchEventImpl(Unknown Source)

java.awt.EventQueue.access$500(Unknown Source)

java.awt.EventQueue$3.run(Unknown Source)

java.awt.EventQueue$3.run(Unknown Source)

java.security.AccessController.doPrivileged(Native Method)

java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivileg

e(Unknown Source)

java.awt.EventQueue.dispatchEvent(Unknown Source)

java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)

java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)

java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)

Best documented Bug documentation:
http://bugs.java.com/view_bug.do?bug_id=6429812

With regards
Dr. Georg Kratz-Kummetz

UNIVERSIT?TSKLINIKUM FREIBURG
Klinikrechenzentrum
Patientenmanagement Systeme

Agnesenstr. 6 - 8 ? 79106 Freiburg
Telefon: +49 761 270-22910
Telefax: +49 761 270-20660

www.uniklinik-freiburg.de

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

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: <Swing Dev> <AWT 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 Sergey.Bylokhov at oracle.com  Wed Sep 13 22:39:00 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Sep 2017 15:39:00 -0700
Subject: <Swing Dev> [10] Review Request: 8187399 Different problems in the
 javadoc's links in java.desktop package
Message-ID: <8d147726-4e2f-b633-29e5-9ffd7c4cfb54@oracle.com>

Hello,
Please review the fix for jdk10.

Some of the tidy warnings were fixed.
Report is here:
http://cr.openjdk.java.net/~jjg/doc-report/jdk-by-module/java.desktop/report.html

Description:
  - java/awt/Desktop.java: the links to "developer.apple.com" were 
removed, it seems that the URLs for these documents are changed over 
time as well as content. We will mention only "CFBundleDocumentTypes" 
and "Info.plist" in the description.
  - javax/print/attribute/standard/PresentationDirection.java: the link 
was changed from ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf
to ftp://ftp.pwg.org/pub/pwg/standards/temp_archive/pwg5100.3.pdf , but 
I guess this is a stable location because the files are there from 2004.
  - others are just broken links which were fixed.

I checked the whole list of links in the desktop module, and found that 
some of them are broken. For example I cannot find an official place for 
the tiff specification(and related documents). Also during migration 
from sun.com we lost some documents, I leave such links as-is, and plan 
to resurrect the documents somewhere.

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


-- 
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: <Swing Dev> <AWT 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/swing-dev/attachments/20170914/d60fce4d/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Thu Sep 14 10:13:02 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 14 Sep 2017 10:13:02 +0000 (UTC)
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <4fd8f3e1-1a16-95bb-c68e-d572bf85a087@oracle.com>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
 <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
 <82ac9212-d59e-4368-ad4e-89d210bbb204@default>
 <fae37d24-4d62-49c4-b0dd-fcc1df18e64f@default>
 <2cb8f671-4a48-827c-504d-62ba4d9ff7f5@oracle.com>
 <4fd8f3e1-1a16-95bb-c68e-d572bf85a087@oracle.com>
Message-ID: <cc99b4b6-d1c5-4215-a9dc-34b765a44f8b@default>

Hi Prasanta, Here is the updated Webrev.

?

http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.03/

?

Please note that I have not done the 2nd change(disposeUI() case) as this is required for the time out case where in the testresult had been initialized with false and would call the disposeUI() accordingly.

?

Thanks and regards,

Shashi

?

From: Prasanta Sadhukhan 
Sent: Tuesday, September 12, 2017 11:45 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net
Cc: Sergey Bylokhov <sergey.bylokhov at oracle.com>
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.

?

Few observations on test:

init() needs to be called under EDT
you are calling disposeUI() in line 233, so it seems there is no need calling again in line122

Regards
Prasanta

On 9/12/2017 12:54 AM, Sergey Bylokhov wrote:

Looks fine. 

On 9/11/17 01:34, Shashidhara Veerabhadraiah wrote: 



Hi, I have updated the webrev to indicate the removal of a file which is not required anymore owing to the change in test from appletviewer based to standard java execution. This is only for the reference. 

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

Thanks and regards, 
Shashi 

-----Original Message----- 
From: Shashidhara Veerabhadraiah 
Sent: Monday, September 11, 2017 9:37 AM 
To: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net 
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end. 

Right Sergey. I was not sure on how to represent it under this Webrev. I will update the Webrev if need be. 

Thanks and regards, 
Shashi 

-----Original Message----- 
From: Sergey Bylokhov 
Sent: Saturday, September 9, 2017 7:33 AM 
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net 
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end. 

Hi, Shashi. 
The fix looks fine, but it looks like bug4310381.html should be removed because it is not used? 

On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote: 



Hi All, Please find the updated Webrev at the below link. 

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

I have added a new test that would go through different laf's and runs 
the test of the tab titles. Previously this test had been a single 
default laf test with appletviewer and now replaced for multi laf 
testing along with the normal java execution. There are instances of 
inaccurate rendering of the titles with respect to the tab pane 
component like clipping, starting offset and going beyond the tab pane 
size as shown below in some of the examples: 

This requires a different thread to really understand why this 
variation across the multiple laf representation and needs more proper 
bounding the title to fit properly within the tab pane space. Hence I 
will be raising multiple bugs to indicate these current issues and 
will be resolved later. Please note that this issue is /_not_/ because 
of the clipping of the text that these current changes that are done 
under this bug fix. 

Thanks and regards, 

Shashi 

-----Original Message----- 
From: Sergey Bylokhov 
Sent: Thursday, August 24, 2017 4:24 AM 
To: Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; Shashidhara 
Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; 
HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net 
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab 
titles are not clipped with dots at the end. 

I am not sure is it possible to prove, but I think that we need to 
pass tabPane as a component to ClipStrinUfNecessary. 

On 17.08.2017 3:48, Prasanta Sadhukhan wrote: 

? > Fix looks good. 

? > 

? > But, can you update 

? > test/javax/swing/JTabbedPane/4310381/bug4310381.java 

? > to include the test for all installed l&fs so that we can see if 
there 

? > is problem in any other l&fs? 

? > 

? > Regards 

? > Prasanta 

? > On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah wrote: 

? >> 

? >> Hi All, Please review a fix for the JDK- 8004029 where the long 
tab 

? >> titles were not clipped with the dots at the end to indicate a 

? >> lengthy title. The aqua look and feel which is the default laf for 

? >> mac does the title clipping only leading to an ambiguous UI where 
in 

? >> the clipped title would look like the /_complete_/ title though it 
is not. 

? >> Hence it is good to show dots at the end indicating a much bigger 

? >> title exists though the tab does not have enough real estate to 

? >> display the complete title. 

? >> 

? >> _Solution and fix:_ I have updated the aqua laf module to clip the 

? >> title text and put the dots at the end if the text size is larger 

? >> than the tab size. Below is the picture /_after_/ the fix. 

? >> 

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

? >> 

? >> Webrev: 

? >> http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/ 

? >> HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/"<http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/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/swing-dev/attachments/20170914/768b7d06/attachment.html>

From prasanta.sadhukhan at oracle.com  Thu Sep 14 10:56:16 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 14 Sep 2017 16:26:16 +0530
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <cc99b4b6-d1c5-4215-a9dc-34b765a44f8b@default>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
 <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
 <82ac9212-d59e-4368-ad4e-89d210bbb204@default>
 <fae37d24-4d62-49c4-b0dd-fcc1df18e64f@default>
 <2cb8f671-4a48-827c-504d-62ba4d9ff7f5@oracle.com>
 <4fd8f3e1-1a16-95bb-c68e-d572bf85a087@oracle.com>
 <cc99b4b6-d1c5-4215-a9dc-34b765a44f8b@default>
Message-ID: <13af7065-dfa4-3164-dca3-b762d9917dba@oracle.com>

One more thing I noticed

106 } catch (Exception e) {
107 throw new RuntimeException(e);
  108              }
109
110 // disposing the frame
111 SwingUtilities.invokeAndWait(() -> {
112 frame.dispose();
  113             });

if there is any exception thrown as above, then we are not going to 
dispose. I believe it will be better if we do try-catch-finally and add 
frame.dispose() in finally block.
Also, I think it should be disposeUI() rather than frame.dispose() as we 
have already called createUI() by that time so testUI frame is also present.

Also, for 2nd change, I got your point. In that case, I guess you can 
bring l122-123 inside if (!status)

117 if (!status) {
118 System.out.println("Test timed out.");
119 }
120
121 if (test.testResult == false) {
122 disposeUI();
123 throw new RuntimeException("Test Failed.");
124 } Maybe you can call full thing under try-catch-finally   try{
86 for(UIManager.LookAndFeelInfo laf : 
UIManager.getInstalledLookAndFeels()) { ......... } catch () { throw 
RuntimeException } finally { disposeUI(); } Regards Prasanta

On 9/14/2017 3:43 PM, Shashidhara Veerabhadraiah wrote:
>
> Hi Prasanta, Here is the updated Webrev.
>
> http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.03/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.03/>
>
> Please note that I have not done the 2^nd change(disposeUI() case) as 
> this is required for the time out case where in the testresult had 
> been initialized with false and would call the disposeUI() accordingly.
>
> Thanks and regards,
>
> Shashi
>
> *From:*Prasanta Sadhukhan
> *Sent:* Tuesday, September 12, 2017 11:45 AM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net
> *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
> *Subject:* Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab 
> titles are not clipped with dots at the end.
>
> Few observations on test:
>
> init() needs to be called under EDT
> you are calling disposeUI() in line 233, so it seems there is no need 
> calling again in line122
>
> Regards
> Prasanta
>
> On 9/12/2017 12:54 AM, Sergey Bylokhov wrote:
>
>     Looks fine.
>
>     On 9/11/17 01:34, Shashidhara Veerabhadraiah wrote:
>
>         Hi, I have updated the webrev to indicate the removal of a
>         file which is not required anymore owing to the change in test
>         from appletviewer based to standard java execution. This is
>         only for the reference.
>
>         http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.02/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.02/>
>
>         Thanks and regards,
>         Shashi
>
>         -----Original Message-----
>         From: Shashidhara Veerabhadraiah
>         Sent: Monday, September 11, 2017 9:37 AM
>         To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
>         <mailto:sergey.bylokhov at oracle.com>; Prasanta Sadhukhan
>         <prasanta.sadhukhan at oracle.com>
>         <mailto:prasanta.sadhukhan at oracle.com>;
>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>         Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long
>         Tab titles are not clipped with dots at the end.
>
>         Right Sergey. I was not sure on how to represent it under this
>         Webrev. I will update the Webrev if need be.
>
>         Thanks and regards,
>         Shashi
>
>         -----Original Message-----
>         From: Sergey Bylokhov
>         Sent: Saturday, September 9, 2017 7:33 AM
>         To: Shashidhara Veerabhadraiah
>         <shashidhara.veerabhadraiah at oracle.com>
>         <mailto:shashidhara.veerabhadraiah at oracle.com>; Prasanta
>         Sadhukhan <prasanta.sadhukhan at oracle.com>
>         <mailto:prasanta.sadhukhan at oracle.com>;
>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>         Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long
>         Tab titles are not clipped with dots at the end.
>
>         Hi, Shashi.
>         The fix looks fine, but it looks like bug4310381.html should
>         be removed because it is not used?
>
>         On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote:
>
>             Hi All, Please find the updated Webrev at the below link.
>
>             http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.01/
>             <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.01/>
>
>
>             I have added a new test that would go through different
>             laf's and runs
>             the test of the tab titles. Previously this test had been
>             a single
>             default laf test with appletviewer and now replaced for
>             multi laf
>             testing along with the normal java execution. There are
>             instances of
>             inaccurate rendering of the titles with respect to the tab
>             pane
>             component like clipping, starting offset and going beyond
>             the tab pane
>             size as shown below in some of the examples:
>
>             This requires a different thread to really understand why
>             this
>             variation across the multiple laf representation and needs
>             more proper
>             bounding the title to fit properly within the tab pane
>             space. Hence I
>             will be raising multiple bugs to indicate these current
>             issues and
>             will be resolved later. Please note that this issue is
>             /_not_/ because
>             of the clipping of the text that these current changes
>             that are done
>             under this bug fix.
>
>             Thanks and regards,
>
>             Shashi
>
>             -----Original Message-----
>             From: Sergey Bylokhov
>             Sent: Thursday, August 24, 2017 4:24 AM
>             To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>
>             <mailto:prasanta.sadhukhan at oracle.com>; Shashidhara
>             Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
>             <mailto:shashidhara.veerabhadraiah at oracle.com>;
>             swing-dev at openjdk.java.net
>             <mailto:swing-dev at openjdk.java.net>
>             Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The
>             long Tab
>             titles are not clipped with dots at the end.
>
>             I am not sure is it possible to prove, but I think that we
>             need to
>             pass tabPane as a component to ClipStrinUfNecessary.
>
>             On 17.08.2017 3:48, Prasanta Sadhukhan wrote:
>
>             ? > Fix looks good.
>
>             ? >
>
>             ? > But, can you update
>
>             ? > test/javax/swing/JTabbedPane/4310381/bug4310381.java
>
>             ? > to include the test for all installed l&fs so that we
>             can see if
>             there
>
>             ? > is problem in any other l&fs?
>
>             ? >
>
>             ? > Regards
>
>             ? > Prasanta
>
>             ? > On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah wrote:
>
>             ? >>
>
>             ? >> Hi All, Please review a fix for the JDK- 8004029
>             where the long
>             tab
>
>             ? >> titles were not clipped with the dots at the end to
>             indicate a
>
>             ? >> lengthy title. The aqua look and feel which is the
>             default laf for
>
>             ? >> mac does the title clipping only leading to an
>             ambiguous UI where
>             in
>
>             ? >> the clipped title would look like the /_complete_/
>             title though it
>             is not.
>
>             ? >> Hence it is good to show dots at the end indicating a
>             much bigger
>
>             ? >> title exists though the tab does not have enough real
>             estate to
>
>             ? >> display the complete title.
>
>             ? >>
>
>             ? >> _Solution and fix:_ I have updated the aqua laf
>             module to clip the
>
>             ? >> title text and put the dots at the end if the text
>             size is larger
>
>             ? >> than the tab size. Below is the picture /_after_/ the
>             fix.
>
>             ? >>
>
>             ? >> Bug: https://bugs.openjdk.java.net/browse/JDK-8004029
>
>             ? >>
>
>             ? >> Webrev:
>
>             ? >>
>             http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/
>             <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>
>
>
>             ? >>
>             <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>
>             <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/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/swing-dev/attachments/20170914/13a9bf1d/attachment.html>

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: <Swing Dev> <AWT 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/swing-dev/attachments/20170914/30ba989f/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Sep 14 18:18:14 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Sep 2017 11:18:14 -0700
Subject: <Swing Dev> Swing: NPE after calling JTable.updateUI() when
 using a header renderer + Windows L&F
In-Reply-To: <49c9bb6140454fc995577da7dcb6ad70@UKL-EX02.ad.uniklinik-freiburg.de>
References: <49c9bb6140454fc995577da7dcb6ad70@UKL-EX02.ad.uniklinik-freiburg.de>
Message-ID: <3a18bea5-1146-7cf3-f134-f8d1228af711@oracle.com>

Hi, Georg.
Thank you for the report, I will take a look.

On 9/13/17 05:13, Dr. Georg Kratz-Kummetz wrote:
> The Error occurs for example in Windows 10 when changing theme in 
> Windows while an extended TableHeaderRenderer is working.
> 
> System is: Windows 10 (10.0.10240)
> 
> Java is: 1.8.0_60
> 
> Stacktrace is
> 
> java.lang.NullPointerException
> 
> com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.paint
> 
> (Unknown Source)
> 
> javax.swing.CellRendererPane.paintComponent(Unknown Source)
> 
> javax.swing.plaf.basic.BasicTableHeaderUI.paintCell(Unknown Source)
> 
> javax.swing.plaf.basic.BasicTableHeaderUI.paint(Unknown Source)
> 
> javax.swing.plaf.ComponentUI.update(Unknown Source)
> 
> javax.swing.JComponent.paintComponent(Unknown Source)
> 
> javax.swing.JComponent.paint(Unknown Source)
> 
> javax.swing.JComponent.paintChildren(Unknown Source)
> 
> javax.swing.JComponent.paint(Unknown Source)
> 
> javax.swing.JViewport.paint(Unknown Source)
> 
> javax.swing.JComponent.paintChildren(Unknown Source)
> 
> javax.swing.JComponent.paint(Unknown Source)
> 
> javax.swing.JComponent.paintChildren(Unknown Source)
> 
> javax.swing.JComponent.paint(Unknown Source)
> 
> javax.swing.JComponent.paintChildren(Unknown Source)
> 
> javax.swing.JComponent.paint(Unknown Source)
> 
> javax.swing.JComponent.paintChildren(Unknown Source)
> 
> javax.swing.JComponent.paint(Unknown Source)
> 
> javax.swing.JComponent.paintChildren(Unknown Source)
> 
> javax.swing.JComponent.paint(Unknown Source)
> 
> javax.swing.JLayeredPane.paint(Unknown Source)
> 
> javax.swing.JComponent.paintChildren(Unknown Source)
> 
> javax.swing.JComponent.paintToOffscreen(Unknown Source)
> 
> javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown Source)
> 
> javax.swing.RepaintManager$PaintManager.paint(Unknown Source)
> 
> javax.swing.RepaintManager.paint(Unknown Source)
> 
> javax.swing.JComponent.paint(Unknown Source)
> 
> java.awt.GraphicsCallback$PaintCallback.run(Unknown Source)
> 
> sun.awt.SunGraphicsCallback.runOneComponent(Unknown Source)
> 
> sun.awt.SunGraphicsCallback.runComponents(Unknown Source)
> 
> java.awt.Container.paint(Unknown Source)
> 
> java.awt.Window.paint(Unknown Source)
> 
> javax.swing.RepaintManager$4.run(Unknown Source)
> 
> javax.swing.RepaintManager$4.run(Unknown Source)
> 
> java.security.AccessController.doPrivileged(Native Method)
> 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivileg
> 
> e(Unknown Source)
> 
> javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
> 
> javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
> 
> javax.swing.RepaintManager.prePaintDirtyRegions(Unknown Source)
> 
> javax.swing.RepaintManager.access$1200(Unknown Source)
> 
> javax.swing.RepaintManager$ProcessingRunnable.run(Unknown Source)
> 
> java.awt.event.InvocationEvent.dispatch(Unknown Source)
> 
> java.awt.EventQueue.dispatchEventImpl(Unknown Source)
> 
> java.awt.EventQueue.access$500(Unknown Source)
> 
> java.awt.EventQueue$3.run(Unknown Source)
> 
> java.awt.EventQueue$3.run(Unknown Source)
> 
> java.security.AccessController.doPrivileged(Native Method)
> 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivileg
> 
> e(Unknown Source)
> 
> java.awt.EventQueue.dispatchEvent(Unknown Source)
> 
> java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
> 
> java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
> 
> java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
> 
> Best documented Bug documentation:
> 
> http://bugs.java.com/view_bug.do?bug_id=6429812
> 
> With regards
> 
> Dr. Georg Kratz-Kummetz
> 
> UNIVERSIT?TSKLINIKUM FREIBURG
> 
> Klinikrechenzentrum
> 
> Patientenmanagement Systeme
> 
> Agnesenstr. 6 ? 8 ? 79106 Freiburg
> 
> Telefon: +49 761 270-22910
> 
> Telefax: +49 761 270-20660
> 
> www.uniklinik-freiburg.de
> 


-- 
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: <Swing Dev> <AWT 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/swing-dev/attachments/20170915/0c0ff69b/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Fri Sep 15 09:27:50 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Fri, 15 Sep 2017 09:27:50 +0000 (UTC)
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <13af7065-dfa4-3164-dca3-b762d9917dba@oracle.com>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
 <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
 <82ac9212-d59e-4368-ad4e-89d210bbb204@default>
 <fae37d24-4d62-49c4-b0dd-fcc1df18e64f@default>
 <2cb8f671-4a48-827c-504d-62ba4d9ff7f5@oracle.com>
 <4fd8f3e1-1a16-95bb-c68e-d572bf85a087@oracle.com>
 <cc99b4b6-d1c5-4215-a9dc-34b765a44f8b@default>
 <13af7065-dfa4-3164-dca3-b762d9917dba@oracle.com>
Message-ID: <613157a7-b4c1-410c-b107-7b0b953df2d1@default>

Hi, Here is the updated webrev. Removed unnecessary try catch blocks!!

?

http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.04/

?

Thanks and regards,

Shashi

?

From: Prasanta Sadhukhan 
Sent: Thursday, September 14, 2017 4:26 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net
Cc: Sergey Bylokhov <sergey.bylokhov at oracle.com>
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.

?

One more thing I noticed

106????????????? } catch (Exception e) {
 107?????????????????? throw new RuntimeException(e);
 108????????????? }
 109 
?110???????????? // disposing the frame
 111???????????? SwingUtilities.invokeAndWait(() -> {
 112????????? ???????frame.dispose();
 113???????????? });

if there is any exception thrown as above, then we are not going to dispose. I believe it will be better if we do try-catch-finally and add frame.dispose() in finally block.
Also, I think it should be disposeUI() rather than frame.dispose() as we have already called createUI() by that time so testUI frame is also present.

Also, for 2nd change, I got your point. In that case, I guess you can bring l122-123 inside if (!status)

117???????? if (!status) {
 118???? ????????System.out.println("Test timed out.");
 119???????? }
 120 
?121???????? if (test.testResult == false) {
 122???????????? disposeUI();
 123???????????? throw new RuntimeException("Test Failed.");
 124???????? }
?
Maybe you can call full thing under try-catch-finally
 try{
86???????? for(UIManager.LookAndFeelInfo laf : UIManager.getInstalledLookAndFeels()) {
.........
} catch () {
 throw RuntimeException
} finally {
 disposeUI();
}
?
Regards
Prasanta

On 9/14/2017 3:43 PM, Shashidhara Veerabhadraiah wrote:

Hi Prasanta, Here is the updated Webrev.

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.03/"http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.03/

?

Please note that I have not done the 2nd change(disposeUI() case) as this is required for the time out case where in the testresult had been initialized with false and would call the disposeUI() accordingly.

?

Thanks and regards,

Shashi

?

From: Prasanta Sadhukhan 
Sent: Tuesday, September 12, 2017 11:45 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.

?

Few observations on test:

init() needs to be called under EDT
you are calling disposeUI() in line 233, so it seems there is no need calling again in line122

Regards
Prasanta

On 9/12/2017 12:54 AM, Sergey Bylokhov wrote:

Looks fine. 

On 9/11/17 01:34, Shashidhara Veerabhadraiah wrote: 




Hi, I have updated the webrev to indicate the removal of a file which is not required anymore owing to the change in test from appletviewer based to standard java execution. This is only for the reference. 

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.02/ 

Thanks and regards, 
Shashi 

-----Original Message----- 
From: Shashidhara Veerabhadraiah 
Sent: Monday, September 11, 2017 9:37 AM 
To: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net 
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end. 

Right Sergey. I was not sure on how to represent it under this Webrev. I will update the Webrev if need be. 

Thanks and regards, 
Shashi 

-----Original Message----- 
From: Sergey Bylokhov 
Sent: Saturday, September 9, 2017 7:33 AM 
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net 
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end. 

Hi, Shashi. 
The fix looks fine, but it looks like bug4310381.html should be removed because it is not used? 

On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote: 




Hi All, Please find the updated Webrev at the below link. 

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.01/ 

I have added a new test that would go through different laf's and runs 
the test of the tab titles. Previously this test had been a single 
default laf test with appletviewer and now replaced for multi laf 
testing along with the normal java execution. There are instances of 
inaccurate rendering of the titles with respect to the tab pane 
component like clipping, starting offset and going beyond the tab pane 
size as shown below in some of the examples: 

This requires a different thread to really understand why this 
variation across the multiple laf representation and needs more proper 
bounding the title to fit properly within the tab pane space. Hence I 
will be raising multiple bugs to indicate these current issues and 
will be resolved later. Please note that this issue is /_not_/ because 
of the clipping of the text that these current changes that are done 
under this bug fix. 

Thanks and regards, 

Shashi 

-----Original Message----- 
From: Sergey Bylokhov 
Sent: Thursday, August 24, 2017 4:24 AM 
To: Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; Shashidhara 
Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; 
HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net 
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab 
titles are not clipped with dots at the end. 

I am not sure is it possible to prove, but I think that we need to 
pass tabPane as a component to ClipStrinUfNecessary. 

On 17.08.2017 3:48, Prasanta Sadhukhan wrote: 

? > Fix looks good. 

? > 

? > But, can you update 

? > test/javax/swing/JTabbedPane/4310381/bug4310381.java 

? > to include the test for all installed l&fs so that we can see if 
there 

? > is problem in any other l&fs? 

? > 

? > Regards 

? > Prasanta 

? > On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah wrote: 

? >> 

? >> Hi All, Please review a fix for the JDK- 8004029 where the long 
tab 

? >> titles were not clipped with the dots at the end to indicate a 

? >> lengthy title. The aqua look and feel which is the default laf for 

? >> mac does the title clipping only leading to an ambiguous UI where 
in 

? >> the clipped title would look like the /_complete_/ title though it 
is not. 

? >> Hence it is good to show dots at the end indicating a much bigger 

? >> title exists though the tab does not have enough real estate to 

? >> display the complete title. 

? >> 

? >> _Solution and fix:_ I have updated the aqua laf module to clip the 

? >> title text and put the dots at the end if the text size is larger 

? >> than the tab size. Below is the picture /_after_/ the fix. 

? >> 

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

? >> 

? >> Webrev: 

? >> HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/"http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/ 

? >> HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/"<http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/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/swing-dev/attachments/20170915/fc8f1853/attachment.html>

From prasanta.sadhukhan at oracle.com  Fri Sep 15 09:40:49 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 15 Sep 2017 15:10:49 +0530
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <613157a7-b4c1-410c-b107-7b0b953df2d1@default>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
 <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
 <82ac9212-d59e-4368-ad4e-89d210bbb204@default>
 <fae37d24-4d62-49c4-b0dd-fcc1df18e64f@default>
 <2cb8f671-4a48-827c-504d-62ba4d9ff7f5@oracle.com>
 <4fd8f3e1-1a16-95bb-c68e-d572bf85a087@oracle.com>
 <cc99b4b6-d1c5-4215-a9dc-34b765a44f8b@default>
 <13af7065-dfa4-3164-dca3-b762d9917dba@oracle.com>
 <613157a7-b4c1-410c-b107-7b0b953df2d1@default>
Message-ID: <dc9bc33f-a236-61c5-4a91-e944c80a5801@oracle.com>

looks better. but, disposeUI() do not throw any exception so no need to 
catch in


try {
122 if(test != null) {
123 test.disposeUI();
124 }
125 } catch (Exception ex) {
126 throw new RuntimeException("Exception while disposing UI");
  127             }

Regards
Prasanta

On 9/15/2017 2:57 PM, Shashidhara Veerabhadraiah wrote:
>
> Hi, Here is the updated webrev. Removed unnecessary try catch blocks!!
>
> http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.04/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.04/>
>
> Thanks and regards,
>
> Shashi
>
> *From:*Prasanta Sadhukhan
> *Sent:* Thursday, September 14, 2017 4:26 PM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net
> *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
> *Subject:* Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab 
> titles are not clipped with dots at the end.
>
> One more thing I noticed
>
> 106????????????? } catch (Exception e) {
> 107?????????????????? throw new RuntimeException(e);
>   108????????????? }
> 109
> ?110???????????? // disposing the frame
> 111???????????? SwingUtilities.invokeAndWait(() -> {
> 112????????? ???????frame.dispose();
>   113???????????? });
>
> if there is any exception thrown as above, then we are not going to 
> dispose. I believe it will be better if we do try-catch-finally and 
> add frame.dispose() in finally block.
> Also, I think it should be disposeUI() rather than frame.dispose() as 
> we have already called createUI() by that time so testUI frame is also 
> present.
>
> Also, for 2nd change, I got your point. In that case, I guess you can 
> bring l122-123 inside if (!status)
>
> 117???????? if (!status) {
> 118???? ????????System.out.println("Test timed out.");
> 119???????? }
> 120
> ?121???????? if (test.testResult == false) {
> 122???????????? disposeUI();
> 123???????????? throw new RuntimeException("Test Failed.");
> 124???????? }
> Maybe you can call full thing under try-catch-finally
>   try{
> 86???????? for(UIManager.LookAndFeelInfo laf : 
> UIManager.getInstalledLookAndFeels()) {
> .........
> } catch () {
> throw RuntimeException
> } finally {
> disposeUI();
> }
> Regards
> Prasanta
>
> On 9/14/2017 3:43 PM, Shashidhara Veerabhadraiah wrote:
>
>     Hi Prasanta, Here is the updated Webrev.
>
>     http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.03/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.03/>
>
>     Please note that I have not done the 2^nd change(disposeUI() case)
>     as this is required for the time out case where in the testresult
>     had been initialized with false and would call the disposeUI()
>     accordingly.
>
>     Thanks and regards,
>
>     Shashi
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Tuesday, September 12, 2017 11:45 AM
>     *To:* Shashidhara Veerabhadraiah
>     <shashidhara.veerabhadraiah at oracle.com>
>     <mailto:shashidhara.veerabhadraiah at oracle.com>;
>     swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>     *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
>     <mailto:sergey.bylokhov at oracle.com>
>     *Subject:* Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab
>     titles are not clipped with dots at the end.
>
>     Few observations on test:
>
>     init() needs to be called under EDT
>     you are calling disposeUI() in line 233, so it seems there is no
>     need calling again in line122
>
>     Regards
>     Prasanta
>
>     On 9/12/2017 12:54 AM, Sergey Bylokhov wrote:
>
>         Looks fine.
>
>         On 9/11/17 01:34, Shashidhara Veerabhadraiah wrote:
>
>
>             Hi, I have updated the webrev to indicate the removal of a
>             file which is not required anymore owing to the change in
>             test from appletviewer based to standard java execution.
>             This is only for the reference.
>
>             http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.02/
>             <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.02/>
>
>
>             Thanks and regards,
>             Shashi
>
>             -----Original Message-----
>             From: Shashidhara Veerabhadraiah
>             Sent: Monday, September 11, 2017 9:37 AM
>             To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
>             <mailto:sergey.bylokhov at oracle.com>; Prasanta Sadhukhan
>             <prasanta.sadhukhan at oracle.com>
>             <mailto:prasanta.sadhukhan at oracle.com>;
>             swing-dev at openjdk.java.net
>             <mailto:swing-dev at openjdk.java.net>
>             Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The
>             long Tab titles are not clipped with dots at the end.
>
>             Right Sergey. I was not sure on how to represent it under
>             this Webrev. I will update the Webrev if need be.
>
>             Thanks and regards,
>             Shashi
>
>             -----Original Message-----
>             From: Sergey Bylokhov
>             Sent: Saturday, September 9, 2017 7:33 AM
>             To: Shashidhara Veerabhadraiah
>             <shashidhara.veerabhadraiah at oracle.com>
>             <mailto:shashidhara.veerabhadraiah at oracle.com>; Prasanta
>             Sadhukhan <prasanta.sadhukhan at oracle.com>
>             <mailto:prasanta.sadhukhan at oracle.com>;
>             swing-dev at openjdk.java.net
>             <mailto:swing-dev at openjdk.java.net>
>             Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The
>             long Tab titles are not clipped with dots at the end.
>
>             Hi, Shashi.
>             The fix looks fine, but it looks like bug4310381.html
>             should be removed because it is not used?
>
>             On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote:
>
>
>                 Hi All, Please find the updated Webrev at the below link.
>
>                 http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.01/
>                 <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.01/>
>
>
>                 I have added a new test that would go through
>                 different laf's and runs
>                 the test of the tab titles. Previously this test had
>                 been a single
>                 default laf test with appletviewer and now replaced
>                 for multi laf
>                 testing along with the normal java execution. There
>                 are instances of
>                 inaccurate rendering of the titles with respect to the
>                 tab pane
>                 component like clipping, starting offset and going
>                 beyond the tab pane
>                 size as shown below in some of the examples:
>
>                 This requires a different thread to really understand
>                 why this
>                 variation across the multiple laf representation and
>                 needs more proper
>                 bounding the title to fit properly within the tab pane
>                 space. Hence I
>                 will be raising multiple bugs to indicate these
>                 current issues and
>                 will be resolved later. Please note that this issue is
>                 /_not_/ because
>                 of the clipping of the text that these current changes
>                 that are done
>                 under this bug fix.
>
>                 Thanks and regards,
>
>                 Shashi
>
>                 -----Original Message-----
>                 From: Sergey Bylokhov
>                 Sent: Thursday, August 24, 2017 4:24 AM
>                 To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>
>                 <mailto:prasanta.sadhukhan at oracle.com>; Shashidhara
>                 Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
>                 <mailto:shashidhara.veerabhadraiah at oracle.com>;
>                 swing-dev at openjdk.java.net
>                 <mailto:swing-dev at openjdk.java.net>
>                 Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx]
>                 The long Tab
>                 titles are not clipped with dots at the end.
>
>                 I am not sure is it possible to prove, but I think
>                 that we need to
>                 pass tabPane as a component to ClipStrinUfNecessary.
>
>                 On 17.08.2017 3:48, Prasanta Sadhukhan wrote:
>
>                 ? > Fix looks good.
>
>                 ? >
>
>                 ? > But, can you update
>
>                 ? > test/javax/swing/JTabbedPane/4310381/bug4310381.java
>
>                 ? > to include the test for all installed l&fs so that
>                 we can see if
>                 there
>
>                 ? > is problem in any other l&fs?
>
>                 ? >
>
>                 ? > Regards
>
>                 ? > Prasanta
>
>                 ? > On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah
>                 wrote:
>
>                 ? >>
>
>                 ? >> Hi All, Please review a fix for the JDK- 8004029
>                 where the long
>                 tab
>
>                 ? >> titles were not clipped with the dots at the end
>                 to indicate a
>
>                 ? >> lengthy title. The aqua look and feel which is
>                 the default laf for
>
>                 ? >> mac does the title clipping only leading to an
>                 ambiguous UI where
>                 in
>
>                 ? >> the clipped title would look like the
>                 /_complete_/ title though it
>                 is not.
>
>                 ? >> Hence it is good to show dots at the end
>                 indicating a much bigger
>
>                 ? >> title exists though the tab does not have enough
>                 real estate to
>
>                 ? >> display the complete title.
>
>                 ? >>
>
>                 ? >> _Solution and fix:_ I have updated the aqua laf
>                 module to clip the
>
>                 ? >> title text and put the dots at the end if the
>                 text size is larger
>
>                 ? >> than the tab size. Below is the picture /_after_/
>                 the fix.
>
>                 ? >>
>
>                 ? >> Bug:
>                 https://bugs.openjdk.java.net/browse/JDK-8004029
>
>                 ? >>
>
>                 ? >> Webrev:
>
>                 ? >>
>                 http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/
>                 <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>
>
>
>                 ? >>
>                 <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>
>                 <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/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/swing-dev/attachments/20170915/e510adab/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Fri Sep 15 09:46:35 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Fri, 15 Sep 2017 09:46:35 +0000 (UTC)
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <dc9bc33f-a236-61c5-4a91-e944c80a5801@oracle.com>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
 <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
 <82ac9212-d59e-4368-ad4e-89d210bbb204@default>
 <fae37d24-4d62-49c4-b0dd-fcc1df18e64f@default>
 <2cb8f671-4a48-827c-504d-62ba4d9ff7f5@oracle.com>
 <4fd8f3e1-1a16-95bb-c68e-d572bf85a087@oracle.com>
 <cc99b4b6-d1c5-4215-a9dc-34b765a44f8b@default>
 <13af7065-dfa4-3164-dca3-b762d9917dba@oracle.com>
 <613157a7-b4c1-410c-b107-7b0b953df2d1@default>
 <dc9bc33f-a236-61c5-4a91-e944c80a5801@oracle.com>
Message-ID: <9bf86bfa-644c-4667-883b-da779e1e18ad@default>

Hi Prasanta, Please find the updated Webrev @ http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.05/

?

Thanks and regards,

Shashi

?

From: Prasanta Sadhukhan 
Sent: Friday, September 15, 2017 3:11 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net
Cc: Sergey Bylokhov <sergey.bylokhov at oracle.com>
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.

?

looks better. but, disposeUI() do not throw any exception so no need to catch in 

?

try {
 122???????????????? if(test != null) {
 123???????????????????? test.disposeUI();
 124???????????????? }
 125???????????? } catch (Exception ex) {
 126??????????? ?????throw new RuntimeException("Exception while disposing UI");
 127???????????? }
?
Regards
Prasanta

On 9/15/2017 2:57 PM, Shashidhara Veerabhadraiah wrote:

Hi, Here is the updated webrev. Removed unnecessary try catch blocks!!

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.04/"http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.04/

?

Thanks and regards,

Shashi

?

From: Prasanta Sadhukhan 
Sent: Thursday, September 14, 2017 4:26 PM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.

?

One more thing I noticed

106????????????? } catch (Exception e) {
 107?????????????????? throw new RuntimeException(e);
 108????????????? }
 109 
?110???????????? // disposing the frame
 111???????????? SwingUtilities.invokeAndWait(() -> {
 112????????? ???????frame.dispose();
 113???????????? });

if there is any exception thrown as above, then we are not going to dispose. I believe it will be better if we do try-catch-finally and add frame.dispose() in finally block.
Also, I think it should be disposeUI() rather than frame.dispose() as we have already called createUI() by that time so testUI frame is also present.

Also, for 2nd change, I got your point. In that case, I guess you can bring l122-123 inside if (!status)

117???????? if (!status) {
 118???? ????????System.out.println("Test timed out.");
 119???????? }
 120 
?121???????? if (test.testResult == false) {
 122???????????? disposeUI();
 123???????????? throw new RuntimeException("Test Failed.");
 124???????? }
?
Maybe you can call full thing under try-catch-finally
 try{
86???????? for(UIManager.LookAndFeelInfo laf : UIManager.getInstalledLookAndFeels()) {
.........
} catch () {
 throw RuntimeException
} finally {
 disposeUI();
}
?
Regards
Prasanta

On 9/14/2017 3:43 PM, Shashidhara Veerabhadraiah wrote:

Hi Prasanta, Here is the updated Webrev.

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.03/"http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.03/

?

Please note that I have not done the 2nd change(disposeUI() case) as this is required for the time out case where in the testresult had been initialized with false and would call the disposeUI() accordingly.

?

Thanks and regards,

Shashi

?

From: Prasanta Sadhukhan 
Sent: Tuesday, September 12, 2017 11:45 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end.

?

Few observations on test:

init() needs to be called under EDT
you are calling disposeUI() in line 233, so it seems there is no need calling again in line122

Regards
Prasanta

On 9/12/2017 12:54 AM, Sergey Bylokhov wrote:

Looks fine. 

On 9/11/17 01:34, Shashidhara Veerabhadraiah wrote: 





Hi, I have updated the webrev to indicate the removal of a file which is not required anymore owing to the change in test from appletviewer based to standard java execution. This is only for the reference. 

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.02/ 

Thanks and regards, 
Shashi 

-----Original Message----- 
From: Shashidhara Veerabhadraiah 
Sent: Monday, September 11, 2017 9:37 AM 
To: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net 
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end. 

Right Sergey. I was not sure on how to represent it under this Webrev. I will update the Webrev if need be. 

Thanks and regards, 
Shashi 

-----Original Message----- 
From: Sergey Bylokhov 
Sent: Saturday, September 9, 2017 7:33 AM 
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net 
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are not clipped with dots at the end. 

Hi, Shashi. 
The fix looks fine, but it looks like bug4310381.html should be removed because it is not used? 

On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote: 





Hi All, Please find the updated Webrev at the below link. 

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.01/ 

I have added a new test that would go through different laf's and runs 
the test of the tab titles. Previously this test had been a single 
default laf test with appletviewer and now replaced for multi laf 
testing along with the normal java execution. There are instances of 
inaccurate rendering of the titles with respect to the tab pane 
component like clipping, starting offset and going beyond the tab pane 
size as shown below in some of the examples: 

This requires a different thread to really understand why this 
variation across the multiple laf representation and needs more proper 
bounding the title to fit properly within the tab pane space. Hence I 
will be raising multiple bugs to indicate these current issues and 
will be resolved later. Please note that this issue is /_not_/ because 
of the clipping of the text that these current changes that are done 
under this bug fix. 

Thanks and regards, 

Shashi 

-----Original Message----- 
From: Sergey Bylokhov 
Sent: Thursday, August 24, 2017 4:24 AM 
To: Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; Shashidhara 
Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; 
HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net 
Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab 
titles are not clipped with dots at the end. 

I am not sure is it possible to prove, but I think that we need to 
pass tabPane as a component to ClipStrinUfNecessary. 

On 17.08.2017 3:48, Prasanta Sadhukhan wrote: 

? > Fix looks good. 

? > 

? > But, can you update 

? > test/javax/swing/JTabbedPane/4310381/bug4310381.java 

? > to include the test for all installed l&fs so that we can see if 
there 

? > is problem in any other l&fs? 

? > 

? > Regards 

? > Prasanta 

? > On 8/17/2017 2:08 PM, Shashidhara Veerabhadraiah wrote: 

? >> 

? >> Hi All, Please review a fix for the JDK- 8004029 where the long 
tab 

? >> titles were not clipped with the dots at the end to indicate a 

? >> lengthy title. The aqua look and feel which is the default laf for 

? >> mac does the title clipping only leading to an ambiguous UI where 
in 

? >> the clipped title would look like the /_complete_/ title though it 
is not. 

? >> Hence it is good to show dots at the end indicating a much bigger 

? >> title exists though the tab does not have enough real estate to 

? >> display the complete title. 

? >> 

? >> _Solution and fix:_ I have updated the aqua laf module to clip the 

? >> title text and put the dots at the end if the text size is larger 

? >> than the tab size. Below is the picture /_after_/ the fix. 

? >> 

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

? >> 

? >> Webrev: 

? >> HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/"http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/ 

? >> HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/"<http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/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/swing-dev/attachments/20170915/871e5aa6/attachment.html>

From prasanta.sadhukhan at oracle.com  Fri Sep 15 09:51:08 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 15 Sep 2017 15:21:08 +0530
Subject: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab titles are
 not clipped with dots at the end.
In-Reply-To: <9bf86bfa-644c-4667-883b-da779e1e18ad@default>
References: <3ccccbce-74f1-4a91-af5f-1973a1180065@default>
 <5679e543-3769-fcde-61b3-bcfe09c566ba@oracle.com>
 <492d708e-0a27-caab-1df4-65e5ddb6403e@oracle.com>
 <c843a091-d96a-46a8-b528-0fd37b8045f7@default>
 <84389a4c-3814-4c06-8b10-97d323592e83@oracle.com>
 <82ac9212-d59e-4368-ad4e-89d210bbb204@default>
 <fae37d24-4d62-49c4-b0dd-fcc1df18e64f@default>
 <2cb8f671-4a48-827c-504d-62ba4d9ff7f5@oracle.com>
 <4fd8f3e1-1a16-95bb-c68e-d572bf85a087@oracle.com>
 <cc99b4b6-d1c5-4215-a9dc-34b765a44f8b@default>
 <13af7065-dfa4-3164-dca3-b762d9917dba@oracle.com>
 <613157a7-b4c1-410c-b107-7b0b953df2d1@default>
 <dc9bc33f-a236-61c5-4a91-e944c80a5801@oracle.com>
 <9bf86bfa-644c-4667-883b-da779e1e18ad@default>
Message-ID: <c4d6c1c7-9a8b-0b58-eff2-dcb4c795714f@oracle.com>

+1

Regards
Prasanta
On 9/15/2017 3:16 PM, Shashidhara Veerabhadraiah wrote:
>
> Hi Prasanta, Please find the updated Webrev @ 
> http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.05/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.05/>
>
> Thanks and regards,
>
> Shashi
>
> *From:*Prasanta Sadhukhan
> *Sent:* Friday, September 15, 2017 3:11 PM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net
> *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
> *Subject:* Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab 
> titles are not clipped with dots at the end.
>
> looks better. but, disposeUI() do not throw any exception so no need 
> to catch in
>
> try {
> 122???????????????? if(test != null) {
> 123???????????????????? test.disposeUI();
> 124???????????????? }
> 125???????????? } catch (Exception ex) {
> 126??????????? ?????throw new RuntimeException("Exception while 
> disposing UI");
>   127???????????? }
> Regards
> Prasanta
>
> On 9/15/2017 2:57 PM, Shashidhara Veerabhadraiah wrote:
>
>     Hi, Here is the updated webrev. Removed unnecessary try catch blocks!!
>
>     http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.04/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.04/>
>
>     Thanks and regards,
>
>     Shashi
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Thursday, September 14, 2017 4:26 PM
>     *To:* Shashidhara Veerabhadraiah
>     <shashidhara.veerabhadraiah at oracle.com>
>     <mailto:shashidhara.veerabhadraiah at oracle.com>;
>     swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>     *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
>     <mailto:sergey.bylokhov at oracle.com>
>     *Subject:* Re: <Swing Dev> [10] JDK-8004029: [macosx] The long Tab
>     titles are not clipped with dots at the end.
>
>     One more thing I noticed
>
>     106????????????? } catch (Exception e) {
>
>     107?????????????????? throw new RuntimeException(e);
>
>       108????????????? }
>
>     109
>
>     ?110???????????? // disposing the frame
>
>     111???????????? SwingUtilities.invokeAndWait(() -> {
>
>     112????????? ???????frame.dispose();
>
>       113???????????? });
>
>     if there is any exception thrown as above, then we are not going
>     to dispose. I believe it will be better if we do try-catch-finally
>     and add frame.dispose() in finally block.
>     Also, I think it should be disposeUI() rather than frame.dispose()
>     as we have already called createUI() by that time so testUI frame
>     is also present.
>
>     Also, for 2nd change, I got your point. In that case, I guess you
>     can bring l122-123 inside if (!status)
>
>     117???????? if (!status) {
>
>     118???? ????????System.out.println("Test timed out.");
>
>     119???????? }
>
>     120
>
>     ?121???????? if (test.testResult == false) {
>
>     122???????????? disposeUI();
>
>     123???????????? throw new RuntimeException("Test Failed.");
>
>     124???????? }
>
>     Maybe you can call full thing under try-catch-finally
>
>       try{
>
>     86???????? for(UIManager.LookAndFeelInfo laf :
>     UIManager.getInstalledLookAndFeels()) {
>
>     .........
>
>     } catch () {
>
>     throw RuntimeException
>
>     } finally {
>
>     disposeUI();
>
>     }
>
>     Regards
>
>     Prasanta
>
>     On 9/14/2017 3:43 PM, Shashidhara Veerabhadraiah wrote:
>
>         Hi Prasanta, Here is the updated Webrev.
>
>         http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.03/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.03/>
>
>         Please note that I have not done the 2^nd change(disposeUI()
>         case) as this is required for the time out case where in the
>         testresult had been initialized with false and would call the
>         disposeUI() accordingly.
>
>         Thanks and regards,
>
>         Shashi
>
>         *From:*Prasanta Sadhukhan
>         *Sent:* Tuesday, September 12, 2017 11:45 AM
>         *To:* Shashidhara Veerabhadraiah
>         <shashidhara.veerabhadraiah at oracle.com>
>         <mailto:shashidhara.veerabhadraiah at oracle.com>;
>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>         *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
>         <mailto:sergey.bylokhov at oracle.com>
>         *Subject:* Re: <Swing Dev> [10] JDK-8004029: [macosx] The long
>         Tab titles are not clipped with dots at the end.
>
>         Few observations on test:
>
>         init() needs to be called under EDT
>         you are calling disposeUI() in line 233, so it seems there is
>         no need calling again in line122
>
>         Regards
>         Prasanta
>
>         On 9/12/2017 12:54 AM, Sergey Bylokhov wrote:
>
>             Looks fine.
>
>             On 9/11/17 01:34, Shashidhara Veerabhadraiah wrote:
>
>
>
>                 Hi, I have updated the webrev to indicate the removal
>                 of a file which is not required anymore owing to the
>                 change in test from appletviewer based to standard
>                 java execution. This is only for the reference.
>
>                 http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.02/
>                 <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.02/>
>
>
>                 Thanks and regards,
>                 Shashi
>
>                 -----Original Message-----
>                 From: Shashidhara Veerabhadraiah
>                 Sent: Monday, September 11, 2017 9:37 AM
>                 To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
>                 <mailto:sergey.bylokhov at oracle.com>; Prasanta
>                 Sadhukhan <prasanta.sadhukhan at oracle.com>
>                 <mailto:prasanta.sadhukhan at oracle.com>;
>                 swing-dev at openjdk.java.net
>                 <mailto:swing-dev at openjdk.java.net>
>                 Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx]
>                 The long Tab titles are not clipped with dots at the end.
>
>                 Right Sergey. I was not sure on how to represent it
>                 under this Webrev. I will update the Webrev if need be.
>
>                 Thanks and regards,
>                 Shashi
>
>                 -----Original Message-----
>                 From: Sergey Bylokhov
>                 Sent: Saturday, September 9, 2017 7:33 AM
>                 To: Shashidhara Veerabhadraiah
>                 <shashidhara.veerabhadraiah at oracle.com>
>                 <mailto:shashidhara.veerabhadraiah at oracle.com>;
>                 Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>
>                 <mailto:prasanta.sadhukhan at oracle.com>;
>                 swing-dev at openjdk.java.net
>                 <mailto:swing-dev at openjdk.java.net>
>                 Subject: Re: <Swing Dev> [10] JDK-8004029: [macosx]
>                 The long Tab titles are not clipped with dots at the end.
>
>                 Hi, Shashi.
>                 The fix looks fine, but it looks like bug4310381.html
>                 should be removed because it is not used?
>
>                 On 9/4/17 02:33, Shashidhara Veerabhadraiah wrote:
>
>
>
>                     Hi All, Please find the updated Webrev at the
>                     below link.
>
>                     http://cr.openjdk.java.net/~sveerabhadra/8004029/webrev.01/
>                     <http://cr.openjdk.java.net/%7Esveerabhadra/8004029/webrev.01/>
>
>
>                     I have added a new test that would go through
>                     different laf's and runs
>                     the test of the tab titles. Previously this test
>                     had been a single
>                     default laf test with appletviewer and now
>                     replaced for multi laf
>                     testing along with the normal java execution.
>                     There are instances of
>                     inaccurate rendering of the titles with respect to
>                     the tab pane
>                     component like clipping, starting offset and going
>                     beyond the tab pane
>                     size as shown below in some of the examples:
>
>                     This requires a different thread to really
>                     understand why this
>                     variation across the multiple laf representation
>                     and needs more proper
>                     bounding the title to fit properly within the tab
>                     pane space. Hence I
>                     will be raising multiple bugs to indicate these
>                     current issues and
>                     will be resolved later. Please note that this
>                     issue is /_not_/ because
>                     of the clipping of the text that these current
>                     changes that are done
>                     under this bug fix.
>
>                     Thanks and regards,
>
>                     Shashi
>
>                     -----Original Message-----
>                     From: Sergey Bylokhov
>                     Sent: Thursday, August 24, 2017 4:24 AM
>                     To: Prasanta Sadhukhan
>                     <prasanta.sadhukhan at oracle.com>
>                     <mailto:prasanta.sadhukhan at oracle.com>; Shashidhara
>                     Veerabhadraiah
>                     <shashidhara.veerabhadraiah at oracle.com>
>                     <mailto:shashidhara.veerabhadraiah at oracle.com>;
>                     swing-dev at openjdk.java.net
>                     <mailto:swing-dev at openjdk.java.net>
>                     Subject: Re: <Swing Dev> [10] JDK-8004029:
>                     [macosx] The long Tab
>                     titles are not clipped with dots at the end.
>
>                     I am not sure is it possible to prove, but I think
>                     that we need to
>                     pass tabPane as a component to ClipStrinUfNecessary.
>
>                     On 17.08.2017 3:48, Prasanta Sadhukhan wrote:
>
>                     ? > Fix looks good.
>
>                     ? >
>
>                     ? > But, can you update
>
>                     ? >
>                     test/javax/swing/JTabbedPane/4310381/bug4310381.java
>
>                     ? > to include the test for all installed l&fs so
>                     that we can see if
>                     there
>
>                     ? > is problem in any other l&fs?
>
>                     ? >
>
>                     ? > Regards
>
>                     ? > Prasanta
>
>                     ? > On 8/17/2017 2:08 PM, Shashidhara
>                     Veerabhadraiah wrote:
>
>                     ? >>
>
>                     ? >> Hi All, Please review a fix for the JDK-
>                     8004029 where the long
>                     tab
>
>                     ? >> titles were not clipped with the dots at the
>                     end to indicate a
>
>                     ? >> lengthy title. The aqua look and feel which
>                     is the default laf for
>
>                     ? >> mac does the title clipping only leading to
>                     an ambiguous UI where
>                     in
>
>                     ? >> the clipped title would look like the
>                     /_complete_/ title though it
>                     is not.
>
>                     ? >> Hence it is good to show dots at the end
>                     indicating a much bigger
>
>                     ? >> title exists though the tab does not have
>                     enough real estate to
>
>                     ? >> display the complete title.
>
>                     ? >>
>
>                     ? >> _Solution and fix:_ I have updated the aqua
>                     laf module to clip the
>
>                     ? >> title text and put the dots at the end if the
>                     text size is larger
>
>                     ? >> than the tab size. Below is the picture
>                     /_after_/ the fix.
>
>                     ? >>
>
>                     ? >> Bug:
>                     https://bugs.openjdk.java.net/browse/JDK-8004029
>
>                     ? >>
>
>                     ? >> Webrev:
>
>                     ? >>
>                     http://cr.openjdk.java.net/~aghaisas/shashi/8004029/webrev.00/
>                     <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>
>
>
>                     ? >>
>                     <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/webrev.00/>
>                     <http://cr.openjdk.java.net/%7Eaghaisas/shashi/8004029/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/swing-dev/attachments/20170915/9d10db5d/attachment.html>

From philip.race at oracle.com  Fri Sep 15 19:34:58 2017
From: philip.race at oracle.com (Phil Race)
Date: Fri, 15 Sep 2017 12:34:58 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [10] Review Request: 8187399
 Different problems in the javadoc's links in java.desktop package
In-Reply-To: <8d147726-4e2f-b633-29e5-9ffd7c4cfb54@oracle.com>
References: <8d147726-4e2f-b633-29e5-9ffd7c4cfb54@oracle.com>
Message-ID: <9ad3322c-3333-555c-6f53-6321eab1435e@oracle.com>

771      * @implNote Please note that for Mac OS, notifications
  772      * are only sent if the Java app is a bundled application,
  773      * with a {@code CFBundleDocumentTypes} array present in its
774 * Info.plist.


Should we be using {@code ..} for CFBundleDocumentTypes. It is not Java 
code,
but this makes it look like it is.

I think we should have some reference to "go see Apple developer docs" 
to find out what
that and Info.plist are .. even if it not a direct link.

-phil.


On 09/13/2017 03:39 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk10.
>
> Some of the tidy warnings were fixed.
> Report is here:
> http://cr.openjdk.java.net/~jjg/doc-report/jdk-by-module/java.desktop/report.html 
>
>
> Description:
>  - java/awt/Desktop.java: the links to "developer.apple.com" were 
> removed, it seems that the URLs for these documents are changed over 
> time as well as content. We will mention only "CFBundleDocumentTypes" 
> and "Info.plist" in the description.
>  - javax/print/attribute/standard/PresentationDirection.java: the link 
> was changed from ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf
> to ftp://ftp.pwg.org/pub/pwg/standards/temp_archive/pwg5100.3.pdf , 
> but I guess this is a stable location because the files are there from 
> 2004.
>  - others are just broken links which were fixed.
>
> I checked the whole list of links in the desktop module, and found 
> that some of them are broken. For example I cannot find an official 
> place for the tiff specification(and related documents). Also during 
> migration from sun.com we lost some documents, I leave such links 
> as-is, and plan to resurrect the documents somewhere.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187399
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8187399/webrev.00
>
>

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

From javalists at cbfiddle.com  Fri Sep 15 20:05:50 2017
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 15 Sep 2017 13:05:50 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [10] Review Request: 8187399
 Different problems in the javadoc's links in java.desktop package
In-Reply-To: <9ad3322c-3333-555c-6f53-6321eab1435e@oracle.com>
References: <8d147726-4e2f-b633-29e5-9ffd7c4cfb54@oracle.com>
 <9ad3322c-3333-555c-6f53-6321eab1435e@oracle.com>
Message-ID: <4DDE087A-58D8-4E55-8006-E9A8C92007F6@cbfiddle.com>

It?s also not English, which not using @code would make it look like...


> On Sep 15, 2017, at 12:34 PM, Phil Race <philip.race at oracle.com> wrote:
> 
> 771      * @implNote Please note that for Mac OS, notifications
>  772      * are only sent if the Java app is a bundled application,
>  773      * with a {@code CFBundleDocumentTypes} array present in its
>  774      * Info.plist.
> 
> Should we be using {@code ..} for CFBundleDocumentTypes. It is not Java code,
> but this makes it look like it is.
> 



From Sergey.Bylokhov at oracle.com  Sat Sep 16 01:46:48 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Sep 2017 18:46:48 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [10] Review Request: 8187399
 Different problems in the javadoc's links in java.desktop package
In-Reply-To: <9ad3322c-3333-555c-6f53-6321eab1435e@oracle.com>
References: <8d147726-4e2f-b633-29e5-9ffd7c4cfb54@oracle.com>
 <9ad3322c-3333-555c-6f53-6321eab1435e@oracle.com>
Message-ID: <1b9669d9-80e2-bc6c-b693-4b04c479d3d8@oracle.com>

That's of course a stylistic issue, but I think that the keywords(not 
necessary a java) look better when they are highlighted. Depending from 
the style it can look like this:
http://cr.openjdk.java.net/~serb/8187399/img.png

Here is an updated webrev:
http://cr.openjdk.java.net/~serb/8187399/webrev.01
  - The link to the "Apple Developer Documentation" was added.
  - Info.plist is also wrapped in the {@code}
  - Mac OS was replaced by macOS


On 9/15/17 12:34, Phil Race wrote:
> 771      * @implNote Please note that for Mac OS, notifications
>   772      * are only sent if the Java app is a bundled application,
>   773      * with a {@code CFBundleDocumentTypes} array present in its
> 774 * Info.plist.
> 
> 
> Should we be using {@code ..} for CFBundleDocumentTypes. It is not Java 
> code,
> but this makes it look like it is.
> 
> I think we should have some reference to "go see Apple developer docs" 
> to find out what
> that and Info.plist are .. even if it not a direct link.
> 
> -phil.
> 
> 
> On 09/13/2017 03:39 PM, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk10.
>>
>> Some of the tidy warnings were fixed.
>> Report is here:
>> http://cr.openjdk.java.net/~jjg/doc-report/jdk-by-module/java.desktop/report.html 
>>
>>
>> Description:
>> ?- java/awt/Desktop.java: the links to "developer.apple.com" were 
>> removed, it seems that the URLs for these documents are changed over 
>> time as well as content. We will mention only "CFBundleDocumentTypes" 
>> and "Info.plist" in the description.
>> ?- javax/print/attribute/standard/PresentationDirection.java: the link 
>> was changed from ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf
>> to ftp://ftp.pwg.org/pub/pwg/standards/temp_archive/pwg5100.3.pdf , 
>> but I guess this is a stable location because the files are there from 
>> 2004.
>> ?- others are just broken links which were fixed.
>>
>> I checked the whole list of links in the desktop module, and found 
>> that some of them are broken. For example I cannot find an official 
>> place for the tiff specification(and related documents). Also during 
>> migration from sun.com we lost some documents, I leave such links 
>> as-is, and plan to resurrect the documents somewhere.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187399
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8187399/webrev.00
>>
>>
> 


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Mon Sep 18 16:36:16 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 18 Sep 2017 09:36:16 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [10] Review Request 8187367: Numerous
 swing display problems with scaled displays on Windows
Message-ID: <050c5fd4-b051-94a8-1b69-89211fe6882a@oracle.com>

Hello,

Please review fix for JDK10 (in Swing and Java2D):

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

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

Swing apps  may have artifacts on HiDPI screens with fractional scales. 
There are several issues which may cause various artifacts but the 
current fix only eliminates one type of artifacts the vertical and 
horizontal lines on painted surfaces (other issues are addressed by [1] 
and [2]). This issue was introduced after 8073320 and then incorrectly 
fixed in 8163193.

The root cause is the painter pattern is drawn on a wrongly sized and 
scaled image in case the image is an off-screen volatile image. The 
painter doesn't take into account the volatile image inner scale 
transformation which is not an identity in case of HiDPI , so the 
resulting image is drawn on of off-screen surface that in the scale 
times bigger than it is actually necessary. Since such images are cached 
this was waste of RAM. Also, the bounds sent to the painter class don't 
take into account the transformation rounding error the latter caused 
artifacts on the drawing edges.

--Semyon

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

[2] https://bugs.openjdk.java.net/browse/JDK-8187586



From Sergey.Bylokhov at oracle.com  Mon Sep 18 19:01:05 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Sep 2017 12:01:05 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [10] Review Request 8187367:
 Numerous swing display problems with scaled displays on Windows
In-Reply-To: <050c5fd4-b051-94a8-1b69-89211fe6882a@oracle.com>
References: <050c5fd4-b051-94a8-1b69-89211fe6882a@oracle.com>
Message-ID: <844da46f-a57e-c639-fbaf-5a55ceaaf777@oracle.com>

Hi, Semyon.
Is it possible to write a test case for this issue? It will be helpful 
to understand the bug and a fix.

On 9/18/17 09:36, Semyon Sadetsky wrote:
> Hello,
> 
> Please review fix for JDK10 (in Swing and Java2D):
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8187367
> 
> webrev: http://cr.openjdk.java.net/~ssadetsky/8187367/webrev.00/
> 
> Swing apps? may have artifacts on HiDPI screens with fractional scales. 
> There are several issues which may cause various artifacts but the 
> current fix only eliminates one type of artifacts the vertical and 
> horizontal lines on painted surfaces (other issues are addressed by [1] 
> and [2]). This issue was introduced after 8073320 and then incorrectly 
> fixed in 8163193.
> 
> The root cause is the painter pattern is drawn on a wrongly sized and 
> scaled image in case the image is an off-screen volatile image. The 
> painter doesn't take into account the volatile image inner scale 
> transformation which is not an identity in case of HiDPI , so the 
> resulting image is drawn on of off-screen surface that in the scale 
> times bigger than it is actually necessary. Since such images are cached 
> this was waste of RAM. Also, the bounds sent to the painter class don't 
> take into account the transformation rounding error the latter caused 
> artifacts on the drawing edges.
> 
> --Semyon
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8187585
> 
> [2] https://bugs.openjdk.java.net/browse/JDK-8187586
> 


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Tue Sep 19 14:58:44 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Sep 2017 07:58:44 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [10] Review Request 8187367:
 Numerous swing display problems with scaled displays on Windows
In-Reply-To: <844da46f-a57e-c639-fbaf-5a55ceaaf777@oracle.com>
References: <050c5fd4-b051-94a8-1b69-89211fe6882a@oracle.com>
 <844da46f-a57e-c639-fbaf-5a55ceaaf777@oracle.com>
Message-ID: <170b93d2-abae-1080-2eae-9d0e5c07dcf1@oracle.com>

On 09/18/2017 12:01 PM, Sergey Bylokhov wrote:
> Hi, Semyon.
> Is it possible to write a test case for this issue? It will be helpful 
> to understand the bug and a fix.

Writing the test is hard because those inner interfaces are  too deep 
inside. You can use SwingSet2 demo to see the described artifacts at 
fractional scales before the fix.

>
> On 9/18/17 09:36, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK10 (in Swing and Java2D):
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8187367
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8187367/webrev.00/
>>
>> Swing apps  may have artifacts on HiDPI screens with fractional 
>> scales. There are several issues which may cause various artifacts 
>> but the current fix only eliminates one type of artifacts the 
>> vertical and horizontal lines on painted surfaces (other issues are 
>> addressed by [1] and [2]). This issue was introduced after 8073320 
>> and then incorrectly fixed in 8163193.
>>
>> The root cause is the painter pattern is drawn on a wrongly sized and 
>> scaled image in case the image is an off-screen volatile image. The 
>> painter doesn't take into account the volatile image inner scale 
>> transformation which is not an identity in case of HiDPI , so the 
>> resulting image is drawn on of off-screen surface that in the scale 
>> times bigger than it is actually necessary. Since such images are 
>> cached this was waste of RAM. Also, the bounds sent to the painter 
>> class don't take into account the transformation rounding error the 
>> latter caused artifacts on the drawing edges.
>>
>> --Semyon
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8187585
>>
>> [2] https://bugs.openjdk.java.net/browse/JDK-8187586
>>
>
>



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: <Swing Dev> <AWT 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 semyon.sadetsky at oracle.com  Thu Sep 21 03:11:11 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 20 Sep 2017 20:11:11 -0700
Subject: <Swing Dev> [10] Review request for 8187599: Remove dependency of
 Building Nimbus L&F on JAXB
Message-ID: <85c5735a-4f64-71e9-d930-03d766e5c9b6@oracle.com>

Hello,

Please review fix for JDK10:

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

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

External JAXB was replaced by StAX parser in Nimbus L&F classes generation.

--Semyon




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: <Swing Dev> <AWT 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 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: <Swing Dev> <AWT 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 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: <Swing Dev> <AWT 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 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: <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:21:39 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Sep 2017 20:21:39 -0700
Subject: <Swing Dev> <AWT 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 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: <Swing Dev> <AWT 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 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: <Swing Dev> <AWT 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: <Swing Dev> <AWT 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: <Swing Dev> <AWT 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: <Swing Dev> <AWT 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: <Swing Dev> <AWT 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/swing-dev/attachments/20170922/17946139/attachment.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: <Swing Dev> <AWT 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/swing-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: <Swing Dev> <AWT 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/swing-dev/attachments/20170922/e5de16dd/attachment.html>

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: <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 Sergey.Bylokhov at oracle.com  Mon Sep 25 17:14:24 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 Sep 2017 10:14:24 -0700
Subject: <Swing Dev> [10] Review request for 8187599: Remove dependency
 of Building Nimbus L&F on JAXB
In-Reply-To: <85c5735a-4f64-71e9-d930-03d766e5c9b6@oracle.com>
References: <85c5735a-4f64-71e9-d930-03d766e5c9b6@oracle.com>
Message-ID: <a5cff0d6-24c1-1ec8-bd60-154f44c3bdd1@oracle.com>

Hi, Semyon.
It seems that this change breaks the build, because it added a new 
non-default constructor to SynthModel.

open/make/jdk/src/classes/build/tools/generatenimbus/ObjectFactory.java:60: 
error: constructor SynthModel in class SynthModel cannot be applied to 
given types;
         return new SynthModel();
                ^
   required: XMLStreamReader
   found: no arguments

On 9/20/17 20:11, Semyon Sadetsky wrote:
> Hello,
> 
> Please review fix for JDK10:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8187599
> 
> webrev: http://cr.openjdk.java.net/~ssadetsky/8187599/webrev.00/
> 
> External JAXB was replaced by StAX parser in Nimbus L&F classes generation.
> 
> --Semyon
> 
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Mon Sep 25 17:26:56 2017
From: philip.race at oracle.com (Phil Race)
Date: Mon, 25 Sep 2017 10:26:56 -0700
Subject: <Swing Dev> [10] Review request for 8187599: Remove dependency
 of Building Nimbus L&F on JAXB
In-Reply-To: <a5cff0d6-24c1-1ec8-bd60-154f44c3bdd1@oracle.com>
References: <85c5735a-4f64-71e9-d930-03d766e5c9b6@oracle.com>
 <a5cff0d6-24c1-1ec8-bd60-154f44c3bdd1@oracle.com>
Message-ID: <f74e7868-5a22-35df-c104-919586611344@oracle.com>

This change is also huge. How did you do this ? Manually ?
There should be diffs of the files generated this way and the files 
generated by JAXB
so we can compare. Ideally they'd be byte-for-byte identical but failing 
that it should
be trivial to see that any diffs are insignificant.

-phil.

On 09/25/2017 10:14 AM, Sergey Bylokhov wrote:
> Hi, Semyon.
> It seems that this change breaks the build, because it added a new 
> non-default constructor to SynthModel.
>
> open/make/jdk/src/classes/build/tools/generatenimbus/ObjectFactory.java:60: 
> error: constructor SynthModel in class SynthModel cannot be applied to 
> given types;
>         return new SynthModel();
>                ^
>   required: XMLStreamReader
>   found: no arguments
>
> On 9/20/17 20:11, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK10:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8187599
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8187599/webrev.00/
>>
>> External JAXB was replaced by StAX parser in Nimbus L&F classes 
>> generation.
>>
>> --Semyon
>>
>>
>
>



From semyon.sadetsky at oracle.com  Mon Sep 25 17:34:49 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 25 Sep 2017 10:34:49 -0700
Subject: <Swing Dev> [10] Review request for 8187599: Remove dependency
 of Building Nimbus L&F on JAXB
In-Reply-To: <a5cff0d6-24c1-1ec8-bd60-154f44c3bdd1@oracle.com>
References: <85c5735a-4f64-71e9-d930-03d766e5c9b6@oracle.com>
 <a5cff0d6-24c1-1ec8-bd60-154f44c3bdd1@oracle.com>
Message-ID: <02cb5dfa-44f7-b9ee-e334-6c5085bcdc7e@oracle.com>

On 09/25/2017 10:14 AM, Sergey Bylokhov wrote:

> Hi, Semyon.
> It seems that this change breaks the build, because it added a new 
> non-default constructor to SynthModel.
>
> open/make/jdk/src/classes/build/tools/generatenimbus/ObjectFactory.java:60: 
> error: constructor SynthModel in class SynthModel cannot be applied to 
> given types;
>         return new SynthModel();
>                ^
>   required: XMLStreamReader
>   found: no arguments
ObjectFactory.java was missed from the webrev. It should be deleted 
actually.
The updated webrev: http://cr.openjdk.java.net/~ssadetsky/8187599/webrev.01/

>
> On 9/20/17 20:11, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK10:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8187599
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8187599/webrev.00/
>>
>> External JAXB was replaced by StAX parser in Nimbus L&F classes 
>> generation.
>>
>> --Semyon
>>
>>
>
>



From semyon.sadetsky at oracle.com  Mon Sep 25 17:36:18 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 25 Sep 2017 10:36:18 -0700
Subject: <Swing Dev> [10] Review request for 8187599: Remove dependency
 of Building Nimbus L&F on JAXB
In-Reply-To: <f74e7868-5a22-35df-c104-919586611344@oracle.com>
References: <85c5735a-4f64-71e9-d930-03d766e5c9b6@oracle.com>
 <a5cff0d6-24c1-1ec8-bd60-154f44c3bdd1@oracle.com>
 <f74e7868-5a22-35df-c104-919586611344@oracle.com>
Message-ID: <205dc5cf-412b-d4c4-4f34-b435c55d7744@oracle.com>

On 09/25/2017 10:26 AM, Phil Race wrote:

> This change is also huge. How did you do this ? Manually ?
Yes, manually.
> There should be diffs of the files generated this way and the files 
> generated by JAXB
> so we can compare. Ideally they'd be byte-for-byte identical but 
> failing that it should
> be trivial to see that any diffs are insignificant.
I did the diff. All files files are byte-for-byte identical.

--Semyon
>
> -phil.
>
> On 09/25/2017 10:14 AM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>> It seems that this change breaks the build, because it added a new 
>> non-default constructor to SynthModel.
>>
>> open/make/jdk/src/classes/build/tools/generatenimbus/ObjectFactory.java:60: 
>> error: constructor SynthModel in class SynthModel cannot be applied 
>> to given types;
>>         return new SynthModel();
>>                ^
>>   required: XMLStreamReader
>>   found: no arguments
>>
>> On 9/20/17 20:11, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK10:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8187599
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8187599/webrev.00/
>>>
>>> External JAXB was replaced by StAX parser in Nimbus L&F classes 
>>> generation.
>>>
>>> --Semyon
>>>
>>>
>>
>>
>



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: <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 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: <Swing Dev> <AWT 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 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: <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 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: <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 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: <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: <Swing Dev> <AWT 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/swing-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: <Swing Dev> <AWT 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/swing-dev/attachments/20170926/d44ed4a3/attachment.html>

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: <Swing Dev> <AWT 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 pankaj.b.bansal at oracle.com  Wed Sep 27 06:17:02 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 26 Sep 2017 23:17:02 -0700 (PDT)
Subject: <Swing Dev> [10] Review Request: JDK-6463710 :
 ListSelectionModel.setSelectionMode() underspecified
Message-ID: <f6a06e0c-9179-496b-af27-7fdbca9e0e3b@default>

Hi All,

 

Please review the fix for JDK 10.

 

Bug:

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

 

Webrev:

http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.00/

 

Issue:

ListSelectionModel.setSelectionMode() or JList.setSelectionMode() does not change the selection and leaves the selection in inconsistent state. This bug will affect the JList and JTable as they both use ListSelectionModel. The JTree uses it indirectly through TreeSelectionModel which handles it.

 

Fix:

Made changes in ListSelectionModel to check if the selectionMode has changed and if yes, clear the selection. 

Made changes in JList to make it consistent with JTable.

Added a test program to test the functionality for ListSelectionModel.setSelectionMode()

 

 

Regards,

Pankaj Bansal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170926/6042f6f8/attachment.html>

From semyon.sadetsky at oracle.com  Wed Sep 27 16:55:00 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 27 Sep 2017 09:55:00 -0700
Subject: <Swing Dev> [10] Review Request: JDK-6463710 :
 ListSelectionModel.setSelectionMode() underspecified
In-Reply-To: <f6a06e0c-9179-496b-af27-7fdbca9e0e3b@default>
References: <f6a06e0c-9179-496b-af27-7fdbca9e0e3b@default>
Message-ID: <bad99347-55de-2135-08ee-7d4c3b7def02@oracle.com>

Hi Pankaj,

Clearing current selection each time the selection mode is changed could 
be a good solution for the issue but this may cause compatibility 
problems in existing applications.

I'd suggest you try to preserve the consistent part of the current 
selection, at least the topmost single row.

--Semyon


On 09/26/2017 11:17 PM, Pankaj Bansal wrote:
>
> Hi All,
>
> Please review the fix for JDK 10.
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-6463710
>
> Webrev:
>
> http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eaghaisas/pankaj/6463710/webrev.00/>
>
> Issue:
>
> ListSelectionModel.setSelectionMode() or JList.setSelectionMode() does 
> not change the selection and leaves the selection in inconsistent 
> state. This bug will affect the JList and JTable as they both use 
> ListSelectionModel. The JTree uses it indirectly through 
> TreeSelectionModel which handles it.
>
> Fix:
>
> Made changes in ListSelectionModel to check if the selectionMode has 
> changed and if yes, clear the selection.
>
> Made changes in JList to make it consistent with JTable.
>
> Added a test program to test the functionality for 
> ListSelectionModel.setSelectionMode()
>
> Regards,
>
> Pankaj Bansal
>

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

From Sergey.Bylokhov at oracle.com  Wed Sep 27 18:21:13 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Sep 2017 11:21:13 -0700
Subject: <Swing Dev> [10] Review request for 8187599: Remove dependency
 of Building Nimbus L&F on JAXB
In-Reply-To: <02cb5dfa-44f7-b9ee-e334-6c5085bcdc7e@oracle.com>
References: <85c5735a-4f64-71e9-d930-03d766e5c9b6@oracle.com>
 <a5cff0d6-24c1-1ec8-bd60-154f44c3bdd1@oracle.com>
 <02cb5dfa-44f7-b9ee-e334-6c5085bcdc7e@oracle.com>
Message-ID: <7c7cbb01-a99d-2c0e-49eb-2ef748fda853@oracle.com>

On 9/25/17 10:34, Semyon Sadetsky wrote:
> ObjectFactory.java was missed from the webrev. It should be deleted 
> actually.
> The updated webrev: 
> http://cr.openjdk.java.net/~ssadetsky/8187599/webrev.01/

Looks fine.


-- 
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: <Swing Dev> <AWT 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 pankaj.b.bansal at oracle.com  Thu Sep 28 11:57:03 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 28 Sep 2017 04:57:03 -0700 (PDT)
Subject: <Swing Dev> [10] Review Request: JDK-6463710 :
 ListSelectionModel.setSelectionMode() underspecified
In-Reply-To: <bad99347-55de-2135-08ee-7d4c3b7def02@oracle.com>
References: <f6a06e0c-9179-496b-af27-7fdbca9e0e3b@default>
 <bad99347-55de-2135-08ee-7d4c3b7def02@oracle.com>
Message-ID: <e09c6ee8-3da7-4b29-8ca6-db167eb7d973@default>

Hi,

 

I have updated the webrev for the review comments. Now I have preserved the consistent part for the selection depending upon old and new selectionMode. Please review.

 

webrev:

http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.01/

 

Regards,

Pankaj Bansal

 

From: Semyon Sadetsky 
Sent: Wednesday, September 27, 2017 10:25 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10] Review Request: JDK-6463710 : ListSelectionModel.setSelectionMode() underspecified

 

Hi Pankaj,

Clearing current selection each time the selection mode is changed could be a good solution for the issue but this may cause compatibility problems in existing applications.

I'd suggest you try to preserve the consistent part of the current selection, at least the topmost single row.

--Semyon

 

On 09/26/2017 11:17 PM, Pankaj Bansal wrote:

Hi All,

 

Please review the fix for JDK 10.

 

Bug:

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

 

Webrev:

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

 

Issue:

ListSelectionModel.setSelectionMode() or JList.setSelectionMode() does not change the selection and leaves the selection in inconsistent state. This bug will affect the JList and JTable as they both use ListSelectionModel. The JTree uses it indirectly through TreeSelectionModel which handles it.

 

Fix:

Made changes in ListSelectionModel to check if the selectionMode has changed and if yes, clear the selection. 

Made changes in JList to make it consistent with JTable.

Added a test program to test the functionality for ListSelectionModel.setSelectionMode()

 

 

Regards,

Pankaj Bansal

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170928/840d3b0a/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: <Swing Dev> <AWT 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/swing-dev/attachments/20170928/1ae71498/attachment.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: <Swing Dev> <AWT 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/swing-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: <Swing Dev> <AWT 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/swing-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: <Swing Dev> <AWT 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/swing-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: <Swing Dev> <AWT 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: <Swing Dev> <AWT 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/swing-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: <Swing Dev> <AWT 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/swing-dev/attachments/20170928/09630f99/attachment.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: <Swing Dev> <AWT 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: <Swing Dev> <AWT 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/swing-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: <Swing Dev> <AWT 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/swing-dev/attachments/20170929/4fa7d856/attachment.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: <Swing Dev> <AWT 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: <Swing Dev> <AWT 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/swing-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: <Swing Dev> <AWT 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: <Swing Dev> <AWT 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: <Swing Dev> <AWT 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.



From brian.burkhalter at oracle.com  Fri Sep 15 19:43:30 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 15 Sep 2017 19:43:30 -0000
Subject: <Swing Dev> [OpenJDK 2D-Dev] [10] Review Request: 8187399
	Different problems in the javadoc's links in java.desktop package
In-Reply-To: <9ad3322c-3333-555c-6f53-6321eab1435e@oracle.com>
References: <8d147726-4e2f-b633-29e5-9ffd7c4cfb54@oracle.com>
 <9ad3322c-3333-555c-6f53-6321eab1435e@oracle.com>
Message-ID: <B589BD5B-36A2-45B0-A5F6-096AFCE34231@oracle.com>

To be truly picky, the current moniker for ?Apple Unix? is ?macOS? [1].

Brian

[1] https://en.wikipedia.org/wiki/MacOS

On Sep 15, 2017, at 12:34 PM, Phil Race <philip.race at oracle.com> wrote:

> 771      * @implNote Please note that for Mac OS, notifications
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170915/4bdbb22d/attachment.html>