Skip to main content

Will JFileChooser ever get fixed on Windows?

28 replies [Last post]
swpalmer
Offline
Joined: 2003-06-10
Points: 0

I'm getting a LOT of pressure at work to write my own JNI code to access the native Windows file dialogs because the Swing implementation is so poor. Our customers complain, other developer's complain, our sales people complain.. etc.. So now I'm complaining here.

There are several open bugs for this... and they are all old. Some have been closed without being resolved, but many are still open. I appreciate some of the performance improvements I've seen recently with Mustang... they help a bit.. but there is so much more to do.

Sorting - finally here in Mustang (boy did that take waaaay too long, but thanks!), but the names are not sorted the same as the native UI. In particular names starting with an underscore are misplaced.

Context menu - forget the really hard part about supporting all the native shell extensions that might have installed stuff for the context menu.. What about the simple stuff like Delete and Rename?

Why not use a dropdown list to select the 'view' (List, Details), instead of the multiple buttons that are used now?

Where are these views?
Thumbnails, Tiles, Icons

Why is the Directories-only version not using anything at all like the windows directory chooser?

Some of this is covered here
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4438933

But there are also:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4442981
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5035693
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4835469
... just do a search... the problem has been around for a while...

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
alexlamsl
Offline
Joined: 2004-09-02
Points: 0

> Why don't we just have a AWT file chooser and keep
> the Swing one the same?

I'd top that idea - Swing should stay as purely Java as possible ;-)

swpalmer
Offline
Joined: 2003-06-10
Points: 0

> I'd top that idea - Swing should stay as purely Java
> as possible ;-)

Well keep in mind that JFileChooser MUST use a lot of native calls to implement the proper look and feel.

I don't mind the idea of making JFileChooser (optionally) use the native file dialog... but I think this must happen in conjunction with improvements to the Java version.

Basically, I'm saying that all the stuff that can be done on the Java side to make JFileChooser more closely match the native dialog, should be done, as long as it isn't unreasonably difficult. Then the native dialog idea should be reconsidered based on what is left. I wonder how much really would be left?

Another issue is with applications that want to customize the look and feel, but still provided the essential familiarity in areas like the file dialog. E.g. what if I want the dialog to have colours and buttons with my look and feel, but I want the context menu to include everything that the native Windows context menu includes? It's admittedly a less common case but it would be nice to have. Perhaps that can be solved outside of Swing though, via a JDIC project that provides accessibility to Windows shell extensions or some such thing.

The other main thing is the setAccessory method of JFileChooser. If you could support that with the native dialog implementation (and I think it is possible), it would be great. Many applications, like office suites for example, use an accessory panel to show details or previews of the document currently selected. I do that in one of my applications when it is browsing for custom media files that have various attributes that would influence the decision to load them into the application. By showing the attributes in the browser it makes the selection process better.

Scott Violet

swing@javadesktop.org wrote:
> It depends :)
>
> For my particular use-case, all I need is a native file chooser. Then
> again, I wouldn't want the API to be modified to restrict my choices for
> the future (when I might want to add/remove components from the file
> chooser).

That's one of the advantages of enabling Swing to use the native one,
where appropriate. You could always use Swing's filechooser and choose
how you want it to operate.

> Why don't we just have a AWT file chooser and keep the Swing one the same?

We may end up doing that as well.

-Scott

fuerte
Offline
Joined: 2004-11-22
Points: 0

Could it be possible to use SWT only for file dialogs? SWT is quite big though.

fuerte
Offline
Joined: 2004-11-22
Points: 0

What if Sun added SWT to JRE and made it possible to use both Swing and SWT in the same application (maybe it already is), so that some windows could be Swing and some SWT.

swpalmer
Offline
Joined: 2003-06-10
Points: 0

> What if Sun added SWT to JRE and made it possible to
> use both Swing and SWT in the same application (maybe
> it already is), so that some windows could be Swing
> and some SWT.

I am very much against this idea. If anything I think that it would make more sense to enhance AWT so it was more SWT -like.

