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
