Problems with Swing on Kaffe

[Nathan Meyers]

Glynn Clements wrote:

> Peter C.Mehlitz wrote:
>
> > > plus you wouldn't break existing applications.
> > > Aren't those methods on Toolkit you choose not to implement
> > > required by the PersonalJava standard you claim to conform to?
> >
> > Since peers are completely "hidden" implementation, it shouldn't break any app.
> > The Toolkit createXX methods are protected, and I don't see how they would be
> > used by apps.
>
> Correct me if I've misunderstood what's going on here, but all of the
> java.awt.* `widget' classes work by calling methods of the peer which
> they create (using `getToolkit().createFoo(this)') in their
> addNotify() method.
>
> How can a Toolkit be implemented without providing classes which
> implement the Peer interfaces?
>

The way Swing does it: by opening a bare-naked window and rendering the
components into it. A Swing button is not a Motif/Win32 button. It isn't
even a subwindow in your GUI. It's just some designated real estate in
the GUI; the toolkit takes care of figuring out when something is
happening that affects the component -- such as clicking a mouse button
over the real estate belonging to a GUI button.

An unfortunate side-effect of lightweight components is a big increase
in network traffic and load on the application; a lot of things that are
handled by the X server when heavyweight windows are used (for example,
sending mouse events for a small button in a big GUI) now must be
handled by the potentially remote X client.

There's actually a nice middle ground between using peer toolkits and
using lightweight components -- don't use the native toolkits; do your
own toolkit but let the components have their own windows. Works for Tk.

Nathan Meyers
nmeyers at teleport.com