Re: Gtkjfilechooser: new release 1.4

2009/12/28 Pavel Porvatov <Pavel.Porvatov@...>:
> I filed a new bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6913179, which we would
> like to have fixed in jdk7.

Hello,

I would follow this steps:
1. Write some C code to call the desired functions in GtkFileChooserDialog
2. Generate the JNI interface
3. Rewriting sun.awt.X11.XFileDialogPeer to call the native code through JNI

What do you think about? Do you have further suggestions?

Regards,
Costantino

Re: Gtkjfilechooser: new release 1.4

Hi Costantino,

Swing team members you are working with are on winter holidays until
Monday, Jan 11th. Hence there may be a delay with response for a few
days, sorry.

Thanks,
	Andrey.

Costantino Cerbo wrote:
> 2009/12/28 Pavel Porvatov <Pavel.Porvatov@...>:
>> I filed a new bug:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6913179, which we would
>> like to have fixed in jdk7.
> 
> Hello,
> 
> I would follow this steps:
> 1. Write some C code to call the desired functions in GtkFileChooserDialog
> 2. Generate the JNI interface
> 3. Rewriting sun.awt.X11.XFileDialogPeer to call the native code through JNI
> 
> What do you think about? Do you have further suggestions?
> 
> Regards,
> Costantino

hg: jdk7/swing/jdk: 6584033: (tz) wrong buffer length in TimeZone_md.c

Changeset: e9ccd1dd6923
Author:    andrew
Date:      2010-01-08 12:51 +0000
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e9ccd1dd6923

6584033: (tz) wrong buffer length in TimeZone_md.c
Summary: Add testcase for this bug
Reviewed-by: darcy, okutsu

+ test/java/util/TimeZone/TimeZoneDatePermissionCheck.java
+ test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh

getToolkit().getScreenInsets Ubuntu bug

Re: getToolkit().getScreenInsets Ubuntu bug

Re: getToolkit().getScreenInsets Ubuntu bug

Re: getToolkit().getScreenInsets Ubuntu bug

Bug 6913179: The java.awt.FileDialog should use native GTK file chooser on linux distros

Hello Pavel,

I hope you had a good holiday!

As said, I began to port the native GTK FileChooser in
java.awt.FileDialog (bug id 6913179).
You can get this initial code from (it's an eclipse project):
 svn checkout http://gtkjfilechooser.googlecode.com/svn/trunk/GTKFileDialog

Then type "make test" in your shell to run a simple demo.

I'd like now to integrate it with the real OpenJDK codebase, but I've
see that the GTK libraries aren't invoked through #include <gtk/gtk.h>
but through "gtk2_interface.h" (in
jdk7/mytl/jdk/src/solaris/native/sun/awt).
That means, I should extend this header file to accept also the
GtkFileChooser related functions that are in my
native/src/GtkFileDialogPeer.c.
Could you (or somebody else) please explain me, how to do that?

Besides I have the following questions/comments:
1) Maybe should we write a new class sun.awt.X11.GtkFileDialogPeer
instead of modify sun.awt.X11.XFileDialogPeer?
The old XFileDialogPeer will be continued to be used in system without
the GTK libraries. That means, we should modify
sun.awt.X11.XToolkit#createFileDialog(FileDialog) to return
GtkFileDialogPeer instead of XFileDialogPeer, if GTK is avalaible.
By the way, how can we check in the JDK the presence of GTK? (I think,
it's already done for the availability of the GTK L&F, but I could not
find how).

2) java.awt.FileDialog supports only the selection of files but not of
folders: Why don't we allow its method setMode(.) to accept also other
values than LOAD (0) or SAVE (1). For example we could pass the value
2 to allow only the selection of folders? It's a minimal change that
doesn't broke the existing API. On platforms where the new selection
mode for folders isn't yet implemented, the behaviour should be the
same as for the mode LOAD (0).

