JFormDesigner
System File Chooser
Class SystemFileChooser (in package com.formdev.flatlaf.util) allows using operating system file dialogs in Java Swing applications.
Details: https://www.formdev.com/flatlaf/system-file-chooser/
Windows
macOS
Linux
Light or Dark ?
On Windows and Linux, the system file dialogs are shown in system appearance. If application uses FlatLaf Dark, but system uses Light appearance, then file dialogs are also shown in Light appearance. Have not found a way to control light/dark appearance on those platforms.
On macOS, system file dialogs are shown in same appearance as FlatLaf. If application uses FlatLaf Dark, but system uses Light appearance, then file dialogs are shown in Dark appearance.
Background story
Before starting this task, the basic idea was to implement some (small) native
code for Windows and use AWT FileDialog on macOS and Linux. Thought that could
be done in 2 or 3 days. I was so wrong...
Turns out that AWT FileDialog does not provide necessary features (e.g.
"Select Folder"), window modality does not work, macOS file dialog does not
offer a "file filter" combobox, etc.
So implemented (larger) native code for Windows, macOS and Linux. This was difficult because I never used GTK before and my macOS Cocoa skills were also limited.
In the end it took about 4 weeks to implement, test and document this feature.
If I had known that, I probably wouldn't have started it...
So if you use FlatLaf in a commercial application, please consider sponsoring FlatLaf development: https://www.formdev.com/flatlaf/sponsor/
Thank you.
A snapshot for this PR is now available.
Use PR-988-SNAPSHOT as version.
https://github.com/JFormDesigner/FlatLaf#snapshots
Prebuilt binaries (Artifacts) are available here (requires GitHub login): https://github.com/JFormDesigner/FlatLaf/actions/runs/14009048883
I attach crash log, failure is pretty vanilla, just causes segmentation fault when exiting. hs_err_pid64597.log hs_err_pid64674.log
@ctipper thanks for reporting.
Unfortunately I can not reproduce it 😕
... just causes segmentation fault when exiting
What exactly are you doing? Open file dialog and then exit app while file dialog is still open? Or close file dialog and then quit the app?
Does it happen for open, save or select folder file dialogs? Or for all?
Can you reproduce it with the FlatLaf Demo? (use "File > Open (System)" to open system file dialog)
Exiting the file dialog triggers seg fault. Logs show two different code paths. Not sure I can help much, I thought the logs would be enough. They are both file open dialogs.
Exiting the file dialog triggers seg fault.
Does it happen when you press the "Cancel" button? or the "Open" button?
I thought the logs would be enough
Well, the log contains a lot of Java related information, but not a stack of native calls. ATM I have no idea where it crashes...
It's the Open button. I'm sorry I've dismantled my test bed. I was getting the system crash reporter but didn't think to save a copy unless you happen to know where in my file system they would be located?
java-2025-06-08-110041 copy.txt java-2025-06-08-110343 copy.txt File format is IPS, I changed file extension manually to upload (unsupported file type)
It's the Open button.
And it does not crash if you press the "Cancel" button? Is this correct?
Many thanks for the additional logs. I'll have a look 👍
Have updated macOS to 15.5 and can now reproduce the issue. Working on a fix...
The crash on macOS 15.x is now fixed in latest PR-988-SNAPSHOT:
https://github.com/JFormDesigner/FlatLaf#snapshots
There don't appear to be any macOS artifacts @ com.formdev:flatlaf:dylib:macos-arm64:PR-988-SNAPSHOT
Otherwise I can confirm success on arm64 macos (using artifacts rather than snapshots)
I implemented the system file chooser 5 different times, once as a open dialog and 4 times as an save as dialog. One save dialog launched in a minimised state, which needs a trick to maximise. I've only seen this in Preview.app and I don't understand how it's triggered, I didn't do anything special.
Reflecting on the minimised dialog and Preview.app I think I had used this option in my app to save as PDF
fc.addChoosableFileFilter(
new SystemFileChooser.FileNameExtensionFilter( "PDF Files", "pdf" ) );
Could that be the trigger?
Edit: It only happens on first launch, I'm thinking it's just a quirk
One save dialog launched in a minimised state, ...
Not sure what you mean by "minimized state" 😕 Can you please post a screenshot?
...which needs a trick to maximise.
what trick?
My app, with an export to PDF dialog. This is minimised. Preview.app presents a minimal version of this when you move a PDF to another folder. This only appears one time, it seems to remember state.
Also wondering what it would take to centre dialog on app window, I only adapted my App quickly and may have missed something.
I have confirmed working in Windows 11. I may be nitpicking but dialogs are wider than my app window and have to be resized.
I've tested in Xfce4 now, all working. I'm also able to do a side by side comparison with JFileChooser and in my opinion the platform needs to incorporate this code, JFileChooser is years old and not fit for purpose. How hard would it be to upstream this PR, I mean it looks really bureaucratic to me but I'm not a JDK dev?
One thing that is missing is passing a FileSystemView to the constructor or via a setter method (theJFileChooser supports it in a constructor and it can be used to sort the directories and the newest files to be on the top for example).
Not sure if a cross-platform solution for FileSystemView would be possible
One thing that is missing is passing a
FileSystemViewto the constructor or via a setter method (theJFileChoosersupports it in a constructor and it can be used to sort the directories and the newest files to be on the top for example).
@Scoty @KlemenDEV this is not possible because native file dialogs do not support this. They show always the file system.
Just realized that there are some unanswered questions...
My app, with an export to PDF dialog. This is minimised. Preview.app presents a minimal version of this when you move a PDF to another folder. This only appears one time, it seems to remember state.
@ctipper unfortunately there is no way to control this behavior. There is a property to get the "expanded" state, but no setter: https://developer.apple.com/documentation/appkit/nssavepanel/isexpanded
Also wondering what it would take to centre dialog on app window, I only adapted my App quickly and may have missed something.
@ctipper There is no way to control size or location of native file dialogs. The operating systems decide where to show it and its size.
I have confirmed working in Windows 11. I may be nitpicking but dialogs are wider than my app window and have to be resized.
@ctipper There is no Windows API to control file dialog size.
PDF dialog. This is minimised
@DevCharly This presented no difficulty as state is preserved, it just appears initially so only mild confusion. Weirdly it seemed to know that it was set for PDF so many users will not discover this
dialogs are wider than my app window
@DevCharly Let's hope it maintains state, I am not sitting at my test machine
This is all good work, though the Windows feature is the main motivation for me. JFileChooser is not a very useful dialog on Windows. Looking forward to the release.
Once again, thanks for this feature. One step forward to being JavaFX free in our software :D
I have tried to implement the solution for our project (https://github.com/MCreator/MCreator/compare/master...KlemenDEV:MCreator:system_file_chooser) and have noticed one problem.
With e.g. JavaFX that also uses native dailogs, one can defina a file filter such as "_file_suffix.png", so it only shows files that end with suffix + extension, but your file filter prevents dots in extensions and auto-applies dots, preventing this use case. Since JavaFX can do it, I think this should not be limitation of system chooser options. Would it be possible to implement something like this for this library too?
Other than that, seems to work very well, nicely done! :)
Wondering if there is any eta or roadmap for the stable release with this feature? Do you need any help with more testing?
In our testing, outside the feature request above I have no other comments and it seems to work as advertised :)