The JRE does not need to have three GUI toolkits. It is bad enough that it has two. Code bloat and download size are already a concern for some.

Scott Violet

> My point being, that I was asking about JFileChooser and if I should
> expect improvements to be coming from Sun or not. If so, what sort of
> improvements are expected? E.g. I suspect 100% support for native shell
> extensions in the context menu to be difficult and possibly impossible
> or impractical enough to never happen, but things like Icon view should
> be doable. (Maybe Thumbnail view is also very hard ... I don't know.)
> Using a drop-down menu to select the view type instead of radio buttons
> should also be possible.

I believe Leonid already answered this. Yes, we are working on
improvements, yes we realize JFileChooser is important.

Will the improvements make 1.6? 1.6 is nearly done, from an engineering
perspective, so you'll most likely have to wait till 1.7.

-Scott

swpalmer
Offline
Joined: 2003-06-10
Points: 0

> > My point being, that I was asking about
> JFileChooser and if I should
> > expect improvements to be coming from Sun or not.
...
>
> I believe Leonid already answered this. Yes, we are
> working on
> improvements, yes we realize JFileChooser is
> important.

Actually,when Leonid mentioned hooks to the native Windows Dialog it sounded as if it was considered because fixing the Swing component (completely) wasn't likely to happen, at least not enough to suite everyone... so I figured perhaps there was room for further clarification.

I don't want to come across as overly negative. I'm pleased with what I have seen so far in Mustang. Fixing the sorting helps me a great deal, since many customers find it essential for navigating through directories with lots of files.

In general the attention that the desktop environment has been getting in Mustang is great. I and my colleagues are very pleased to see it happening. I'm picking on JFileChooser because it is something that is such a common part of the user-experience. It goes unnoticed much of the time, but when someone does pop-up the context menu, or try to change the view it does come as a shock that what is expected as a common ability across the OS is somehow missing from my application. From the user's point of view they are justified in thinking I would actually have to go out of my way to break it :)

So thanks for what you have done so far. And please keep it up because Look and Feel fidelity [b]is[/b] an important thing.

Scott Violet

swing@javadesktop.org wrote:
>>> My point being, that I was asking about
>> JFileChooser and if I should
>>> expect improvements to be coming from Sun or not.
> ...
>> I believe Leonid already answered this. Yes, we are
>> working on
>> improvements, yes we realize JFileChooser is
>> important.
>
> Actually,when Leonid mentioned hooks to the native Windows Dialog it
> sounded as if it was considered because fixing the Swing component
> (completely) wasn't likely to happen, at least not enough to suite
> everyone... so I figured perhaps there was room for further clarification.

Our current thinking is to try and make it possible for Swing's
JFileChooser to use the native one. This would obviously have some
limitations, and you would have to ask for it, but in theory 90-95% of
the common usages of JFileChooser could be accommodated via using the
native file dialog. What do you think?

Thanks for the kind words!

-Scott

cowwoc
Offline
Joined: 2003-08-24
Points: 0

It depends :)

For my particular use-case, all I need is a native file chooser. Then again, I wouldn't want the API to be modified to restrict my choices for the future (when I might want to add/remove components from the file chooser).

Why don't we just have a AWT file chooser and keep the Swing one the same?

leouser
Offline
Joined: 2005-12-12
Points: 0

well if we only have the AWT FileChooser, the file chooser is going to look awfully funny when used with my special look and feel. For example say on Windows I want my java app to look like Tk on Linux(yikes!). I can't have the JFileChooser looking good when everything is supposed to look bad.

leouser

cowwoc
Offline
Joined: 2003-08-24
Points: 0

From what I hear, this is only going to get fixed in Dolphin. I feel your pain. I also feel JFileChooser is the biggest noticable problem in Windows L&F right now. I can't believe we're going to have to wait *another* two years for a fix :(

I'm currently trying to create a patch using Project Peabody to contribute to Mustang before it goes final so at least keyboard navigation in JFileChooser will be more bareable. It remains to be seen whether I'll have this patch ready in time (building the JDK locally is a *major* pain).

alexlamsl
Offline
Joined: 2004-09-02
Points: 0

Just adding my 2 cents here :-)

