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

["Scott Gilbertson" <scottg at mantatest dot com>]

> "Scott Gilbertson" <scottg at mantatest dot com> writes:
>
> > > scott >  I therefore figured we needed to make LightweightPeer an
> > extension
> > > scott >  of ContainerPeer (rather than ComponentPeer) and return a
> > > scott >  LightweightPeer from createComponent.
> > brian > I think this is wrong.  A LightweightPeer is not necessarily a
> > brian > container, though you may implement a container based upon one.
> scott > In that case, where does java.awt.Container get its peer in the
> scott > lightweight case?  There is no createContainer method in
> scott > java.awt.Toolkit.  Should Container create its peer directly
> scott > (without using Toolkit)?
brian > It's the same peer, i.e. we don't implement a peer specifically for
brian > Container, the one provided for Component does just fine.  The extra
brian > functionality of maintaining a sequence of added children is just
that
brian > and not part of the peer.

> we don't implement a peer specifically for Container...
Yes we do, in classes which implement java.awt.peer.ContainerPeer.

> It's the same peer
Right, but only with the patch, which makes GLightweightPeer implement both.
This way a Container can do createComponent and get an applicable peer.  Try
creating lightweight Containers and Components without my patch, and the
program either crashes or fails to paint, depending on what other patches
you have.  The same program will work fine in the JRE.  The attached program
should illustrate the problem.  It probably won't work using any of the
gcj/libjava code in cvs, but it works fine with my patched libjava and also
in the JRE.  The program pops up a window containing some triangles.

I think the key points are:
java.awt.Component requires a java.awt.peer.ComponentPeer, even when
lightweight.
java.awt.Container requires a java.awt.peer.ContainerPeer, even when
lightweight, so that, for example, the getInsets method won't crash.
Without my patch, both are only implemented together in the heavyweight
case - GLightweightPeer only implements ComponentPeer.
XPanelPeer (heavyweight), for example, ultimately implements both.
GLightweightPeer does not, so lightweight Containers don't work.
Furthermore, without the patch, java.awt.Toolkit doesn't create a peer for a
lighweight Component.  It returns null.  You therefore get an exception or
failure to paint, as I described earlier.

I suppose in theory GLightweightPeer could be modified to implement both
ContainerPeer and ComponentPeer, without making either of those interfaces
extend the other.  This approach would rely on casting in Container to get
the container-specific methods.  Come to think of it, that's essentially
what happens with heavyweight Containers. You'd still have the slight
problem that a lightweight Component's peer would be reserving a pointer for
insets, even if the Component is not a Container, but that's pretty trivial.
Would that be a better approach?

Attachment: Light.java
Description: Binary data