[Patch] File-choosing dialog not native

[Stereo]

File-choosing dialogs in Java applications are of two main types: dialogs created with java.awt.FileDialog and those created with javax.swing.JFileChooser. Using java.awt.FileDialog on Mac OS X would make JOSM behave more like a native Mac app, and the dialog would look much like a Finder window in OS X.

See also:

Apple's native platform integration guide for Java developers, ​https://developer.apple.com/library/mac/documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html , section "File-Choosing Dialogs"

Netbeans bug 82821, ​https://netbeans.org/bugzilla/show_bug.cgi?id=82821

[Don-vip]

Didn't even knew that Java proposed two classes for the very same feature o_O

This is something we can do without a Mac, I think.

[Lesath]

Ok - will try that one first - seems to be an easy one - with a AbstractFileChooser (to be implemented) it should work with both classes (java.awt.FileDialog/javax.swing.JFileChooser). OpenFileAction() is the class to start for this isn't it?

Or we switch completely to java.awt.FileDialog.

[Don-vip]

java.awt.FileDialog will never comply to Look-and-feel chosen by user and will look like native dialog. Many users would prefer this, but I think it would be safer to also keep the JFileChooser implementation.

The two key classes are:

1. source:trunk/src/org/openstreetmap/josm/actions/DiskAccessAction.java​
2. source:trunk/src/org/openstreetmap/josm/gui/widgets/JFileChooserManager.java

I'd see a property like use.native.file.dialog to choose between awt/swing implementation, i.e choose between JFileChooserManager (class not modified) and a new class FileDialogManager (if required) in DiskAccessAction and other classes currently using JFileChooserManager.

[Lesath]

Hmm - this seems more though than on first look.

There are more classes affected than I thought - plus FileDialog does not have all functionality that JFileChooser provides. Plus there are a bunch of classes affected - DiskAccessAction, ExtensionFileFilter, OpenFileAction, SaveAction, MapPaintDialog etc.

Just wanted to let you know that I'm still working on this - but it takes longer than I expected at the first look.

I will implement a GenericFileChooser that provides the same methods as JFileChooser. The underlying implementation will differ based on use.native.file.dialog which one is taken.

So in short JOSM will work with GenericFileChooser - its interface is compatible with JFileChooser.

[Don-vip]

Solution sounds nice :) Thanks for working on this :)

[Stereo]

Thank you Lesath!

The Extension filter hasn't ever really worked in JOSM. It just greys out the files that are filtered and makes them impossible to select. No one has ever complained about that, so it's probably ok if it disappears.

[Stereo]

The "native" file dialog would also let you sort by Kind, which is half-redundant with the extension filter anyway.

[Lesath]

Mac Native FileDialog

[Lesath]

Linux Native FileDialog

[Lesath]

Win 8 Native FileDialog

[Lesath]

Patch for native filedialog

[Lesath]

Hi there,

I've got the patch finished, but I'm not really happy with it, because it simply lacks of features or extensibility. However, this patch will work and if the use.native.file.dialog is used it will show the native dialog.

Step to enable it:

1. Enter preferences
2. Make sure "Expert mode" is selected
3. Go to Advanced Preferences, there enter use.native.file.dialog
4. set the value to true

Voila - you will get the native awt FileDialog.

But as written it lacks of features - and the set locale is also ignored (see attached screenshots for example).

Nevertheless I will hope this will help you.

[Don-vip]

I will look at it this week and see if we can integrate it :) Many thanks !

[simon04]

+1 for a native file dialog, the Swing based one simply looks ugly on Linux. Thank you as well for your contribution! A few remarks:

• FileDialogManager isn't used anywhere?
• Instead of having GenericFileChooser manage both selectors at the same time in several methods, we should have an interface or abstract class AbstractFileChooser (defining the methods getSelectedFile, getSelectedFiles, and other if needed). We'd provide two implementations of AbstractFileChooser which are based on JFileChooser and FileDialog respectively. The GenericFileChooserManager would then return either instance based on the property use.native.file.dialog. Following this approach, both implementations become clearer since they focus on one GUI component only, and more extensible since it is easy to add a third/fourth dialog type …
• I wouldn't worry about "simply lacks of features" since (as far as I checked) all usages only access the getSelectedFile/getSelectedFiles method.
• For the few places needing JFileChooser.DIRECTORIES_ONLY or JFileChooser.FILES_AND_DIRECTORIES, we could provide GenericFileChooserManager#createDirectoryChooser and GenericFileChooserManager#createFileAndDirectoryChooser, respectively. So there'd no need for exposing the JFileChooser constants.
• Also the plugins cadastre-fr and sds need to be adapted.

[Lesath]

Thanks for the remarks - I will have a further look into it - maybe this weekend which is a long one ;-)

The abstract class should be a better and clearer implementation - this is true.

I never thought of the plugins - thanks - I will check them too.

[Don-vip]

Did you have the opportunity to continue to work on this subject? :)

[Lesath]

Sorry - no - got a little swamped with life (read football) and work so no - not yet ;-)

[Don-vip]

OK no problem :) We'll try to finish this for next release :)

[Don-vip]

Replying to Lesath:

got a little swamped with life (read football)

It's finished now :)

[Lesath]

Replying to Don-vip:

Replying to Lesath:

got a little swamped with life (read football)

It's finished now :)

Thought so - I saw the merge conflicts today - onto the next ticket!

Thanks!

[Don-vip]

Move some tickets to next milestone

[Don-vip]

@Lesath: are you still OK to finish this patch?

[Don-vip]

Ticket #10539 has been marked as a duplicate of this ticket.

[Don-vip]

First beta of the patch, based on Lesath's work and taking into account Simon's first three remarks. I didn't see there's a serious drawback with FileDialog which doesn't support file filters at all (only a single filter, but it doesn't work on Windows, as ​stated in Javadoc):

Filename filters do not function in Sun's reference implementation for Microsoft Windows.

We need to fix that before considering to propose it as a viable option.

Some interesting links:

1. ​https://community.oracle.com/message/5455889#5455889
2. ​http://stackoverflow.com/a/1224744/2257172
3. ​https://netbeans.org/bugzilla/show_bug.cgi?id=82821
4. ​JDK-4811086, ​JDK-4811090, ​JDK-4811095, ​JDK-6192906, ​JDK-6699863, ​JDK-6927978, ​JDK-7125172

[Don-vip]

Looks impossible to add filters, I'm going to propose this as an option with a warning, but not as default. I hope this dialog will be improved in Java 9. That's not impossible as the multi selection is quite new (added in Java 7 only).

[Don-vip]

In 7578/josm:

fix #10024 - Add an option in Preferences/Look-and-Feel to use native file-choosing dialogs.
They look nicer but they do not support file filters, so we cannot use them (yet) as default.
Based on patch by Lesath and code review by simon04.
The native dialogs are not used if selection mode is not supported ("files and directories" on all platforms, "directories" on systems other than OS X)

[Stereo]

The file filters never worked on Mac OS X, so the new dialogs can safely be set to default there without upsetting anyone.

[Don-vip]

In 7585/josm:

see #10024, see #10455 - use native file dialogs by default on OS X