Re: Patch: GLightweightPeer,LightweightPeer,Toolkit allow creation and display of lightweight components

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

I've had a little discussion going on the main java list about my
lightweight component patch, which is the only one I've submitted that isn't
yet in cvs.  Thanks, Tom, for getting the rest of them in.  I'll try hard to
make sure my future patches are formatted correctly.

I concluded my latest reply with the following paragraph, which is based on
inspection of the class/interface hierarchy for XPanelPeer (as an example of
a heavyweight Container's peer).  I wonder if you could let me know what you
think of it, as well as the issues following it, and whether I ought to
resubmit the patch using the described approach.  I've also attached a small
program which I don't think will work on the unpatched libjava, but which
works fine with the patch as-is.  Thanks.

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?

Note that this approach still means you're returning a GLightweightPeer from
Toolkit.createComponent, which got a "This change we definitely can't put
in" reply earilier.  In fact, about a hundred other classes in the main java
tree reference classes in the gnu.java tree, but I suppose that doesn't
necessarily mean it's right.

In any event, I don't think createComponent logically belongs in XToolkit,
etc., because the lightweight components are by definition pure java, and
therefore don't depend on anything in the platform-specific Toolkit except
their nearest heavyweight parent, which has its own peer.

----- Original Message -----
From: Tom Tromey <tromey at redhat dot com>
To: Scott Gilbertson <scottg at mantatest dot com>
Cc: <java-patches at gcc dot gnu dot org>
Sent: Wednesday, January 15, 2003 3:10 PM
Subject: Re: Patch: GLightweightPeer,LightweightPeer,Toolkit allow creation
and display of lightweight components


> >>>>> "Scott" == Scott Gilbertson <scottg at mantatest dot com> writes:
>
> Scott> These changes allow creation and display of lighweight
> Scott> components by directly subclassing java.awt.Component and
> Scott> java.awt.Container.
>
> I'm not so sure about this change.  I'll look at it a little later
> today and see what is going on.
>
> Scott> gcc/libjava/java/awt/Toolkit.java
> Scott>  protected LightweightPeer
> Scott>  createComponent(Component target)
> Scott>  {
> Scott> -  return null;
> Scott> +  return gnu.java.awt.GLightweightPeer.INSTANCE;
> Scott>  }
>
> This change we definitely can't put in.  This makes the
> platform-independent Toolkit class depend directly on a particular
> lightweight peer implementation.  It seems to me that this function
> should be overridden in the platform-specific Toolkit, for instance
> XToolkit.  What do you think about that?
>
> That said, I don't understand why the GLightweightPeer class is in
> gnu.java.awt and not somewhere else.  So, I'm a little confused.
>
> Tom

Attachment: Light.java
Description: Binary data