> www.gjt.org
> CVS dir
> java/org/gjt/shark
I'll check it out, I'm there too. Isn't everything on GJT LGPLed?
> Actually it turns out you can have several levels of abstractionI have
> drivers directly on top of the hardware and yes the driver is
> non-portable
Very nice. I figured (hoped) i
Paul Fisher wrote:
> "Daniel Rall" <[EMAIL PROTECTED]> writes:
>
> > Yeah, same here. I vote for doing away with heavyweight peer
> > components all together and having the AWT simply wrap the
> > lightweight JFC components.
>
> The GTK+ heavyweight peers are almost complete. We're not going to
"Daniel Rall" <[EMAIL PROTECTED]> writes:
> Yeah, same here. I vote for doing away with heavyweight peer
> components all together and having the AWT simply wrap the
> lightweight JFC components.
The GTK+ heavyweight peers are almost complete. We're not going to
just throw them away. They wor
> - What is the point of the peer architecture? If each peer has a
> non-peer counterpart, why not do everything directly in the non-peer?
> (I've been wondering the answer to this question ever since I first
> learned the AWT)
Yeah, same here. I vote for doing away with heavyweight peer compon
Kimberley Burchett <[EMAIL PROTECTED]> writes:
> - What is the point of the peer architecture? If each peer has a
> non-peer counterpart, why not do everything directly in the
> non-peer?
It's easier to port that way. The peers provide the native layer, and
the non-peers provide the Java layer
Kimberley Burchett wrote:
> I have a few questions before I volunteer to help with the AWT:
Thanks for writing!
> - What is the point of the peer architecture? If each peer has a
> non-peer counterpart, why not do everything directly in the non-peer?
> (I've been wondering the answer to this q
6 matches
Mail list logo