Making shared objects with GCJ

Tue Jun 15 15:48:00 GMT 2004

Robin Rawson-Tetley wrote:
>When the classpath folks have a correctly architected, working
>implementation of Swing, SwingWT still fulfils a role. The whole point
>of Swing is that you have a consistent look and feel across all
>platforms by only using Window/Canvas peers and doing the rendering in
>Java. SwingWT is about driving native widgets so your Swing app looks
>correct for the platform it is on. Two very different design goals.
>>
Classpath's Swing implementation should not neccessarily be limited to 
using the same L&F across platforms. Since Swing was designed for 
pluggable look & feels, there is no reason why native toolkits can't be 
used to implement Swing, just like SwingWT and Apple's Swing 
implementation on OS X. Although not having to worry about platform look 
& feel differences may be nice for developers, its the major reasons 
users tend to dislike Swing applications. Without real native widgets, 
they are inconsistent at best and ugly at worst.
Of course, the initial implementation of swing will likely use a simple, 
non-native PLAF since that is likely going to be the most simple to 
implement, however we would welcome anyone who wants to work on 
native-toolkit PLAFs.
Regards
Bryce