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

Semyon Sadetsky semyon.sadetsky at oracle.com
Fri Sep 22 16:13:18 UTC 2017


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



More information about the awt-dev mailing list