JFormDesigner / FlatLaf

FlatLaf - Swing Look and Feel (with Darcula/IntelliJ themes support)
https://www.formdev.com/flatlaf/
Apache License 2.0
3.39k stars 269 forks source link

File Chooser files are hard to find #100

Open Chrriis opened 4 years ago

Chrriis commented 4 years ago

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: FileChooser1

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): FileChooser2

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? FileChooser3

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? 🙂

smileatom commented 4 years ago

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?

Chrriis commented 4 years ago

@smileatom

Why would setting use system icons on all file choosers be a "downside"?

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.

Using the native file dialog is always an option if you require it.

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.

smileatom commented 4 years ago

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.

smileatom commented 4 years ago

Any fool can write a JNI wrapper around the system file chooser.

smileatom commented 4 years ago

Close.

DevCharly commented 4 years ago

Having system icons would be definitely better. I'll check how to integrate them.

Note that I also find navigation capabilities in the system file chooser much better.

Do you mean keyboard navigation? Or the bar at the left side?

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.

Chrriis commented 4 years ago

There is no problem to use it in Swing apps (except the look).

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! 😉

Note that I also find navigation capabilities in the system file chooser much better.

I was talking about the bar on the left. I use it all the time, I may not be the only one...

eirikbakke commented 2 years ago

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:

FileChooser

(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.

rkeen-siemens commented 2 years ago

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.

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.

It would be great if FlatLAF could somehow provide access to the standard Windows 11 file chooser.

I second that sentiment.

DevCharly commented 2 years ago

It would be great if FlatLAF could somehow provide access to the standard Windows 11 file chooser.

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

eirikbakke commented 2 years ago

The improvements to the Java file chooser are welcome! There would still be value to having a real native file chooser, though, e.g. so that the "Quick Access" directories are available on Windows.

image

DevCharly commented 2 years ago

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...

rkeen-siemens commented 2 years ago

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.

koden8 commented 2 years ago

@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

eirikbakke commented 2 years ago

@dinix2008 The jnafilechooser library worked great! I adapted it for my use; the associated win32 APIs were not as tricky as I feared.

Chrriis commented 2 years ago

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. I wonder if a real native file chooser could support transparently all the Swing customization APIs.

rogerbj commented 3 weeks ago

@DevCharly I see this in the sponsor page:

System file chooser (Windows 10/11) "Add new API to use native Windows 10/11 file chooser. The same API can be used on macOS to open AWT file chooser, which opens native macOS file chooser. Linux behavior TBD. This does not change JFileChooser. (issue #100, suggested API) (requires new native code in existing Windows native library)"

Is the plan also that it will support the accessory component found in JFileChooser?

DevCharly commented 3 weeks ago

@DevCharly I see this in the sponsor page:

System file chooser (Windows 10/11) "Add new API to use native Windows 10/11 file chooser. The same API can be used on macOS to open AWT file chooser, which opens native macOS file chooser. Linux behavior TBD. This does not change JFileChooser. (issue #100, suggested API) (requires new native code in existing Windows native library)"

Is the plan also that it will support the accessory component found in JFileChooser?

No, don't think that this is even possible. The accessory component is Swing. Would be difficult to embed that into native file choosers...

rogerbj commented 3 weeks ago

@DevCharly I assumed so. If completing the sponsorship for the native file chooser, in what time frame do you expect to have it ready?