Any ideas on lightweight component support (probably important for swing)?

Scott Gilbertson scottg@mantatest.com
Mon Apr 21 17:27:00 GMT 2003


I submitted a small patch a while ago entitled: "Patch:
GLightweightPeer,LightweightPeer,Toolkit allow creation and display of
lightweight components"
(http://gcc.gnu.org/ml/java-patches/2002-q4/msg00344.html).  The problem I
was trying to solve is that you couldn't create a lightweight component,
because java.awt.Toolkit.createComponent returned null so you'd get a
NullPointerException.  I think this problem will need resolution in order to
implement swing, which uses lightweight components.  I also needed it for my
awt application, which uses tons of custom lightweights (as do many awt
applications).  The patch hasn't gone in yet, due to concerns about whether
I took the right approach.

I'm wondering if anyone knows a better approach than the one I took.

The logic of my patch is as follows.  The 1.4.0 javadoc (repeated at the end
of this email) says createComponent creates a LightweightPeer that works for
both Component and Container.  We have a ContainerPeer interface, which
extends ComponentPeer.  I therefore figured we needed to make
LightweightPeer an extension of ContainerPeer (rather than ComponentPeer)
and return a LightweightPeer from createComponent.  This meant I had to add
the ComponentPeer methods to the unused GLightweightPeer class (which
implements LightweightPeer), and make createComponent return a
GLightweightPeer.  Since LightweightComponent doesn't depend on which
toolkit you're using, it seemed reasonable to implement it in the base
java.awt.Toolkit class, rather than in XToolkit, GtkToolkit, etc.

It may seem strange to implement both the ContainerPeer and ComponentPeer
interfaces in GLightweightPeer, but I think it's necessary in order to meet
the "Creates a peer for a component or container" requirement from the 1.4.0
javadoc.

Does anyone see a flaw in this logic, or perhaps know of a cleaner way to
get LightweightPeer working?

Looking back at my patch, which makes only one instance of GLightweightPeer
and always returns that, it might have been clearer to return "new
GLightweightPeer ()" from createComponent, and make GLightweightPeer.insets
a non-static field.  I don't recall why I did it the other way up.  Perhaps
I made only one GLightweightPeer because it didn't have any fields, then
realized it needed insets and put a "clone" in getInsets, more-or-less
imitating what happens in Container.getInsets if there's no peer.  Dumb
idea, I think, because any changes you make to the values in the insets
won't stick.  I'd be happy to resubmit the patch with "new GLightweightPeer
()"  and no "clone", and will probably do so in the absence of advise to the
contrary.

createComponent javadoc from jdk 1.4.0:
-------------------------------------------
protected java.awt.peer.LightweightPeer createComponent(Component target)
Creates a peer for a component or container. This peer is windowless and
allows the Component and Container classes to be extended directly to create
windowless components that are defined entirely in java.




More information about the Java mailing list