I've a request to make some changes to a little applet that currently use a JFileChooser.
One of the main complaints is that the file chooser is a pain in the ass to use because it behaves differently than the native widget, especially for navigating up to the root level.
So, knowing that and all the other issue JFileChooser suffer (like the zip file caching on windows...), I was wondering that a viable alternative exists in the java world.
Of course, there is SWT that use the native widget, but increasing the applet size by 25 is not really an option. So, is there a better pure java implementation of a file chooser?
The AWT FileDialog actually does use the native component, but as with most AWT vs. Swing issues, it's much less flexible and customizable than Swing's JFileChooser. So there's a tradeoff: JFileChooser may have a clunky user interface, but it's usually better for most purposes. If you really want your file choosing dialogs to look and feel like the native ones, though, then you can go with FileDialog.
I know this is a little late, but it may help other users. You can customize the UI of an application to the UI of the OS:
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (Exception e) {e.printStackTrace(); }
You can also try XFileDialog. Haven't tried it much yet but looks worth evaluating.
I wrote a wrapper around JavaFX' file chooser if available. If included in your application, you can replace
JFileChooser fileChooser = new JFileChooser();
with
JFileChooser fileChooser = new NativeJFileChooser();
It will then use the native (and modern) file chooser of the underlying platform. Not everything works 100% the same, so make sure to test it afterwards, but most things should go smoothly.
As #htw said use FileDialog if the look and feel is your main concern. By using FileDialog be aware that there a lots of convenience methods that you won't be able to use...
I used VFSJFileChooser few times. It doesn't suffer from the JFileChooser bugs(slow to load because of zip files, windows only), but the interface is not "native".
Related
JavaFX FileChooser subclasses as final from Object, and none of its methods looks promising. It's just a bit annoying from a TDD point of view (end-to-end test). Is the idea just to mock the whole business of choosing a file?
Swing JFileChooser was a proper JComponent: you could dig into it, mess around with it, subclass it, etc. With FileChooser I don't even see how we could get a Robot or JavaFX framework to select things, press buttons, etc. Seems a bit ... monolithic.
I want to use JFileChooser for Windows and FileDialog for Macs in my Java app. I have it already written in JFileChooser, do I need to completely rewrite it to handle the case for Macs (i.e check if the current OS is Mac and reimplement everything using FileDialog) or is there a easier way?
Short answer: yes, you have to reimplement everything.
Long answer: you could try to add an additional abstraction layer on top of everything, e.g. something like MyOpenDialog and MySaveDialog. These classes decide upon the OS whether to use JFileChooser or FileDialog, so you still have to implement it once. But only once, and if you need it in multiple places in your application, you can just use your own classes.
Be aware that FileDialog does not offer all the features of JFileChooser, e.g. offering the user a list of file formats to choose from (FileFilter) is only available for JFileChooser.
Is there a way to make the JFileChooser show the directory string at the top of the dialog just like in Windows? I need it because in that way, the users can paste the value they want instead of traversing the hierarchy every time.
PS: I'd like to avoid custom FileChoosers if possible.
What I want:
What I have:
The best solution would be to use the FileChooser from JavaFX. It has all the features needed to emulate the Windows file dialog.
http://docs.oracle.com/javafx/2/api/javafx/stage/FileChooser.html
I'm a Java developer and I have a new question. I want to open a file with another program. I can do it easily with the java.awt.Desktop class with this code:
public static void open(File document) throws IOException {
Desktop dt = Desktop.getDesktop();
dt.open(document);
}
But is there a way to choose which program it uses to open the file? My program is only for Ubuntu. I want a list with all regular programs that can open that file (all options you see with a right click on the file). And if it is an executable file it should just execute. Is this possible with Java? And if it isn't, Is it possible with C++?
It's possible, but probably not as easy as using the Desktop API, as that probably just calls xdg-open under the hood.
As the Desktop API almost certainly calls xdg-open under the hood (as most well-designed programs would do), you may be able to achieve the effect you desire by setting your desktop up such that xdg-open does the right thing for you.
If that's not sufficient, xdg-open uses platform tools to do its work, falling back to xdg-mime. This reads .desktop files. You can probably do the same...
I read that via
System.setProperty("apple.awt.fileDialogForDirectories", "true");
users can select directories via a FileDialog, now the FileDialog evoces the native file chooser, so that is exactly what i want but in the line above it reads: apple.awt..., does this mean this option will only work on Mac OSX?
if(no) {
great
} else {
what can i do to implement this on other operating systems than?
}
Thanks for any help!
PS: I know a lot of people suggest the use of a JFileChooser, but in this case i'd very much prefer the FileDialog, except if that's impossible
It is exactly as you feared.
AWT used native libs underneath. OSX has the feature to look for directories only, windows does not.
So youre only change is to use a dialog not based on AWT, i.e. Swing or SWT.
You can define an interface with platform specifc implementations. This gives a good looking dialog on OSX and something that works on other platforms. That's what I do.
To my knowledge, FileDialog does not support (in-code) using a directory dialog on all platforms.
You're already mentioned Swing's JFileChooser, but you may want to consider SWT for your widgets instead.
SWT is Eclipse (originally IBM)'s project to create an updated Java GUI Toolkit that still uses native widgets when they are available.
The major downside of SWT is that it is not part of the standard Java distribution... and each platform has its own SWT jar file.
Incidentally, SWT has a DirectoryDialog widget.