> From: Jason Osgood [mailto:[EMAIL PROTECTED]]
>
> <snip>
>
> 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.
>
Here's my view of the situation (disclaimer: I am not an AWT expert):
Controls like buttons, text boxes, dropdowns, etc. could probably be done in
a lightweight manner since they always require a parent window to live in.
As long as you can draw in the parent window and intercept keyboard and
mouse events, you can emulate every bit of behavior that existing Windowing
systems do for these components.
Graphics is more of a hardware interface than a heavyweight peer. It
doesn't send events and users don't interact with it. Plus, you have to
have an interface to native code at *least* to be able to draw a pixel.
Graphics is as good a place as any to do that.
Top-level windows (Frames, Dialogs, etc.) still need heavyweight peers under
current OSs. Unless we control the entire desktop, we cannot accurately
simulate their behavior.
Now, on projects like JOS it *will* be possible not to have heavyweight
native peers for anything except Graphics because the desktop could be
written in Java and therefore could create the correct placement of
heavyweights. For existing OSs we could create our own single top-level
window as a little desktop-within-the-desktop. Would make a nice second AWT
implementation once we get this first set out of the door.
--John
