GTK+ peer for Swing. -WAS- Re: Making shared objects with GCJ

[Bryce McKinlay]

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