Re: Question about implementing java.awt.Toolkit.createComponent for lightweights

[Scott Gilbertson]

> "Scott Gilbertson" <address@hidden> writes:
>
> > I submitted the following patch for GCJ, but there's been some
discussion
> > about whether it's OK.  I'm hoping someone on the Classpath project has
> > either already thought about the issue or can provide an opinion.
> >     http://gcc.gnu.org/ml/java-patches/2003-q2/msg00140.html
> >
> > The patch implements java.awt.createComponent, so that lightweight
> > components and containers work (as would presumably be required for
swing).
> > The above link includes a test class which works with the patch but not
> > without it.
> >
> > Questions:
> >
> > Is it right for java.awt.Toolkit to implement createComponent, or should
it
> > return null and leave the implementation up to the platform-specific
peers
> > (GtkToolkit, XToolkit, etc.)?
> >
> > If my patch is OK, should it go in Classpath first, rather than directly
> > into GCJ?
>
> Either is okay if it is accepted in one of them.  I thought I
> responded to this on the gcj list some time back.
> Brian Jones

So far the patch has not been accepted.  See the java-patches list:
http://gcc.gnu.org/ml/java-patches/2003-q2/msg00140.html
http://gcc.gnu.org/ml/java-patches/2003-q2/msg00197.html
http://gcc.gnu.org/ml/java-patches/2003-q2/msg00221.html

I was unable to descern from your earlier comments whether or not you agree
with the approach taken in the patch.  Maybe I'm just being thick, but I'm
really looking for "yes, this patch should go in" or "no, it shouldn't go
in, and here's why".  To continue the previous thread, here's your most
recent comment on the subject from the java list:

> It's the same peer, i.e. we don't implement a peer specifically for
> Container, the one provided for Component does just fine.  The extra
> functionality of maintaining a sequence of added children is just that
> and not part of the peer.

This sounds like a description of what my patch does, except that Container
relies on Container-specific peer methods, even without my patch, and
therefore can't use ComponentPeer.  The patch makes
java.awt.Toolkit.createComponent return a gnu.java.awt.GLightweightPeer,
which I've modified so it will work for both Component and Container by
implementing both peer interfaces.  In the libjava code (I'm assuming
Classpath is the same), Container requires a ContainerPeer and Component
requires a ComponentPeer, which aren't (without my patch) the same thing.
The ContainerPeer interface has methods for insets and layout, which aren't
required by Component.  In the heavyweight case the ContainerPeer methods
are implemented for the specific platforms so that you can, for example, use
native methods to allow the underlying windowing system to manage insets.
The ContainerPeer methods are therefore necessary.

Tom Tromey's main objection to the patch seems to be his assertion that it
should be toolkit-specific (i.e. it should go in xlib, gtk, etc. - see
http://gcc.gnu.org/ml/java-patches/2003-q2/msg00197.html).  I disagree,
because I claim lightweights are supposed to be platform-independent,
relying exclusively on public members of the heavyweight component classes
to do the platform-specific work.  So the real question is whether it's OK
for the combined Component/Container lightweight peer to be defined as I've
done, or whether it needs to be made platform-specific.  If it's OK as-is,
then I need to convince Tom of that so he'll accept the patch.  If not, I
need to change it.  Which is it, in your opinion?

Thanks.