This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]