I wonder if you could have a look at this change, half of which I claim is related: http://developer.classpath.org/pipermail/classpath/2006-February/000157.html
I originally submitted it for GCJ (hence the superfluous "libjava/" on all the paths), but it needs to go in Classpath before checking in there, so merging doesn't get out of control. I haven't been able to get Classpath+JamVM to work, so I've been unable to test it in order to submit a Classpath patch. I'm working with the xlib peers on GCJ (so I'm not really in a position to pass judgement on GTK peer code), but my changes referenced above affect GTK peers as well. Here's my test program, which fails without my patch using GCJ + Classpath 0.20 (as merged into the GCJ tree), with both xlib and gtk peers: http://gcc.gnu.org/ml/java/2006-02/msg00048/LightweightRepaintTest.java Your patch still has createComponent returning a GLightweightPeer when the Component is not a Container (as in my test program), and I claim there's a problem with GLightweightPeer, so it wouldn't surprise me much if my test program still fails with your patch. I'd be overjoyed if you'd include my changes and ultimately check them in, since I could then do the same for GCJ. ----- Original Message ----- From: "Lillian Angel" Sent: Tuesday, February 21, 2006 10:28 AM Subject: [cp-patches] RFC: LightweightPeers reworked > Hello, > > Tom F. and I worked on changing how we handle Container lightweights and > Component lightweights. This bug showed up in MegaMek and several test > cases. It appeared that Containers should be handled differently. > > When a Container was placed in a Window, and contained Heavyweight > components, the location of the components were always being set at > (0,0), relative to the Window. This is because the components were not > aware of the bounds of the Container. Now, GtkLightweightPeer is similar > to a GtkPanelPeer. > > GtkLightweightPeer extends GtkContainerPeer. This fixes the problem. We > discovered that we could not completely get rid of GLightweightPeer > because Components still depended on its constructor. > > I tested this with the swing demo and MegaMek. The painting seems to > work fine still... > > Feel free to give me feedback before I commit this. > > 2006-02-21 Lillian Angel <[EMAIL PROTECTED]> > > * gnu/java/awt/peer/gtk/GtkLightweightPeer.java: > New class to handle Container Lightweights. > * gnu/java/awt/peer/gtk/GtkPanelPeer.java: > Removed unneeded import. > * gnu/java/awt/peer/gtk/GtkToolkit.java > (createComponent): New method to override Toolkit's > createComponent. Returns an instance of GtkLightweightPeer > if the target is a container, and a GLightweightPeer if the > target is a Component. > * include/Makefile.am: > Added gnu_java_awt_peer_gtk_GtkLightweightPeer.h. > * include/gnu_java_awt_peer_gtk_GtkLightweightPeer.h: > New header file. > * java/awt/Toolkit.java > (createComponent): Changed to return null. This method > should be overridden. Added comment explaining why. > * native/jni/gtk-peer/Makefile.am: > Added gnu_java_awt_peer_gtk_GtkLightweightPeer.c. > * native/jni/gtk-peer/gnu_java_awt_peer_gtk_ > GtkLightweightPeer.c: New class. > >
