<Swing Dev> <AWT Dev> [10] Review request for 8182043: Access to Windows Large Icons

[Sergey Bylokhov]

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.