Hi Semyon,
On 22/09/2017 20:06, Semyon Sadetsky wrote:
Hi Alexey,
On 09/22/2017 10:53 AM, Alexey Ivanov wrote:
Hi Semyon,
On 22/09/2017 18:29, Semyon Sadetsky wrote:
Hi Alexey,
On 09/22/2017 09:43 AM, Alexey Ivanov wrote:
Hi Semyon,
On 22/09/2017 17:13, Semyon Sadetsky wrote:
Hi Alexey,
Thank you for your exact clarification.
On 09/22/2017 04:22 AM, Alexey Ivanov wrote:
<SNIP>
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.
Swing UI scales to accommodate HiDPI settings. If fonts are larger
then icons should be larger too. Otherwise icons are too small
compared to surrounding text.
Anyway it could be postponed to a later fix.
Does it make sense to declare the standard sizes of 16×16 and 32×32
as constants at least in Java sources? This way, it would be easier
to find the places in code where a change is necessary.
This topic requires more investigations. At first, we need to keep
the API cross-platform and this requires comparing all supported
platforms in details. At the second, even for the existing windows
implementation there is an ambiguity in icons sizes received form
the OS shell. Windows platform has number of predefined constants to
query icon sizes (small, large, extra large, jumbo...) but their
actual size may differ depending on the shell preferences.
Those icon sizes may be changed by Windows registry settings and may
depend on the hi-res scale. I did several experiments and found that
depending on the way of desktop scaling in Windows 10 (it has two
ways the new one and the old) at the same scale 2x the returned
large icon, for example, may be 32 or 64 pixels in size (this was
the root cause of the 8151385 bug).
I would postpone digging in this direction because we are not
planning to update Swing JFC dialog for better HiDPI view in the
nearest future. Also,we don't have statistics how users may use the
API. Since that, the most flexible API that leaves to the user the
decision about icon size to query seems more preferable.
I totally agree with your points. And the new API provides means for
app developer to choose better-suited size for icons.
What about using constants, private ones, for the two standard sizes
instead of using “magic” numbers?
Which constants do you mean? The next for large and small sizes?
public static final int FILE_ICON_SMALL = -1;
public static final int FILE_ICON_LARGE = -2;
they cannot be private because they are part of the new API that is
requested in the bug. The bug asks enabling the query for the large
icon that ShellFolder had been providing before. The bug itself is not
related to HiDPI. The possibility to get arbitrary icon sizes was
added because after 9 this may be in demand for HiDPI UIs.
I'm talking about these two numbers in Win32ShellFolder2.java as an example:
public Image getIcon(final boolean getLargeIcon) {
int size = getLargeIcon ? *32* : *16*;
Does it make sense to declare constants for the size of 16 and 32. So
that the places where they're used are more easily identified if someone
decides to update the code later for supporting system icon size.
Regards,
Alexey
--Semyon
Other than that, the fix looks good to me.
Regards,
Alexey
--Semyon
Regards,
Alexey
--Semyon
Regards,
Alexey
<SNIP>
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