<Swing Dev> JFileChooser
carlantaki at gmail.com
Fri Sep 7 02:48:04 UTC 2007
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?
On 9/6/07, Leonid Popov <Leonid.Popov at sun.com> wrote:
> Hi Carl, hi Clemens,
> I'm a Swing team engineer responsible for JFileChooser.
> Thanks for your interest in improving JFileChooser. Your discussion shows
> different requirements made by different people can be: while 100% native
> is not important for Clemens, for Carl it is essential. I think I have
> 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
> to add support for native file dialog in Swing. So I think that with one
> the closest releases (unfortunately, it's not clear yet with which one),
> 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
> > > also that date picker.
> > > I know there's the date picker but it should be standard. If we
> > > Swing to rock, the Swing team has to put the right time and
> effort to
> > > make Swing a first class citizen rich client development
> > 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
> > 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
> > 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 -
> > 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
> > - 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swing-dev