Up front: I do agree that FileDialog would benefit, and I am not
going to argue how much, as I do not use that many of them. I have a
wrapper class that gives me a JFileChooser on windows and FileDialog
on the Mac. I am not sure what our Linux guy coded in there, but all
three can be overridden at runtime by a property.
On May 25, 2006, at 9:31 AM, Elliott Hughes wrote:
On 2006-05-25, Scott Palmer <email@hidden> wrote:
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.
While I agree that the AWT is heavily used, I see far more Swing apps
out there, and every one of those not developed on a Mac uses
JFileChooser. They look quite subpar on the Mac, because Mac users
expect the real file dialog, or at least a reasonable facsimile.
It would be nontrivial to get a native looking JFileChooser, but it
would be worth doing, IMO. I do not control the code for other
developers, and when you tell a Windows developer that 'The mac looks
better with an AWT file chooser', they do not say 'Yeah, you are
right, let's change.' They say 'the mac has a second rate java
implementation. Why should we change our code, and what are we
getting from this cross platform language anyway.'
This is not a hypothetical - this discussion has come up several
times at various clients, and more than once has been the impetus for
a move to .NET. Conversely, it has also produced efforts to tune up
the apps to do the right thing. That said, this is not a discussion
to enter lightly.
So, telling the Windows folks that they need to change their code for
the sake of the mac is not a safe thing to do. I do it happily when
the developers have done something dumb and against the spec, like
hard coding a file separator, but I do not want to have to spend that
political capital on their choice of a more recent, and more
encouraged, API.
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".
Perhaps so. That said, I am not the developer of these Java apps, I
am a consumer, and occasionally the one who gets to reverse engineer
their file formats for the happy science guys.
[...]
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.
What about the apps that look fairly good, if not platform perfect,
on Windows, but that look like crud as soon as a file chooser opens
on the Mac? That seems to be the majority among the dozen-plus java
apps my clients use. The ones we write, we wrap the file chooser in
our own class that puts up a JFileChooser or a FileChooser according
to a property, derived at runtime, but I have to sell that to every
other developer, and that is hard.
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.
I do agree that this is a problem. It also should be fixed.
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.
Also agreed.
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.)
Thing is, it works well enough for most of the windows java
developers I have spoken with. They have their issues, but they use
Swing as a rule, and use JFileChoosers unless someone has browbeaten
them into the alternative. Most tell me 'never mix Swing and AWT -
NEVER' when I first bring it up.
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.
I cannot agree, really. Pretending that they are close enough for
cross platform UI, threading, and network code seems to have worked
out pretty well. I can write apps that do something useful, in a
reasonably pretty way, and have those work on my three major
platforms. Further, with recent VMs and machines, they are pretty
snappy, so I can stay out of most platform wars at clients.
Scott
_______________________________________________
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
