<Swing Dev> JFileChooser

[Leonid Popov]

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* <linuxhippy at gmail.com 
> <mailto:linuxhippy at gmail.com>> 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
> 
>