Hi Leonid, Thanks for replying so promptly. That's great for JFileChooser, it was what I was looking for. When you say closest release will that mean it will be available in Java 7 or do you mean later? I know it's hard to predict but what is the plan?
Best Regards, Carl Antaki On 9/6/07, Leonid Popov <[EMAIL PROTECTED]> wrote: > > 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 > > > > > >
