> From: "Thomas Fitzsimmons" > OK, a few comments: > > +public class LightweightComponentPeer > + implements LightweightPeer, ContainerPeer > > Does LightweightComponentPeer still need to implement ContainerPeer or > can it just implement ComponentPeer?
Just implementing ComponentPeer should be OK, except that it requires every peer Toolkit (in libjava, XToolkit for example) to do what GtkToolkit.createComponent does, namely return either a LightweightContainerPeer or a ContainerPeer subclass. The ideal situation would probably be to have: gnu.awt.peer.LightweightContainerPeer (implementing ContainerPeer) and perhaps subclass GtkContainerPeer from that. Then the base implementation of java.awt.Toolkit.createComponent could return either a LightweightComponentPeer or LightweightContainerPeer, depending on the type of Component. That way I wouldn't have to modify XToolkit, which does not override createComponent, the next time Classpath is merged into GCJ. Within the Classpath tree, QtToolkit doesn't override createComponent either, so it probably has the same issue. A related problem with the patch as it stands is that the comment at the top of the non-peer-specific class LightweightComponentPeer says to use a peer-specific class (GtkLightweightContainerPeer) for lightweight Containers. The comment is only reasonable for those using GTK peers.
