A DESCRIPTION OF THE REQUEST :
Currently, JFileChooser seems to follow some strange, windows-only or mac convention from the distant past, of allowing the user to change the name of a displayed directory or file, by simply "slow-clicking" on the name, which then suddenly, sometimes very alloyingly, changes to a highlighted string. They complete the change by pressing Enter. This is sometimes a useful feature in "personal" or "single-user" applications, such as WP, DTP, Graphics, Editing, and so on, that would be common on a GUI desktop, but this should be absolutely forbidden in a multi-user, database style application, such as accounting, point-of-sale, or other mission-critical system. In those application areas, we need to strictly avoid allowing the user to do *anything* except choose the required filename, and click OK or cancel from the FileChooser. Changing the name of a file OR directory in these environments could be fatal. Even worse, the JFileChooser usually displays a "create new folder" button, which can also get the user into serious trouble, and problems can occur if they try to create a directory that already exists, and so on.

The other annoying aspect of this "common convention" in JFileChooser, is that it makes it extremely difficult to navigate quickly though the directory hierarchy, until you find the filename you are looking for, because of the speed at which the "slow-click" action responds on different operating platforms, and it can trip you up without warning and again jump into "change" mode when least expected. The only way to get out of "change" mode seems to be, again by convention, to click "somewhere else" in the white space surrounding the directory names, thus reversing the highlight, and hope that you don't land on another directory name. Also, how do we know whether one of the "drives" or other accessible locations is not outside the user's machine, and located on the network?

It can certainly happen, in which case, you are now allowing the user to directly rename a file or directory on another machine in the local network, when no such action should ever have been allowed! This is not a good situation in which to build a critical, cross-platform, multi-user, GUI application.

The only solution at present, is to create our own customized "filechooser" component, but this is complicated by the low-level details of cross-platform differences, drive names, and so on. A much better solution seems to be to simply enhance JFileChooser, by adding say, a "setRenameFile(false)" property and a "setCreateFolder(false)" property, or alternatively, a single property "setReadOnly(true)", for all those situations described above. This would make JFileChooser more suitable for mission-critical, multi-user applications, but still be completely familiar to users in any application.

I find it difficult to believe that a component as fundamental as JFileChooser should overlook these simple requirements - they certainly should not be thought of features, but more as vital options.


JUSTIFICATION :
This enhancement is necessary to allow failsafe operation of JFileChooser, in those application areas that must protect against accidental or deliberate change of directory names or file names, or creation of new folders, expecially when they might be located outside the current dekstop machine.

This kind of activity, in a mission-critical or database-oriented application such as point-of-sale, accounting, and so on, should be strictly forbidden, and therefore be able to be turned off as an option.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
After applying a boolean property call, such as "setReadOnly(true), a "slow-click" anywhere at all in a directory or filename in the tree of a JFileChooser should have *no* effect whatever, and the ability to create a new directory is disabled.

The user is only allowed to either choose a directory or filename and click OK, or click cancel and return from JFileChooser.

ACTUAL -
1.After a "slow-click" on any directory or filename in the directory tree in JFileChooser, the directory or file name goes into "change" mode (highlighted), and allows the user to overtype a new name.

2. In JFileChooser, a "create new directory" button is usually displayed, allowing the user to create a new directory.