Jason Osgood wrote:
>
> However... An old idea came out of our exchange. When Deep Throat and
> I first met back in '95, we both marveled at AWT's heavy weight peer
> implementation. We both felt that AWT components (and Graphics methods)
> should be "lightweight", like Swing is today.
>
> So... I'm curious to see if an AWT can be written WITHOUT heavy weight
> native peers. In other words, an AWT emulator. My Deep Throat believes
> it would be much more efficient than the current design. (You remarked
> on the event round tripping earlier.) Also, cross platform
> descrepancies would mostly go away. Lastly, Swing would continue to
> work since the "lightweight" AWT would be functionally equivalent to
> JDK's AWT.
>
> What would a lightweight AWT emulator look like? The font stuff in
> Graphics would have to be in software. How much work is that? I think
> interoperability with native drag-n-drop would be feasible. My
> impression is the threading issues would be MUCH simpler. Some
> packages, like Java2D, Java3D and the Magician OpenGL bindings, may
> need heavyweight peers. (Magician has a lightweight component
> solution, I cc'd Alligator for his comments.)
Something that I wondered a while ago, and got negative responses (along
the lines of "someone tried it and it turned out to be horrible") was
implementing the "heavyweight" AWT widgets as calls into the Swing
widgets. For example, java.awt.button would create a JButton as it's
"peer" and dispatch all its calls to that. In effect, Swing becomes the
native toolkit.
I think this would be a cool idea, but only if I'm remembering wrong
about it sucking.
Stuart.
