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