SWT and AWT

[Andrew Haley <aph at redhat dot com>]

Stanley Brown writes:
 > Andrew Haley wrote:
 > 
 > >We do use SWT.  However, we need AWT for projects that already use it.
 >
 > A bit of a misunderstanding.  I was talking of using SWT as the parent 
 > to AWT.  So a AWT button would be nothing but a thin layer over a SWT 
 > button.

I see, yes.  Unfortunately SWT itself isn't very portable at the
moment.  Just try running it on a 64-bit system, for instance.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=37775

 > >There would be no sense in incorporating the SWT sources with libgcj;
 > >besides which, the licences may not be compatible.
 >
 > SWT falls under CPL (Common Public License) which states that it
 > cannot be rolled with a GPL program without their permission.  I
 > don't see that happening.  So your right in that you cannot include
 > the SWT source code in the GCJ tree.  But the question is, do you
 > need the source with GCJ?  If you were compiling the GCJ AWT/Swing
 > classes you would but there is nothing stopping someone from
 > downloading these from Eclipse separate from GCJ.

Okay, but we can't require SWT in order to build libgcj.

 > Programmers would only have to ensure they have the swt jar file
 > and shared lib if they were creating a AWT/SWT/Swing application.

Sure, and people already do that.

 > This is straying down a very touchy subject.  Most open source
 > projects don't want dependencies to projects that fall under a
 > different open source license.  This is understandable and I wont
 > waste time arguing against it.  Creating a thin layer over SWT to
 > get AWT is interesting but is still a lot of work.  What would be
 > real sweet is a SWT project under GCJ that uses CNI instead of JNI
 > and fits with its license.  Thats even more work....

The SWT folks are talking about automagically generating the native
part of SWT from the Java part.  (i.e. read OS.java and generate
structs.c.)  Given that, writing a CNI version would be easy enough.

Andrew.