This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GTK+ peer for Swing. -WAS- Re: Making shared objects with GCJ
John Gabriele wrote:
If I'm understanding this discussion correctly, it's at least
partially about
lightweight/peerless vs. heavyweight/peer implementation. Personally,
I like the
idea of Classpath Swing using the GTK+ peer -- for execution speed,
simplicity,
and I'd guess it'd be much more easily/quickly implemented.
Unfortunately, I don't think using native widgets for Swing would
necessarily get us more speed. A native PLAF would still be subject to
the AWT's underlying design problems which cause poor performance in the
first place. As others have pointed out, however, performance issues are
slowly fading away as hardware gets faster and runtime technologies
improve (think gcj ;-). I don't think it would be easier to implement,
either - there are all kinds of issues that will crop up when mixing
native widgets into the Swing API.
Wait. If GTK+ runs on, say, Mac OS X. And it is implemented in terms
of Carbon
(the older Mac toolkit -- which looks "Mac-like" of course), and if
CP's Swing
uses the GTK+ peer, that's a "native-LAF", right?
The official GTK+ works on OS X, but it run's on top of the X layer, ie
it looks the same as it does on Linux. I think there are efforts to port
GTK to the native OS X UI, and you could theoretically make Classpath's
GTK peers run on top of that. However, given the kind of "low level"
control needed to implement AWT, I suspect that having too many layers
of toolkits would cause more problems than it is worth. Every extra
layer would impact performance, too.
Regards
Bryce