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.
see: this is exactly what i was complaining about in an earlier post.
Sun have given this incorrect impression that AWT is old and evil, and
Swing is the answer to all our problems, when the simple truth is that
AWT is maintained, heavily used, and the foundation of Swing.
i'm not arguing that JFileChooser doesn't need work. it does. but
FileDialog needs work too, and i believe that working on FileDialog
would give more "bang for the buck".
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.
if you're using a custom look and feel the JFileChooser's appearance
becomes your responsibility. Werner Randelshofer does a reasonable
job.
if you're using the "wrong" LAF for the platform, that seems in
conflict with caring about how accurate a copy of the platform's
dialog JFileChooser is.
yes, a JFileChooser is necessary for these cases, but they're niche,
and those developers are already in a position to take care of
themselves. fixing FileDialog directly answers the question "how do i
make my Java application look like a real application on this
platform?", and no amount of work on JFileChooser is going to get you
as close as just using the real component.
look at the Aqua, GTK, and Windows LAFs' renditions of JTable, for
example. if it's not possible to get a table right after almost a
decade, what hope is there for a file chooser?
That's looking at the problem backwards. Why not fix what is broken
(JFileChooser) instead of changing what works as advertised
(FileDialog)?
because FileDialog is broken too, but in specification (which is
unimplementable on Win32, and missing many important features) rather
than implementation.
As several have stated, JFileChooser has needed features, despite its
flaws. Apple's response of "don't use it" is unacceptable.
but would be ameliorated by having a more widely usable FileDialog.
and it's misleading to pretend that, say, the Windows JFileChooser is
okay. it certainly *looks* pretty close, but the problem i keep
referring to about hanging given a dead CIFS share is there, where the
native FileDialog works just fine. (to pick but a single example.)
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.
pretending that all platforms are the same was and is a mistake.
pretending that you should only implement the stuff that's available
and the same on all platforms was and is a mistake.
throwing the "not implemented" exceptions (as some of the new Java 6
functionality does) is 100% the right thing to do. a cross-platform
application, pace "write once, run everywhere", is a hard thing to
write, and will always require some cross-platform knowledge,
specificity, and testing.
the question is whether Java should make it *possible* to write a good
GNOME/Mac OS/Windows citizen. the answer is yes, and part of the cost
is "not implemented" exceptions. (or boolean feature tests. but you
get my point.)
_______________________________________________
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
