RFR: 8299522: JFilechooser open button size is incorrectly shown [v2]

[Tejesh R]

On Tue, 10 Jan 2023 05:18:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

> > Yeah, initially had thought of doing this, but to keep the default text open for future changes and to maintain the default for CUSTOM Type separately I added additional properties and members. If using the OPEN type properties is fine for CUSTOM also then can use the same I guess.
> 
> It seems fine to me. It's the behaviour if you use the `showDialog` method which shows the same dialog as `showOpenDialog`.
> 
> However, Aqua L&F does use special properties, which are used only in the case where the file chooser is embedded in UI hierarchy as opposed to using the `show*Dialog` methods to display a modal dialog box.
> 
> > > If you prefer going this route and add new properties, I suggest following what's used in Aqua L&F that is `choose-` prefix for the properties and member names
> > 
> > 
> > Yeah, sure can change the prefix. Along with the approve button text?
> 
> Since the type is `CUSTOM_DIALOG`, using `custom-` prefix that you use is actually better as it makes the naming consistent.
> 
> However, I'm still inclined to closing this bug as _Not an Issue_ because you, as the developer, have to explicitly set the text for the Approve button if you use the customer dialog — it's _custom_ after all.

Then instead of adding new properties and members let me do as you suggested, to use OPEN type so that the size issue will be handled, and no new properties/members will be introduced. Fine right?

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

PR: https://git.openjdk.org/jdk/pull/11901