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: 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


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