Jason Osgood <[EMAIL PROTECTED]> writes:
> So... I'm curious to see if an AWT can be written WITHOUT heavy
> weight native peers.
You need some level of heavy weight native peers -- in order to
receive events from the underlying windowing system. So at a minimum,
you could get by with only Frames/Windows having peers.
While such a minimalist-peer system seems possible, I don't see it as
being very appealing to implement.
In fact, I find the current thinking on custom lightweight widgets
vs. windowing system provided widgets to be a little absurd. We have
significant groups of people moving in totally different directions.
On one hand, you have JavaSoft moving away from the OS widgets towards
lightweight widgets. In fact, when Java was being created, if Gosling
and the rest of the originals had known about the Tcl/Tk work being
done within Sun, we wouldn't have the AWT. Java would be using Tk.
By the time they found out about Tk, it was too late to switch.
Over in the Tk world, they're moving away from their custom widgets
towards OS widgets.
Over in Mozilla-land, they're trying to decide what's the best route
to take. They appear to be leaning towards a hybrid approach.
> My Deep Throat believes it would be much more efficient than the
> current design. (You remarked on the event round tripping earlier.)
Lightweights only rely upon the peers for receiving events. Java
handles screen placement, rendering, everything. I doubt it would be
inherently more efficient. You're moving windowing code away from the
X11 server (possibly hardware accelerated) and into software.
I don't know how it is on your system, but SwingSet is slow on my
computer. I love watching the screen redraw. :)
> Also, cross platform discrepancies would mostly go away.
You can also get rid of platform discrepancies by porting the native
toolkit. Gtk+ has already been ported to Win32, and it might
eventually have a Mac port.
> The font stuff in Graphics would have to be in software. How much
> work is that?
There's a big difference between using Swing to function mostly as an
AWT replacement (for widgets), and totally replacing all functions of
the peers -- most importantly -- the graphics context (GC), which is
what you seem to be advocating.
> I think interoperability with native drag-n-drop would be feasible.
> My impression is the threading issues would be MUCH simpler.
Gtk+ has already solved these problems for us. I'm not for
reinventing the wheel, especially when it means loosing important
functionality provided by the X11 server and Gdk.
On a side note, the Gtk+ peers are almost complete. :)
--
Paul Fisher * [EMAIL PROTECTED]
