On Wed, 2006-02-22 at 12:51 -0500, Scott Gilbertson wrote:
> > > // 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?
No. Maybe we need it, especially for consistency.
>
> 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?
Ah, i thought you made a mistake. I see what you are saying.
>
> > 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:\
Yes. That would be fine to add another class.
>
> 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;
> }
>
>
>
