The Open file dialogs used by various commands; e.g. File/New Project..., is an
old fashioned Mac OS 9 style dialog. It looks very out of place on today's Mac
OS X, and is not nearly as functional as the native file dialog.
We use swing JFileChooser (which is created by apple)
At some places we probably could use awt FileChoosers that have more uptodate
visuals, but some locations (like the Open project action) cannot use that one
because it doesns't allow to plug custom UI in there.
I believe this issue ought to be closed as wontfix as it's as designed. Feel
free to file an issue against apple's jdk.
CCing people who might have a deeper understands of the issue.
I suggest using Quaqua (quaqua.dev.java.net) which provides a nice UI for the
JFileChooser which mimics perfectly the look of the Mac OS X. I could integrate
it with my NetBeans-base application with no issues (so far :-)
*** Issue 85173 has been marked as a duplicate of this issue. ***
This is the text of the duplicate 85173 issue:
The various file browsing dialogs within the NB IDE do not use the standard Mac file dialog. I believe
this simply means NB does not use or provide a user configuration for the AWT file dialog.
Specifically: I just downloaded the latest 5.5 beta 2 for Mac OS X. I then click on "New Project". When I
browse in that dialog, I get:
But when I do the same in Eclipse, I get:
I discussed this on the nbeans-users list and was advised to submit an issue.
You may find this a good guide to Mac/Java integration:
Java Development Guide for Mac OS X: Mac OS X Integration for Java
I would like to disagree with both the idea that JFileChooser should be modified by Apple, and with the
idea that Quaqua is the solution. The issue is simpler: there are times that applications, such as the NB
IDE, must make some very small adjustments for specific desktops such as Mac, Windows, and Unix/Linux
Apple provides very specific Java integration suggestions in: http://tinyurl.com/dzak4
Eclipse provides native file browsing, as do other applications. For example, see the NetLogo application,
which uses the standard Mac dialogs, even though it is a Java application.
The two choices are the Swing JFileChooser or the AWT FileChooser.
There's one specific thing that makes it impossible not to use JFileChooser in
NetBeans: With the JFileChooser you can provide your own FileSystemView (i.e.
your own file icons, etc.). Particularly in the open project dialog, we need to
be able to badge the icons of folders which are projects. There is simply no
way to do that with an AWT File Dialog.
There are quite a lot of mac-specific adjustments to make NetBeans UI more
mac-friendly - keybindings are altered (for example, Find Next is Command-G not
F3 on mac, and Ctrl-based mappings are judiciously mapped to Command unless they
clash with Apple system keybindings, there are special UI delegates for the tab
control that fit with Aqua, Apple-style 11AM drop shadows on floating windows,
etc.) I should know, as I wrote most of them.
To quote the page from Apple about their design guidelines, "Unless you need the
functional advantages of JFileChooser you probably want to use
java.awt.FileDialog." Unfortunately this is a case where we need the
"functional advantages" of JFileChooser.
It would be possible to use the AWT file chooser for those file dialogs which do
not need to provide custom icons or a custom filesystem, etc. However, since
open project is so prominent, having the dialogs be inconsistent would probably
be worse than sticking with JFileChooser; and it would require review and
modification of hundreds of sites in the NetBeans codebase to accomplish such a
This really needs to be fixed in Apple's Swing implementation - it's rather
surprising that such a glaring issue hasn't been dealt with already. I wish it
were otherwise, but it is not.
There in fact is one file dialog in NetBeans that does use the AWT file dialog -
right click in the output window and choose Save As :-) However, it is not
usable for many of the most prominent cases.
Currently (in NB 6.0) we implemented our own JFileChooser UI for opening projects and generally folders. While it
certainly doesn't feel Mac native, it has improved functionality such as directory name completion, multiselection of
nested directories and so on.
Currently I believe that's all we could do (as we must stick with JFileChooser as explained), so closing this issue.
You need to rethink the decision to not use the AWT File dialog. This the the only reason I don't use NetBeans, and why I steer my students away from using it. Every major release I check back to see if you've improved the situation, but every time I'm disappointed. Please please please dump JFileChooser.
One option: For a few releases we have had org.openide.filesystems.FileChooserBuilder
It has enough information to know if JFileChooser can be used or not. For most file chooser uses, it is never necessary for the code to touch a JFileChooser directly. So, for most cases it would be possible to use the AWT file dialog on Mac, in a way that is transparent to the caller.
Someone would need to take a pass over the entire codebase and convert every place it's possible to use FileChooserBuilder (maybe that could be automated?).
Note that the main Open Project dialog would still be using JFileChooser - since it needs to mark files which are projects, there is no way to do that in the AWT file chooser.
I read all of the comments above. I understand why JFileChooser had to be used. However, I would prefer a native file dialog to seeing icons in front of projects. I use "Favorites" folder a lot, and there is simply no way to navigate to my favorite folders from JFileChooser. Plus, JFileChooser looks so ugly and outdated on my Mac. As Bithammer mentioned, this is also a big "turn-off" for me.
The use of JFileChooser is the main reason I don't use Netbeans. It's the reason I've not recommended Netbeans to my Java students, my java user group co-members, and my coworkers. So it may not seem like a big deal for whoever prioritizes these usability bugs, but it has the potential to affect hundreds (thousands?) of potential users. I'm happy to help rethink where you see that it's 'impossible' to use AWT FileDialog. This isn't an OS X only issue, JFileChooser looks bad in all UIs.
Running the IDE with command line option -J-Dnb.native.filechooser=true enables native file chooser in Open Project and Open File actions.
If there is any other IDE feature that uses FileChooserBuilder.showOpenDialog or showSaveDialog methods it will switch to native file chooser too.
Note that it's possible to set that system property at runtime to switch from Swing's file chooser to AWT native one. So we can even add a check box to Options window. Cc'ing UI experts for guidance where such a checkbox should appear (if at all)
Integrated into 'main-golden', will be available in build *201208020001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: S. Aubrecht <firstname.lastname@example.org>
Log: #82821 - enable native FileDialog where possible
Clearly this issue does not have a universally good solution due to the conflicting demands of two groups of users, where none can be neglected. Due to the continuing deficiency in JFileChooser native feel we face the trade off between users demanding the familiar functionality of Mac file chooser and NB users that take advantage of the extra functionality that can not be realized through awt FileDialog - here the project path code completion alone can be considered by many to be essential.
Thanks Standa for implementing the system property.
As for adding switches of this kind to IDE Options, it can rightfully be considered bad practice, making the Options UI less clean and focused. However, given the strength of voices taking part in this debate, it seems we need to add the switch anyway as there seems to be no other resolution in sight.
From the existing categories and tabs in Options dialog the closest relevant is probably Miscellaneous->Windows. What would you say to add below the Document Tabs section a new one named, e.g., "Native Look and Feel", under which there would be a checkbox named, e.g., "Maximize use of native look and feel" ? This should be accompanied by a ToolTip to explain that "By default NetBeans takes use of native UI components whenever possible, except in cases where native components restrict standard NetBeans functionality. Check this switch to enforce use of native components despite possible impact on standard NetBeans UI behavior. (Affects file chooser dialogs on Mac.)"
Wording can of course be changed, preferably by native speaker.
Here's an edit to that text:
"NetBeans uses native UI components when those components offer sufficient functionality. Select this option to force use of native components, even when that may limit functionality (e.g. standard Mac OS file chooser)."
I know a guy who works on Swing at Apple, and asked him about this.
Mike: There is no way to do that from the native level, short of actually setting a custom icon on the folder itself so it would be visible in the Finder (presumably, a fine thing to do, if you actually "own" the folder).
(Imagine the issue of a sandboxed app, presumably interposing it's own 1024x1024 icons in full icon view, over paths it shouldn't even know exists)
Tim: Argh. Setting a custom icon would be fine for projects created by NetBeans, but I think it would be a little bit rude if it were done to, say, any folder NetBeans saw that contained a pom.xml
However, how *would* you set a custom icon, and can it be done from Java? There is a module of Apple-specific code that could go in.
Just reread my message to you - "work at Apple" -> "work at Oracle". Tim needs more coffee!
Mike: There isn't anything in the OS X JDK that will do it, but from the command line it's pretty straightforward if you pre-bake the icon resource file, copy it into the directory, and call /usr/bin/SetFile.
So the upshot of that is that the applemenu module *could* set the icons on folders persistently, by running a program which is on all Macs.
As I mentioned to Mike, I don't think it's a good idea to do that for any folder NetBeans stumbles across (or at least that should be off by default), but it would probably be fine for project folders NetBeans creates.
I've added that option in core-main 4b169fa721b7
Integrated into 'main-golden', will be available in build *201208300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: S. Aubrecht <email@example.com>
Log: #82821 - option to toggle native file chooser usage
Integrated into 'main-golden', will be available in build *201211300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Maria Tishkova <firstname.lastname@example.org>
Log: to support nb.native.filechooser option (Options->Miscellaneous->Windows check box "Maximize use of native look and feel " (see bz#82821 - Choose file dialog is not Mac native and bz#219555 - Open file dialog and add item dialog on mac does not have file text edit box like Linux and Windows for more details)