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.
Related
I have this example to listening events from fileSystem (http://java.dzone.com/news/how-watch-file-system-changes) but the events are only create, delete or modify.
I want to listen a simple double click event from my fileSystem.
Does anyone know how to do it? I can't do it by swing.
Thanks!
Java, out of the box, is not capable of watching for "a simple double click event from my fileSystem".
The link you mention is about java code that can watch for other types of events, such as create, delete and modify within the file system, but double clicks are "user interface" events, which are not covered by java code as such.
However, you have rightly mentioned Swing.
If you wrote a programme, using Swing, that was specifically designed to make changes to the file system, then yes, your programme could be written to listen for clicks on a button on a swing layout, and your code could then decide what to do with that click event.
There is no such thing as a "double click event" in terms of the subject you're talking about.
The WatchService in Java is an interface with the implementation being platform specific (including being completely optional, depending on the platform).
The way the default implementation works on some platforms (specifically, windows / *nix) is by periodically polling the filesystem metadata for the directory you specified. If the default implementation is not monitoring access time (atime) or it's not available on the platform (or is turned off), then ... no, you can't get events for file access.
Testing this on OSX, it does not. I would have to test it on Windows and *nix to see what the results were there. I don't know that any of the default implementations do as atime isn't really reliable as it can be turned off on many file systems that support it to improve performance.
If you wanted to use the WatchService interface for this and the platform(s) your code would run on support it, you could implement your own that looked at access time and fired an event.
This StackOverflow Question demonstrates how to check atime on a file, but again remember it's not really reliable (read the comments on the caveats).
On Mac OS X, the native NSSavePanel supports an "accessory view" that can be used to specify file types and other options (using setAccessoryView:). I would like to do something similar in my Swing application as well.
I know JFileChooser supports something like this but it just doesn't look native. Is it possible to do this using AWT's FileDialog directly (which does use the native file dialog)? Maybe using Java Native Access?
No, it is not possible with FileDialog. Check out QuaQua. It's a Mac OS X Java look-and-feel that more closely matches the native UI. Its version of JFileChooser may be more to your liking.
If you're already familiar with the OS X API though, the best solution may be to just open a native dialog directly via JNI.
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.
I know the following things, and was wondering if they can be combined to make Java use jump-lists in Windows:
Windows displays Jump-Lists for supporting programs when a taskbar icon is right-clicked
C++, C#, F#, and VB support this natively (as shown here)
Java can import native capabilities using the JNA (as shown here)
Anybody have experience they can lend to help me create a jump-list for a Java app?
The J7Goodies library won't work, as it no longer exists.
The word "natively" is overstating the case a bit. WPF provides jump list support. That's not the same as C# providing it. (For Windows Forms people there's the Code Pack which is a set of managed wrappers.) And MFC provides jump list support which is also not the same as C++ providing it. Anyway, there are two things going on here. One is adding files you opened recently to that jumplist, which under some circumstances you can get for free. The other is adding arbitrary files (typically starting point templates etc) to the jumplist.
To add a file to the recent/frequent list, you call SHAddToRecentDocs, though you may not have to if, for example, you use the Common File Dialog control to open files, and/or the user double-clicks files to launch your app and open them (you have the file type registered.) Lots of folks suggest calling it anyway to be on the safe side. To add any old thing to the jumplist see http://msdn.microsoft.com/en-us/library/dd378402(v=VS.85).aspx.
How to call those from Java, I forget, but I hope they get you started.
There is a Java library providing the new Windows 7 features for Java. It's called J7Goodies by Strix Code. You can create your own jump lists with it.
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".