People are free to yell about the bugs that they want to fix most; in fact that's how Sun is going to learn how things should be prioritised.

However, to express it with excessive generalisation (e.g. I never had a complaint about JFileChooser myself, nor do any of the people around me - actually I have only heard about this request now) or to send pointless threats in an attempt to force the engineers to work in your favour is Just Plain Wrong.

In addition, if you really want something, think about doing it yourself, as with almost everything in life. Join Peabody if you appreciate Sun's and others' efforts to date with Sun's implementation, or if you'd prefer, go and work with the OSS guys.

And by the end of the day, if you really think that another programming language is better, feel free to cross over and use that language instead. Many of us are using Java quite happily, and do not see why some of the smaller issues get held on and beaten by some people with words instead of code.

leouser
Offline
Joined: 2005-12-12
Points: 0

Ive done some JFileChooser bugs... but *sniff sniff*, I haven't focused on any Windows JFileChooser bugs. :( Maybe someday...

leouser

grlea
Offline
Joined: 2004-05-26
Points: 0

Has everyone forgotten that SUN now accepts submissions for bug fixes from the public?

If the problems are clear, and everyone feels so passionate about it, I'm sure there's someone among us who has the skills to download the source and fix it!
Maybe start with something simple, e.g. setting the button text on the AWT dialog, and go on from there!

Please?

rabbe
Offline
Joined: 2003-06-14
Points: 0

If you're getting pressure to use JNI, then I suggest JNI wrapper. You can use their winpack to display the native dialogs. It's royalty free for distribution.




You have many options. Swings dialogs will probably never be perfect, but they work well enough for most.

profiler
Offline
Joined: 2005-05-12
Points: 0

If you want the native filechooser its less than a days work implementing it yourself. JNIWrapper is the easiest way to get it done though - and look at everything else they have as well - excel/ie/color choosers/directory choosers/window api etc.

If you have customers, and they need a native filechooser, simply provide it. You have options - the easy ones are small prices (99$ or something for jniwrapper) or spend a day doing it yourself through one of the many open source jni software components.

Theres no need to wait for jdk6/7. We have been using this approach for 3 years now in commercial desktop apps.

Joe

swpalmer
Offline
Joined: 2003-06-10
Points: 0

Why don't [b]I[/b] just write my own version of [b]every[/b] class in the JRE that has bugs and forget that Sun has anything to do with it? :)

I know I can [b]work around[/b] the problem, that's obvious and has little to do with Sun fixing what's broken. Sun could just not fix any bugs - we can all just work around everything by writing our own code from scratch.

The Swing team is a little more responsible though.. they actually fix their own bugs :). But some are easier than others, sometimes it could be that there is no practical solution and that's that.

