<Swing Dev> JFileChooser

[Carl Antaki]

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 <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
> 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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20070906/ebe886dc/attachment.html>