<Swing Dev> Gtkjfilechooser: new release 1.4

[Pavel Porvatov]

Hi Costantino,
> Hallo Pavel, Hallo everyone
>
> 2009/12/14 Pavel Porvatov <Pavel.Porvatov at sun.com>:
>   
>> 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 don't know if it's a good idea to emulate the native L&F with Swing
> instead of using directly native code with AWT.
> Anyway that's the philosophy of Swing and the GTK L&F already exists
> and we must do something to improve the current FileChooser (it's too
> outdated!).
> My project is a concrete attempt to solve this annoying issue... If we
> solve this problem with java.awt.FileDialog, I'am also happy ;-)
>   
We believe that attempts to mimic all native file choosers by 
JFileChooser is not a right approach. Currently JFileChooser looks like 
native GTK application
under GTK look and feel. At the same time it's not an exact copy of 
native file dialog (we already miss Windows Vista and
Windows 7 like JFileChooser, as well as different linux distros file 
choosers). Swing doesn't have a goal to make a full copy of native 
compound components.
This is the library that allows you implement them if needed.

Would you prefer to use native GTK file dialog if it had been 
implemented in the java.awt.FileDialog class? Would you be interested to 
participate in it?

Regards, Pavel
>> 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?
>>     
> When I wrote that my GTKJFileChooser is almost "feature-complete", I
> meant that it is quite usable (on Fedora quite much).
> Of course there is still some work to do, but I think the current
> state is a good start point.
>
> IMO the issues that you listed aren't critical and they can be fixed
> reasonably fast with a little effort and cooperation of other people.
>
> This new GTKJFileChooser can be also be included in a following
> OpenJDK release: we must only decide, if it makes sense to continue
> this effort and how.
>
> If there are other people in this mailing list that are interested in
> this project, please write your opinions and we can elaborate a better
> strategy for the future steps.
> For example I can also move the source code on java.net and give you
> commit right.
>