My point being, that I was asking about JFileChooser and if I should expect improvements to be coming from Sun or not. If so, what sort of improvements are expected? E.g. I suspect 100% support for native shell extensions in the context menu to be difficult and possibly impossible or impractical enough to never happen, but things like Icon view should be doable. (Maybe Thumbnail view is also very hard ... I don't know.) Using a drop-down menu to select the view type instead of radio buttons should also be possible.

Fixes in the JRE are preferred over workarounds in my code, for obvious reasons.

I already have some workarounds in my code to deal with some of the really painful aspects of JFileChooser, like sorting. E.g. our customers may have hundreds of files in one folder, if they can't sort by date, it makes it very hard to find what they did last week. They should not have to re-think everything because the file chooser in my application doesn't match what they have come to expect.

I have bought some time with what I've done so far - possibly enough time to hold off until Java 6 ships. But going to a native file dialog is difficult when you want to put a custom Swing panel in it, like you can with JFileChooser. From that perspective, even if Sun implements better bindings to the native Windows dialogs (or I write them myself) that doesn't solve things for every case.

leouser
Offline
Joined: 2005-12-12
Points: 0

I hate asking this, but have you tried enhancing
com.sun.java.plaf.windows.WindowsFileChooserUI?

or using it as the basis for a better WindowsFileChooserUI?

Im assuming that this is the class that is the source of the 'pain' your experiencing.

leouser

cowwoc
Offline
Joined: 2003-08-24
Points: 0

On a related note, I am trying to figure out which part of the code ensures that if a user double-clicks on a directory in directory selection mode that JFileChooser returns right away instead of navigating into that directory and listing its contents.

I know it has something to do with isTraversable() but I can't find a part of the code that returns false for directories if directory selection mode is used. Any ideas?

leouser
Offline
Joined: 2005-12-12
Points: 0

Well, from what I can tell isTraversable determines if a directory is even shown:
import javax.swing.*;
import java.io.*;

public class TestJFC{

public void testJFC(){

JFileChooser jfc = new FC2();
jfc.setFileSelectionMode(jfc.DIRECTORIES_ONLY);
jfc.showOpenDialog(null);

}

class FC2 extends JFileChooser{

public boolean isTraversable(File f){
if(f == null) return true;
System.out.println(f.getName());
if(f.getName().equals("a")) return true;
if(f.getName().equals("b")) return true;
if(f.getName().equals("c")) return true;
return false;
}

}

public static void main(String ... args){
Runnable run = new Runnable(){
public void run(){
new TestJFC().testJFC();
}
};
SwingUtilities.invokeLater(run);
}
}
------------
if you are going to show up in directory 'b' which is a child of 'a' and you only want 'c' to be shown then this code does that.

leouser

flozano
Offline
Joined: 2004-01-22
Points: 0

I think native file open dialogs would be an interesting project for JNDI, just like tray icon support. Maybe someone out there would like to start this subproject.

Bottom line, instead of complaining to Sun about all Java problems, join a community that can solve the problems without Sun. No single company will solve all user problems. This could GNU Classpath, Swing Labs, JGoodies or even SWT and Java-Gnome.

In the end, when the community provides the solution, it'll become official, just like EJB3 almost cloned Hibernate.

loneid
Offline
Joined: 2006-04-13
Points: 0

Hi,

Thanks for your interest! The issues you mentioned are really important ones, and we here in the Swing team are not satisfied with JFileChooser, like you and your customers.

We consider a possibility to add support for native Windows dialogs in the next version of JDK, including native file chooser, what hopefully would solve many of problems. We will also keep on improving existing JFileChooser, of course, but curently we've been working mostly on non-visual things like correct symbolic links processing on Solaris or backward compatibility, so unfortunately we couldn't update the JFileChooser look in Mustang much.

I would also like to encourage all developers interested in JFileChooser improvement, if you feel that a bug is critical for you, please vote for it by clicking at the "Vote for this Bug" link at the left side of the bug details page: it helps us to arrange the bug fixing queue in the right order. Your activity in this forum will also be very helpful. Moreover, if you think you know the solution for a bug, please join our Peabody project and suggest your fix, and your code may become a part of Java (to learn about Peabody, see the Graham Hamilton's article at http://java.sun.com/developer/technicalArticles/J2SE/peabody).

Thanks,
Leonid Popov,
Swing Team engineer

carcour
Offline
Joined: 2003-06-18
Points: 0

By next version do you mean Mustang or Dolphin?
It's really a shame that we're in 2006 in it's still not possible to create a top notch Java desktop app because of the following reasons:
* slow startup time
* high memory footprint, not a lot of memory sharing if launching more than 1 Java app
* JFileChooser really lacks features

I use Swing and I like it a lot but unfortunately some things aren't being solved, maybe after all Java isn't the best language for desktop apps. I'm not talking about responsiveness I know the EventDispatch thread isssue and know how to use SwingWorker, I'm talking about the time it takes to load the widgets because they need to be drawn. SWT's use of native widgets is a good thing they also have the native JFileChooser, why reinvent the wheel? Even though some people say that today's machines are perfectly capable of running Java programs, that is not the case in all companies where some of them still have Pentium II computers.
It's possible to write a good looking app but one shouldn't touch JNI just to access the native FileChooser.
Just something easy like adding right click to all JTextFields and JTextAreas requires a hack and there's no normal way of doing that (Swing hacks) or adding a PopupListener to each component. On Windows (MFC), on Linux (GTK & QT) as well on Mac OS X, the native apps have right click by default.
I like Java, I use it and I find it the most beautiful language, I want the JDK to improve that's why I'm writing that. I have to admit that Java improved a lot from being close to unusable (because it was very slow) in the pre 1.4 days to being not so bad after the release of Java 5 so I thank all the engineers for their work. I also think Java could benefit a lot from being Open Source so pure Open Source people will use it on the server instead of PHP and use Java instead of Mono on the desktop side but isn't it too late?

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

> I use Swing and I like it a lot but unfortunately
> some things aren't being solved, maybe after all Java
> isn't the best language for desktop apps.
Well then why are you not using this "better" for desktop application languages?

> It's possible to write a good looking app but one
> shouldn't touch JNI just to access the native
> FileChooser.
Well right for YOU this is a big problem, however there are many other devs and users arround which would like to have their problems fixed.
My customers actually never complained about the filchooser, so it can't be _the_ thing which holds java away from dekstop ;)

> Just something easy like adding right click to all
> JTextFields and JTextAreas requires a hack and
> there's no normal way of doing that (Swing hacks) or
> adding a PopupListener to each component.
Why a hack, could be explain the problem in detail?

> I also think Java could
> benefit a lot from being Open Source so pure Open
> Source people will use it on the server instead of
> PHP and use Java instead of Mono on the desktop side
> but isn't it too late?
This will never happen, SUN will not give away their one and only future plan away for free. They invested millions of dillars, I would rather help to improve already existing implementations like GNU classpath.

lg Clemens

carcour
Offline
Joined: 2003-06-18
Points: 0

> > I use Swing and I like it a lot but unfortunately
> > some things aren't being solved, maybe after all
> Java
> > isn't the best language for desktop apps.
> Well then why are you not using this "better" for
> desktop application languages?
Because Java is so easy to use compared to doing a GUI in C++.
>
> > It's possible to write a good looking app but one
> > shouldn't touch JNI just to access the native
> > FileChooser.
> Well right for YOU this is a big problem, however
> there are many other devs and users arround which
> would like to have their problems fixed.
> My customers actually never complained about the
> filchooser, so it can't be _the_ thing which holds
> java away from dekstop ;)
If we have it in the OS why not have it in Java, why then not go back to Windows 95 when you can use Windows XP!
>
> > Just something easy like adding right click to all
> > JTextFields and JTextAreas requires a hack and
> > there's no normal way of doing that (Swing hacks)
> or
> > adding a PopupListener to each component.
> Why a hack, could be explain the problem in detail?
Well the problem is that it's no scalable performance wise to add a listener to each JTextField you have. Joshua Marinacci who is a member of the Swing team at Sun wrote a book called Swing hacks where he explains in one of the hacks how to do it. There should be a method to do that instead ex. JComponent.setRightClickEnabled() for example.
>
> > I also think Java could
> > benefit a lot from being Open Source so pure Open
> > Source people will use it on the server instead of
> > PHP and use Java instead of Mono on the desktop
> side
> > but isn't it too late?
> This will never happen, SUN will not give away their
> one and only future plan away for free. They invested
> millions of dillars, I would rather help to improve
> already existing implementations like GNU classpath.
>
> lg Clemens

gfx
Offline
Joined: 2003-06-14
Points: 0

Why don't you use AWT's FileDialog?

swpalmer
Offline
Joined: 2003-06-10
Points: 0

> Why don't you use AWT's FileDialog?

AWT's FileDialog is missing critical features.

The most notable are:

- the inability to set chooseable filters,

- the fact that the existing option of single filter doesn't work on Windows
From the JavaDoc: [i]public void setFilenameFilter(FilenameFilter filter)
Sets the filename filter for this file dialog window to the specified filter. Filename filters do not function in Sun's reference implementation for Microsoft Windows.[/i]
(so no filtering is possible at all on Windows)

- the inability to set the text on the approve button

etc..

FileDialog just isn't robust enough to use on Windows at all.