This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I've filed this as an enhancement but from a user's perspective the current behavior is really a bug. (1) Filechoosers do not recognize the "~" character (2) Filechoosers do not recognize the "$" character Specifically, given a path string, a file chooser should (a) replace ~<string>/ with /home/<string>/ (b) replace ~/ with $HOME (c) replace $<string> with the expansion of the environment variable named by <string> (possibly repeatedly) This should probably only be done when Utilities.getOperatingSystem() returns a unix-style operating system such as Solaris and Linux. For the full discussion (and explanation) please see the thread [nbui] UI Specification: Filechoosers Defaults on nbui (some of that thread is irrelevant to this, so see in particualr the following post: http://www.netbeans.org/servlets/ReadMsg?msgId=281112&listName=nbui Note - I can give you (properly SPL'ed) the code which given a path string expands it properly. What you need to do is plug this into the file choosers, most likely by creating a FileSystem (in the JFileChooser sense, not the OpenIDE sense) which performs this expansion and then plug this filesystem into file choosers as they are created. This issue may also require some modules to be modified but as soon as a central file-expander is available that should be straightforward. Let me know if you want the code.
Target milestone was changed from '3.4' to TBD.
If I understand it correctly it should expand string you enter Object Name field (in new ui spec) or File Name in JFileChooser after you press Enter. Am I right?
IMHO this is an RFE for Swing, not NetBeans. What is NetBeans-specific about it? It just refers to the fact that JFileChooser is not as usable as it should be, e.g. not as usable as the Gnome chooser. If JFileChooser had GNU-readline-style completion, this would be a natural part of that feature.
NetBeans is in a special position to do this because it has access to environment variables; Swing doesn't. I agree that Swing should at least handle ~. But since we're going to support jdk1.3 "forever", and since as far as I know jdk1.4 also doesn't fix this, we could enhance the user experience for users by fixing this. I pointed to this bug on nbui because we were already going to provide a special NetBeans filechooser (probably using JFileChooser). So I think fixing this problem there provides a nice way to remove a major annoyance for Unix users; besides, I was under the impression that we already have a number of "value-adds" over Swing (e.g. org.openide.awt) although that's only a vague impression not based on analysis.
Hmm, perhaps... but we are trying to get rid of "value add" components, not add more of them. They do not interact well with custom L&Fs, and a lot of our users use custom L&Fs. I would oppose adding new GUI components unless we really have to. If we want to adjust the look of a standard component, we should be creating a ComponentUI for it, not using a new component; in Kunststoff L&F the existing UI may be just fine, for example. If the ~ and $ expansion can happen entirely without GUI involvement, this is a plus, though I still feel they would be more natural when combined e.g. with readline support, which involves the L&F. BTW if we *are* using filechoosers for data objects or file objects, rather than java.io.File's, then ~ and $ expansion will be a little trickier: you will have to "map" the expansion into the internal object which represents it.
Yes, I believe this can be done without getting into the area of L&F's; as I explained in the e-mail on nbui about this you just install a delegating FileSystemView on the JFileChooser. It should work regardless of which L&F is in effect. In fact, I thought perhaps you'd already replace the FileSystemView to make it more NetBeans like (e.g. show mounted filesystems as opposed to local disks (when appropriate)).
I implement Object Selector using JFileChooser: I create fake java.io.File hierarchy from node hierarchy (in DataObjectEditor I add JFileChooser optionally in addition to current tree view), I overwrite File, FileView and FileSystemView. I did not check yet where this expansion could be done.
BTW: contrib/quickfilechooser already handles '~' correctly (I think). It doesn't handle $VAR yet, but it would be quite easy to make it do so if anyone cares enough. Note that System.getenv works again in 1.5.
I just added envvar expansion (not completion) to quickfilechooser, if you want to play with it.
If you want this kind of behavior, quickfilechooser provides it. If you want "standard" L&F filechoosers, request that the Swing team doing the GTK L&F improve their filechooser to behave something like the real one, which has at least ~ expansion.