On Tue, 10 Oct 2023 20:00:10 GMT, Phil Race <[email protected]> wrote:
>> Invoking `setEnabled(false)` on an instance of `JFileChooser` the
>> sub-components are unaffected since the sub-components didn't set/unset
>> enabled explicitly. The fix address the issue and sets the Enabled flag to
>> each sub-components. Along with setting the property to each sub components,
>> the action listeners like mouseClick(Double too) and scroll actions has to
>> be processed based on enabled/disabled property similar to other components.
>> Since `JFilechooser` implementation varies based on LookAndFeel, the same
>> had to be taken care for affected LookAndFeel also.
>> Note: `JFrame` being top level container handles frame disable using native
>> method which couldn't be the case for `JFileChooser`. For
>> `showDialog/showOpenDialog/showSaveDialog` the fix could be to set the one
>> the enabled property for created single Dialog. But when an instance of
>> `JFileChooser` is created and added to Frame (Without Dialog been created),
>> disabling the `FileChooser` alone had to be done by handling each
>> sub-components and listeners separately.
>
> src/java.desktop/share/classes/javax/swing/JFileChooser.java line 2082:
>
>> 2080: }
>> 2081:
>> 2082: @Override
>
> No javadoc .. are you hoping to get away without a CSR ?
> I think a CSR would be a good idea anyway because after 25 years of Swing
> ignoring this
> on a JFileChooser, you are going to support it. And if an app had set it and
> not realised then
> it'll see a change.
> So I'm not going to suggest javadoc but I am going to suggest a PR for
> compatibility concerns.
> Then there's always the option to back it out if there's an issue.
Sure, will raise a CSR for that.
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java
> line 374:
>
>> 372: viewMenuButton.addMouseListener(new MouseAdapter() {
>> 373: public void mousePressed(MouseEvent e) {
>> 374: if(!getFileChooser().isEnabled()) {
>
> if (
>
> And since you aren't explicit about it, can you say what is the user
> experience of the native filechooser widget that's used .. isn't it still
> active ? Can you really disable it by ignoring these events ?
<img width="375" alt="FileChooserDiabled"
src="https://github.com/openjdk/jdk/assets/94159358/62539c06-a328-448a-aa3e-49fb0edb2ccc";>
This is how Filechooser looks when we disable every components by setting the
state iteratively as done in JFileChooser class (Ignore the button at bottom,
its for testing enable and disable state). Yet the event handling of filePane
like mouse double click event, scroll event, pop-up events can still catch-up
the events and process them (Couldn't find an option to disable whole filePane
though). So ignoring these events along with disabled Look of UI seems to be a
better option. So in short, when we disable FileChooser, all other individual
components are inactive expect FilePane which looks inactive but processes some
events which are ignored further.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16068#discussion_r1354038983
PR Review Comment: https://git.openjdk.org/jdk/pull/16068#discussion_r1354037736
