Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FileDialog vs JFileChooser

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.

Mike implied that there might be some chance of *FileDialog* improvements if we say what it is that forces us to use JFileChooser.

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.)

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%.

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. 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.

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".

but then i'd only start complaining about how the Cocoa file dialogs aren't as good as (recent) GNOME or Windows ones. in particular, their tendency to hang when some network/removable file system causes an operation to block, and the way (IIRC; i might be confusing this with an Aqua JFileChooser problem) you can't accept a directory if you've double-clicked on it. you have to go back up a level, select the directory, and then accept.

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.

(i think various Apple developers have said in the past that they hold relatively little sway with Sun, and that bug reports to Sun from the likes of us are more likely to have an effect.)

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. and fixing JFileChooser (once for each platform!) will be way harder to fix than going back and revising FileDialog would.

(one thing to bear in mind, and it's in places like this that it really shows, is that most people working *on* Java, for whatever company, don't really work *with* Java. it's an interesting problem to solve, too, because if you take a Java application developer to work on the libraries, he's going to get out of touch. so really you'd need to keep cycling people back and forth every few years. but that would mean that you'd have to have some Java applications for them to work on. and i've yet to see a Java application from Sun that didn't feel like a deliberate act of sabotage.)

--
Elliott Hughes, http://www.jessies.org/~enh/
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.