This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Making shared objects with GCJ
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