Missing label in file chooser

[Chrriis]

It seems the labels for the 2 bottom fields are missing. It is confusing.

Here, for a folder file chooser, I have "Folder name:" and "Files of type:" labels on Windows:

But I get empty labels in FlatLaf:

[DevCharly]

Strange. The labels are there when running on Java 8, but not when running on Java 9 or later...

[Chrriis]

FlatFileChooserUI extends MetalFileChooserUI. In MetalFileChooserUI, resources are read from UIManager with keys like "FileChooser.lookInLabelText", "FileChooser.filesOfTypeLabelText". Where are these defined in FlatLaf?

[Chrriis]

OK, I understand the problem:

• FlatFileChooserUI extends MetalFileChooserUI.
• FlatLaf extends BasicLookAndFeel.

So, the "[java.desktop]/com/sun/swing/internal/plaf/metal/resources/metal*" resource bundle is not loaded. Several keys needed by MetalFileChooserUI are missing.

Unless I am mistaken, resource bundles are loaded using "UIDefaults.addInternalBundle(bundleName);" which is tagged "@since 9". So maybe, this is why it does not work anymore?

I guess that using a MetalXxxUI is risky if the look and feel does not extend MetalLookAndFeel. Otherwise code may break for changes in keys between Java versions.

[dpatriarche]

For the reasons described by Chrriis above, if you switch to the "details view", the following UI resource strings are missing:

• fileNameHeaderText
• fileSizeHeaderText
• fileTypeHeaderText
• fileDateHeaderText

[DevCharly]

@Chrriis you're right. The missing texts are in Metal Laf resource bundle. They are loaded in FlatLaf with:

FlatLaf/flatlaf-core/src/main/java/com/formdev/flatlaf/FlatLaf.java

Lines 271 to 272 in d3a70b8

	// add Metal resource bundle, which is required for FlatFileChooserUI
	defaults.addResourceBundle( "com.sun.swing.internal.plaf.metal.resources.metal" );

Unfortunately this works only for Java 8, but not for Java 9+ because it is a internal file.

So have to add own file chooser texts to FlatLaf...

[DevCharly]

fixed in master branch

[Chrriis]

Yes, it does the job!

Now conceptually, I think this is not perfect: if in the next version of Java the mechanism changes, the library would break due to the desynchronisation of FlatFileChooserUI (extends MetalFileChooserUI) and FlatLaf (extends BasicLookAndFeel). The clean (and naive?) solution would be to either have FlatLaf extend MetalLookAndFeel or FlatFileChooserUI to extend BasicFileChooserUI. But either might be a lot of work or creating more problems?

[dpatriarche]

It would be great if FlatLaf had its own FlatFileChooserUI, but I know it would be a lot of work.

The source for MetalFileChooserUI contains the following comment:

    // Much of the Metal UI for JFilechooser is just a copy of
    // the windows implementation, but using Metal themed buttons, lists,
    // icons, etc. We are planning a complete rewrite, and hence we've
    // made most things in this class private.

That's been there a long time. I'm guessing it's not happening :-/

[DevCharly]

Don't think it is a problem to use MetalFileChooserUI because it does not depend on any other Metal class. It uses some UI defaults and some common classes (sun.awt.shell.ShellFolder and sun.swing.FilePane) that are also used by other core LaFs.

Basing FlatLaf on Metal just for the file chooser is definitely no option.

Implementing an own file chooser is a lot of work, but an option for later.
Don't know whether this is even possible without loosing some core features because it is not possible to use sun.awt.shell.ShellFolder and sun.swing.FilePane in an own implementation...