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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Fri Sep 22 03:21:39 UTC 2017


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.


More information about the awt-dev mailing list