-
-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File Chooser files are hard to find #100
Comments
Why would setting use system icons on all file choosers be a "downside"? Also that is the behavior of Swing itself, Using the native file dialog is always an option if you require it. As to your other observation of course the native OS file chooser acts more like the OS. Thats what native means. Again, either launch the native file chooser or use Java's and customize it. Is this not clear in the java docs? |
I know you like doing everything by hand: I wonder why you are using a look and feel and not just set all the attributes of all components every time you instantiate them 🙂 It is a downside because the application has to be rewritten to have a usable file chooser. Instead, it should be as simple as setting the look and feel at the start of the application.
No it is not. In a Swing application you are supposed to use the Swing file chooser, which will be styled according to the Swing L&F. All the other ways to get a native file chooser are hacks, and hacking shouldn't be the standard way of coding. |
Again you misunderstand the role of L&F in Java. If you really want native behavior, write a native app. If you want unmaintainable ugly native-ish bevahior use Windows L&F, its the closest to what you want. You cant have it both ways. And I dont think any L&F project even as good as this one is will make you happy. But rock on. I guess. |
Any fool can write a JNI wrapper around the system file chooser. |
Close. |
Having system icons would be definitely better. I'll check how to integrate them.
Do you mean keyboard navigation? BTW it is easy to use the native (Windows) file chooser in Java. It's the AWT file dialog. import java.awt.FileDialog;
FileDialog fileDialog = new FileDialog( frame, "Open", FileDialog.LOAD );
fileDialog.setVisible( true ); There is no problem to use it in Swing apps (except the look). For macOS, I would even recommend to use it. |
There are a few problems with the AWT file chooser. For example, modality is a bit different with AWT components (e.g.: open the file chooser, switch to a different full screen application, and click on the app icon: only the file chooser is brought forward). API is slightly less rich. And last but not least: not everyone wants or can change all the places where a file chooser is used for the AWT one 🙂 I quite like the FlatLaf L&F applied to the file chooser, especially with the last change to use system icons! 😉
I was talking about the bar on the left. I use it all the time, I may not be the only one... |
On MacOS, the AWT file chooser actually brings up the native file chooser, which is great. But on Windows, the AWT file chooser seems to be another odd file chooser--perhaps an older native one, but not the standard Windows 10/11 one. See the difference here: (Top one is the AWT file chooser, bottom is the standard Windows 11 file chooser.) It would be great if FlatLAF could somehow provide access to the standard Windows 11 file chooser. Though it might be outside what a LAF is supposed to provide. |
That looks like a bug in Java. According to Vista Goodies in C++: Using the New Vista File Dialogs, it looks like Windows will use the older dialog when it thinks the application has customized it. In Java's case, it looks like Java adds a custom hook which is probably the reason it is using the older style.
I second that sentiment. |
Me too 👍 BTW Windows style shortcut buttons (known from Windows L&F) are coming to FlatLaf 2.3. See PR #522 |
It was a coincidence that I published PR #522 now. Worked on it already at last weekend (before Rangi's comment). And yes, having "Quick access" and other features of the native Windows file chooser would be huge benefit for Swing applications. Only drawback is that a native file chooser can not use FlatLaf themes. But this should be no big problem in most cases... |
Would it be possible to have an option to use the native file chooser when using FlatLaf? I understand it would not match the theme since the OS would provide the dialog, but it may still be preferable for the user. |
@rkeen-siemens, you can use native winapi binding, or use the https://github.com/steos/jnafilechooser project, which provides the ability to work with native dialogs. We use a similar approach in our application, and for native dialogs on Linux/MacOS we use FileChooser class from AWT |
@dinix2008 The jnafilechooser library worked great! I adapted it for my use; the associated win32 APIs were not as tricky as I feared. |
Having a real native file chooser is nice but should be an option because some do want them to be in line with the look and feel. |
@DevCharly I see this in the sponsor page: System file chooser (Windows 10/11) Is the plan also that it will support the accessory component found in |
No, don't think that this is even possible. |
@DevCharly I assumed so. |
Using FlatLaf, files are very hard to find. My setup is Windows based, I don't know how this behaves on other OS.
So, using this test case showing the 3 variations I am going to compare:
FileChooserTest.zip
I can open the FlatLaf file chooser in its current form (never mind the missing labels here). I find that it is hard to identify files, directories, search for known files by their type:
Compare that with the second variation which opens the system L&F file chooser (the L&F of the application remains FlatLaf, but I use a dirty trick):
One possible variation is to keep the FlatLaf file chooser, but to show system icons. The downside is that it has to be set on all instances of file choosers. Maybe this should be somehow settable as default?
Note that I also find navigation capabilities in the system file chooser much better. I wonder if in this specific case FlatLaf shouldn't implement such shortcut buttons in a platform dependent manner (Windows-like basic shortcuts on Windows, maybe something for MacOS, etc.).
The problem I have is that if we decide to adopt FlatLaf on our applications, some clients will be angry if they see losses of functionalities.
Any thoughts? 🙂
The text was updated successfully, but these errors were encountered: