<Swing Dev> RFR: 8182043: Access to Windows Large Icons [v12]

[Phil Race]

On Fri, 21 May 2021 21:41:44 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chenged implementation specification based on CSR review

> > if the aspect ratio is consistent as I expect is typical we should support that
> 
> Ok, i see your point. I can do that for sure, it is just a change of API for now, no implementation will be affected since Windows does not support non-square icons for files and passage about exact size can not be guaranteed will save us from "i requested 128x20 and you returned 128x128" complaints. One will get what platform is able to serve. However, i do not see why we should limit the maximum requested size.

Did I say that?  I think I said something more like the opposite.

The spec you wrote seems to suggest that if the user exceeds some unknown size that you aren't telling them,
you'll return null, leaving them in a guessing game as to what is the maximum.
That can't be right.
So either you provide another API telling them the maximum size, or, if they exceed the maximum size
you specify that the API will return the best fit, just like in other cases.

The question I raised was around what "size" means. If you meant the API to return the size to
which the image will *scale* when drawn, you need to make this very clear to the developer,
or since you don't have an API telling them the max available, they'll respond by asking for ridiculous sizes
to get the best quality image. 

So what do you intend ?



> 
> > I can't agree that IAE is wrong for a negative size.
> 
> How about non-existing file or file? Also IAE?

First .. "inaccessible" should not be distinguishable from "non-existing".
If I ask for a file that the system has hidden from me for whatever reason.
Now since this is something where the app may not know that for platform reasons,
I think a file that cannot be "found" should not throw IAE, just return null.

Passing in null directly tho' probably *should* be IAE because what are they doing that for ??

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 280:

> 278:     * @param size width and height of the icon in user coordinate system.
> 279:     * This API only supports square icons with the edge length
> 280:     * equals or greater than 1. Maximum size allowed is defined by the

I think this is a weird way to say size >=1.

We should throw IAE for <=0 .

I also think we need to allow for rectangular icons,  not bake it in to the spec in such strong terms that we don't.
I suppose  it could be revised if a platform that needs it comes along but  ...

Still not sure about failing if you exceed the maximum size.

Why ? Why not just return the largest possible - it is the same thing as other cases, we'll return the best match.

If that is what you already mean, then say it more clearly.

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 284:

> 282:     * @return an icon as it would be displayed by a native file chooser
> 283:     * or null if invalid parameters are passed such as pointer to a
> 284:     * non-existing file or a size outside of supported range.

pointer -> reference

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875