> > // New class:
> > class GtkLightweightContainerPeer
> > extends LightweightComponentPeer
> > implements ContainerPeer
> > {
> > // ContainerPeer-specific methods that used
> > // to be in GLightweightPeer
> > }
>
Are you saying you don't think we need class
gnu.java.awt.peer.LightweightContainerPeer?
I'm a little confused, because I see that in your reply it changed to class
GtkLightweightContainerPeer in the quoted text, although it needs to be
LightweightContainerPeer for the Toolkit.createComponent code to work.
Maybe that was just a typo?
> Some methods, such as show/hide/setVisible/setBounds/...etc cannot be
> no-ops. This is why it is implemented this way.
The existing GLightweightPeer class contains trivial implementations of all
the ContainerPeer methods, which are adequate for many non-trivial
applications, even using the minimal (or "lean and efficient", depending on
your point of view) xlib peers in GJC's library.
GtkLightweightContainerPeer may of course include more elaborate
implementations of those methods, specifically for use with GTK. In order
to make LightweightContainerPeer work the way GLightweight peer currently
works, it needs to contain those implementations, namely:
private Insets containerInsets;
public Insets insets()
{
return getInsets ();
}
public Insets getInsets()
{
if (containerInsets == null)
containerInsets = new Insets (0,0,0,0);
return containerInsets;
}
public void beginValidate()
{
}
public void endValidate()
{
}
public void beginLayout()
{
}
public void endLayout()
{
}
public boolean isPaintPending()
{
return false;
}
