On 3/30/20 5:02 pm, Alexander Zuev wrote:
- Why we need a new class for only one method, why we cannot enhance the
FileSystemView
where the similar method is implemented already getSystemIcon(File)?
As you know this is not the first attempt to fix this issue and when i asked about
"Why do we need
a separate class for one new method" the answer was "There is a reason, we
tried different approaches
and this one is what we ended up with". Exact reason buried somewhere in the
previous reviews.
Personally for me i would prefer adding the new method to some existing public
class.
Here's the link to the latest bit of the discussion that i found and there was
exactly the same question
raised by Alexey Ivanov, there are some reasons for creating a separate class:
http://mail.openjdk.java.net/pipermail/awt-dev/2019-January/014941.html
If that the only reason, when I think we can get rid it.
- Can we try to re-implement the places where the old method
ShellFolder.getIcon(boolean)
was used, and change it to use the new public API, just to confirm that our
new code is a
a good replacement of the old/private api. I guess we could get rid the
boolean version.
It is outside of the initial scope of the request but yes - i can do it. Should
i do it within this fix or
should i create a new bug and do it there?
Such change will show how well the new API can be used instead of
getIcon(boolean),
this one of the things the bug reporter wanted to achieve.
- The current spec for SystemIcon.getSystemIcon() specify that the icon will
store the
"maximum quality icon" what does it meant?
It means that the maximum size of the icon allowed by the system will be used.
Right now on
Windows (and this issue is Windows specific) the maximum icon size allowed is
256x256 pixels.
That is the size we will request and store in the MultiResolutionImageIcon.
I guess for the most system icons the size 256 is a maximum size, does it mean
we
always will use it? Even if the requested size is 16x16? I guess that on the
HiDPI
screen if the requested size is 16x16 we should use the resolution of size
32x32, not 256x256.
Probably the text should be rephrased.
- Another question is about multi-screen environment, if the JFileChooser will
be shown
on the non-HiDPI screen and then moved to the HiDPI screen which icons we
will request
from the native and which actual icons(resolution) will we draw on each
screen?(both types
of icons large/small are interesting).
Right now Swing is handling scaling and with my limited testing capability (i
don't have access to
the different multi-monitor configurations for obvious reasons) i don't see any
problem. Both
small and large sized icons got scaled together with the scaling factor change,
obviously
quality of icons with size 32 and up is much better since they all are
downscale of the 256x256
icon and both 16x16 and 24x24 icons are pretty pixelated with scaling factor
200% and up,
but that was a trade off for allowing of the custom small icons to be used
where available.
The similar(but not exactly the same) scenario is changing DPI on the fly while
the JFileChooser
is visible on the screen. In that case the JFileChooser should be redrawn and
correct resolution
variant should be used. For example if the file has the icons of size 32x32 and
64x64, but
does not contain the icon 48x48:
- Scale factor is 1.0: JFileChooser requests the "large" icon of size 32x32,
when this icon is
painted on the JFileChooser the 32x32 resolution should
be used.
- Scale factor is 2.0: JFileChooser requests the "large" icon of size 32x32,
when this icon is
painted on the JFileChooser the 64x64 resolution should
be used.
- Scale factor is 1.5: JFileChooser requests the "large" icon of size 32x32,
when this icon is
painted on the JFileChooser we(or the native code) should
upscale the 32x32
resolution or downscale 64x64 icon to the size 48x48.
- The Scale factor dynamically changed from 1to2/2to1: JFileChooser requests the
"large" icon
of size 32x32, when this icon is painted on the
JFileChooser the 32x32 or 64x64
resolution should be used depending from the current
scale.
--
Best regards, Sergey.
