Hi Carl, hi Clemens,
I'm a Swing team engineer responsible for JFileChooser.
Thanks for your interest in improving JFileChooser. Your discussion shows how
different requirements made by different people can be: while 100% native LaF
is not important for Clemens, for Carl it is essential. I think I have good
news for the both parties. We plan to continue improving JFileChooser by
adding, among other things, more native-like features, as well as we are going
to add support for native file dialog in Swing. So I think that with one of
the closest releases (unfortunately, it's not clear yet with which one), every
developer will be able to choose what is more valuable for his customers:
either pluggable LaF or 100% native file dialog.
Please feel free to ask any questions.
Leonid Popov
Swing team engineer
Sun Microsystems
Carl Antaki wrote:
Hi Clemens,
I am not talking about Look and feels it's all about usability. Every
function should be available by more than one mean: by using the
keyboard shortcut, the menu or the context menu for Cut, Copy, Paste.
Windows, Mac OS X, KDE and Gnome all provide context menus and we all
know these platforms represent 99% of all desktops. I still don't
understand why we do not have such basic features available in Java. I
was working on a Swing rich client app but for the time being I'm going
to work on a Web project. All I want is for the benefit of the Swing
developer.
Best Regards
Carl Antaki
On 9/5/07, *Clemens Eisserer* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Carl,
> I asked for that because I hate to say to the client
> that I cannot do that in a certain time because Java does not
> provide that, what impression will it give him? Another example is
> also that date picker.
> I know there's the date picker but it should be standard. If we want
> Swing to rock, the Swing team has to put the right time and effort to
> make Swing a first class citizen rich client development platform.
As I said if you would like to have it resolved in a fixed timeframe
you can simply take the source and do it yourself and as far as I know
there are very experienced companies implementing such fixes.
If you need it and don't know howto do it, there's a guy called
leo_user which maybe does it for money. (I hope he does not dislike
that I point you to him).
Well this is the old discussion about how important native look&feels
are. In my opinion (just taken from the experience with my customers
which are typically average users across all jobs) native lnf is not
important as long as the application looks good. The Steel-Theme of
metal was problematic - however some users already said they like
Ocean because it looks "fresh". And sometimes I use custom LnF's - but
most really don't care. I would say 95% don't care at all.
So from my point-of-view native LnF is not important at all, almost
not at all. I never deployed an app with native LnF enabled by
default.
So you have the following options:
- Implement your own filechooser (only helps you, maybe a lot of work)
- Hack the existing one and submit patches (helps everybody) or keep
changes to your app (but you've to open the sourcecode you modified
because its GPL with classpath exception)
- Pay sombody to fix it.
lg Clemens
