On 24-May-06, at 2:45 PM, Elliott Hughes wrote: On 2006-05-23, Steve Roy <email@hidden> wrote: On 23-May-06, at 1:24 PM, Mike Swingler wrote:
> t's not necessarily the case that the JFileChooser is better than
> the FileDialog because it's newer, they are simply two different
> implementations with very different design intentions and constraints.
>
> Generally we steer folks towards the FileDialog, even in Swing
> applications, assuming they want something as close to the native
> platform's look as possible. Is there additional functionality you
> use with JFileChoosers that you notice missing with the FileDialog?
I am so tired of anyone from Apple making it sound like the
JFileChooser implementation is fine the way it is... For Goodness's
sake, wake up people. Missing functionality in FileDialog? Come on...
Mike specificially *didn't* recommend JFileChooser.
That's the point. Mike appeared to be ok with pushing people to use FileDialog because JFileChooser is poor. It seems obvious that fixing issues with JFileChooser is the more logical course of action. Mike implied that there might be some chance of *FileDialog* improvements if we say what it is that forces us to use JFileChooser.
That's not the impression I got. I certainly hope that he was looking to see why he JFileChooser should be fixed.
Who cares about FileDialog improvements? Is it not working as advertised now? It's JFileChooser that needs the work. I don't want to have hacks in my Swing code. AWT is old news. It's practically deprecated. I shouldn't need to use it (directly) in a Swing application. It sticks out like a sore thumb if the rest of my application uses a customized look and feel, or I allow the user to choose a look and feel. i seriously doubt that it's productive for people on this list to be so rude in response to seemingly honest interest in fixing things. (the other poster was worse.)
As I read it, Mike's post y implied that Apple knows their JFileChooser implementation is sub-par and they aren't concerned because they think it is a trivial matter to use FileDialog instead of JFileChooser. Though his request for input on the matter is welcome and if he is collecting data to build a case for doing the "right" thing (fixing JFileChooser) then more power to him.
i think it's telling that everyone who's been specific about what they'd need in FileDialog has asked for something different. it's like the MS Word problem where everyone uses 10% of the features, but everyone uses a different 10%.
Yes, it tells me that JFileChooser should be fixed because all of it's features are needed and programmers should be able to rely on it working "as expected" by based on both the expectations of users and developers. for example, to my mind the requested ability to put custom components in the file dialog is an abomination. i've never seen that used well.
It doesn't matter. It's part of the JFileChooser spec, so it will get used, which means that some applications will "need" to use JFileChooser, so JFileChooser should have a decent implementation.
As far as the accessory component not ever being used well. The way I look at it, the native Aqua file dialog effectively implements the "accessory" as the last column. In fact, if the Swing version had a default accessory that just looked like the native file info column and if setting your own accessory actually replaced that column, I would consider that acceptable. what i personally would need from FileDialog to be able to use it all the time (rather than just most of the time) is to have a way to say FILES_ONLY/DIRECTORIES_ONLY/FILES_AND_DIRECTORIES on a per-dialog basis.
That is a request for Sun, not Apple. Apple can't change the public interface to FileDialog. so to paraphrase another poster in a more polite fashion, "any JFileChooser functionality Apple can offer us in FileDialog would be appreciated by some, and help improve some Java applications on Mac OS".
That's looking at the problem backwards. Why not fix what is broken (JFileChooser) instead of changing what works as advertised (FileDialog)?
but going back to the post i'm replying to, if you replace "Apple" with "Sun", i'm 100% with you. i too am tired of Sun making it sound like the JFileChooser implementation is usable. and pretending that http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4031440 and its many duplicates need not be fixed. the evaluation of that bug says *exactly* the alternative API that needs adding to replace the should-be deprecated unimplementable API they lumbered themselves with. pretending that JFileChooser is anything but a heinous leap backwards drives me mad.
but this isn't an Apple problem that Apple can fix. this is a Sun problem, and -- though being rude to them probably won't help either -- it's Sun we should be harrassing.
Sun deserves some harassment on the issue for sure. I've bugged them about the Windows implementation. That doesn't let Apple off the hook for not implementing the Swing Aqua look and feel properly though.
as far as i've seen, Apple have been clear and consistent in their advice that you should avoid JFileChooser because -- though they're too polite to say so -- it's a piece of junk. on *all* platforms.
As several have stated, JFileChooser has needed features, despite its flaws. Apple's response of "don't use it" is unacceptable. and fixing JFileChooser (once for each platform!) will be way harder to fix than going back and revising FileDialog would.
I have my doubts. What do you do on platforms where the native FileDialog doesn't have the feature you want? Throwing a bunch of "Not Implemented" exceptions is just going to force all those hacks on the developers again. That's what Swing is trying to solve in the first place.
Scott | 
