Skip to content
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

Open
Chrriis opened this issue May 12, 2020 · 19 comments
Open

File Chooser files are hard to find #100

Chrriis opened this issue May 12, 2020 · 19 comments
Milestone

Comments

@Chrriis
Copy link
Contributor

Chrriis commented May 12, 2020

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
Copy link

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
Copy link
Contributor Author

Chrriis commented May 13, 2020

@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
Copy link

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
Copy link

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

@smileatom
Copy link

Close.

@DevCharly
Copy link
Collaborator

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
Copy link
Contributor Author

Chrriis commented May 15, 2020

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

@DevCharly DevCharly added this to the 0.35 milestone May 18, 2020
@eirikbakke
Copy link
Contributor

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
Copy link

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
Copy link
Collaborator

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
Copy link
Contributor

eirikbakke commented Apr 27, 2022

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
Copy link
Collaborator

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
Copy link

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
Copy link

koden8 commented Apr 28, 2022

@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
Copy link
Contributor

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

@Chrriis
Copy link
Contributor Author

Chrriis commented Apr 30, 2022

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
Copy link

rogerbj commented Oct 12, 2024

@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
Copy link
Collaborator

@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
Copy link

rogerbj commented Oct 15, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants