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.
