> On Tue, 2006-02-21 at 14:52 -0500, Scott Gilbertson wrote:
>
> > 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 ...
> >
> > 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.
>
> I made these changes to the patch. I changed back
> Toolkit.createComponent to return an instance of
> LightweightComponentPeer and I fixed the comment. Below is the updated
> ChangeLog. Attached is the updated patch.
Looking back, I see the ambiguity in my previous email.
The structure I had in mind was:
class LightweightComponentPeer
implements LightweightPeer, ComponentPeer
{
// (as now, including the repaint implementation)
}
// New class:
class LightweightContainerPeer
extends LightweightComponentPeer
implements ContainerPeer
{
// ContainerPeer-specific methods that used
// to be in GLightweightPeer
}
// Base java.awt.Toolkit creates generic lightweight peers for
// both Containers and non-Containers, restoring the
// functionality that used to be there.
// (overridden for GTK, but not for QT or XLIB)
class Toolkit
{
protected LightweightPeer createComponent(Component target)
{
if (target instanceof Container)
return new LightweightContainerPeer(target);
return new LightweightComponentPeer(target);
}
}
