<Swing Dev> Gtkjfilechooser: new release 1.4

[Pavel Porvatov]

Hi Costantino,
> Hallo everyone,
>
> I've just released the new version of gtkjfilechooser, an effort to
> emulate the actual GTK File Chooser in the GTK L&F:
>   http://code.google.com/p/gtkjfilechooser/
>
> On the project site you can find a detailed description with some
> screenshots and a running demo.
> In this version I've fixed some bugs and updated to the GTK+ 2.18 changes.
> I've also extended the testing platforms, that now are:
>     * Fedora 12
>     * Ubuntu 9.10
>     * OpenSuse? 11.2
>     * OpenSolaris? 2009.06
>
>
>   
First of all thanks for your effort. I downloaded your project and took 
a look at it. Below are several comments:
1. Some tests failed

2. While searching in GtkFileChooser I got the following error:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at 
javax.swing.DefaultRowSorter.convertRowIndexToModel(DefaultRowSorter.java:518) 

at javax.swing.JTable.convertRowIndexToModel(JTable.java:2659)
at javax.swing.JTable.getValueAt(JTable.java:2734)
at 
eu.kostia.gtkjfilechooser.ui.FilesListPane$FilesListRenderer.getTableCellRendererComponent(FilesListPane.java:566) 


3. Take a look at the attached screenshot with with your component 
(right) and
native one (left, Ubuntu 9.10). You can see that:
a. you used incorrect icons
b. 42 Gb disk is missed
c. Documents, Music and other folders should be hidden
d. the button with "<" (in top left corner) should be removed

4. The GtkVersion class: it's a tricky method to determine Gtk version 
via the java.lang.ProcessBuilder class. Native code will look more natural.

5. The Wildcard class: why don't you use regular expressions here?

6. Can the eu.kostia.gtkjfilechooser.UrlUtil#encode method be replaced 
by the java.net.URLEncoder#encode one?

7. The Platform class looks tricky as well. That class should be 
implemented in a native code IMO

> @Pavel:
> As you know, I want to donate this project so that it can be
> integrated in the OpenJDK. I've linked the project on java.net, sent
> to SUN the Contributor Agreement (SCA) but until now, nobody has
> manifested interest.
> It's really a pity, because this is a very annoying bug for the GTK
> L&F and my gtkjfilechooser is already almost "feature-completed".
>   
As you can see it's very difficult to implement native GtkFileChooser on 
Java. There are a lot of native resources that can be placed in 
different places in different Linux distributives. You should also keep 
in mind that new minor versions of GTK file chooser can gain new 
features, which should be implemented in java file chooser as well. 
Sometimes it's very difficult to do (e.g. on Windows you can pop up File 
Properties window from the native file chooser with a lot of system 
information). I would suggest also to take a look at Windows 7 native 
file chooser as well... Is it a good idea to implement Windows 7 native 
file chooser on Java!?

This topic has been discussed in the Swing and AWT teams for some time. 
By this time these considerations drove us to the following idea: the 
java.awt.FileDialog class should be improved instead of implementing all 
possible LAFs of file chooser (for example we need GTK, KDE, Windows 
Vista and Windows 7 LAFs)...

I do not think this GTKJFileChooser would be a good candidate for JDK7
time frame by the reasons I described above, although we may reconsider
this in the following releases. Does it make sense?

Regards, Pavel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot.png
Type: image/png
Size: 58090 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20091214/84c84326/Screenshot.png>