3) I could compile the entire OpenJdk 7 without problem, but when I
try to compile only the awt part, it fails with the error message in
the attached file (error.log).
My compile variables are set as follows:
  export LANG=C
  export ALT_BOOTDIR=/usr/lib/jvm/java-openjdk
  export ALT_BINARY_PLUGS_PATH=/home/c.cerbo/openjdk/openjdk-binary-plugs
  export ALT_JDK_IMPORT_PATH=/home/c.cerbo/openjdk/jdk7/mytl/build/linux-i586/j2sdk-image

I Hope this is all clear and this is probably the longest e-mail you
will receive from me! 

Cheers,
Costantino from Stuttgart

Re: getToolkit().getScreenInsets Ubuntu bug

This is pretty close to how getScreenInsets() is implemented in JDK7, so 
it should work fine for JDK6 and earlier JDK versions.

Thanks,

Artem

On 1/10/2010 5:07 AM, Paulo Levi wrote:
> Found a workaround - i think this should be fixed on awt really:
>
>      //workaround for java X11 issue (Toolkit.getScreenInsets) wrong values
>      *private*  *static*  ProcessBuilder panelWorkaround =*new*  ProcessBuilder("xprop","-root","-notype","_NET_WORKAREA");
>
>
>      *private*  *static*  *final*  *boolean*  isX11 =
GraphicsEnvironment.getLocalGraphicsEnvironment()*instanceof*  X11GraphicsEnvironment;
>
>
>
>      *private*  Rectangle getAdequateFullSize()*throws*  HeadlessException{
>          //bug in linux x11 binding (getScreenInsets not counting panels)...
>
>
>          *if*  (isX11){
>              *try*  {
>                  Process proc = panelWorkaround.start();
>
>
>                  String output = IoUtils.toString(proc.getInputStream(),*true*);
>                  String[] results = output.split("=");
>                  *if*  (proc.waitFor() == 0&&  results.length == 2){
>
>
>
>                      //first window
>                      String[] firstWindowProperties = results[1].split(",");
>                      *int*  x = Integer.parseInt(firstWindowProperties[0].trim());
>
>
>                      *int*  y = Integer.parseInt(firstWindowProperties[1].trim());
>                      *int*  width = Integer.parseInt(firstWindowProperties[2].trim());
>
>
>                      *int*  height = Integer.parseInt(firstWindowProperties[3].trim());
>                      *return*  *new*  Rectangle(x, y, width, height);
>
>
>                  }
>              }  *catch*  (Exception ex){
>                  ex.printStackTrace();
>                  *return*  getNormalAdequateSize();
>
>
>              }
>          }
>          *return*  getNormalAdequateSize();
>      }
>
>      *private*  Rectangle getNormalAdequateSize()*throws*  HeadlessException{
>
>
>          Insets i = getToolkit().getScreenInsets(getGraphicsConfiguration());
>          Rectangle max =*new*  Rectangle(getToolkit().getScreenSize());
>          max.x += i.left;
>          max.y += i.top;
>
>
>          max.width -= (i.left + i.right);
>          max.height -= (i.top + i.bottom);
>          *return*  max;
>
>
>      }
>
>

Re: Gtkjfilechooser: new release 1.4

Hi Costantino,

The fix actually belongs to the AWT, so I'm CC'ing the awt-dev <at>  mailing 
list where we can continue to discuss the topic.

On 1/5/2010 4:59 PM Costantino Cerbo wrote:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6913179, which we would
> 
> I would follow this steps:
> 1. Write some C code to call the desired functions in GtkFileChooserDialog
> 2. Generate the JNI interface
> 3. Rewriting sun.awt.X11.XFileDialogPeer to call the native code through JNI
> 
> What do you think about? Do you have further suggestions?

Generally we tend to avoid using loads of native code in the XToolkit. 
You can notice it by looking at the src/solaris/native/sun/xawt/ 
directory: there are just four files.

Would that be possible to take a similar approach with the enhanced file 
dialog fix?

Also, please have a look at 6757222 which is linked from the original 
bug report. It seems that both Swing and AWT could benefit if the 
interface to the GTK were shared among the libraries. Though that looks 
like a slightly bigger project.

--
best regards,
Anthony