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

[Semyon Sadetsky]

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