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

[Alexey Ivanov]

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