AWT/Swing

[Sven de Marothy <sv...@physto.se>]

PJ Cabrera <pj...@alias.hotpop.com> wrote:

> And a big problem it is. If we go with GNU Classpath as the basis of the
> Harmony API, AWT and Swing will depend on GTK+ 2.4 being installed on
> OSX, through DarwinPorts or Fink. 

You're welcome to code some OS X peers if you want. This was already 
addressed in previous emails. It's not like Classpath has a GTK-only policy.

I'm currently hacking on a set of Qt4-based peers. So there.

> In my not so humble opinion, SwingWT is a better alternative, as it uses
> SWT to implement Swing. 

You're opinion should be more humble. It's an awful alternative.

Ok.. let's see:
1) - You need a full AWT implementation, not just Swing. Real-world apps rarely
use Swing only. Many mix Swing and AWT components freely. So you're going to need AWT anyway.  

2) - You can't ever achive a 100% compatible Swing using heavyweight widgets, the
API is designed around the fact that Swing components are lightweight and written in java.

= There is no point in developing Swing as heavyweight, you're going to need to do 
the same effort for implementing AWT anyway.

And that's just the widgets, folks! Then you've got the bigger issue: Java2D.

SWT does not, can not and will not support everything Java2D does. It's simply 
beyond the scope of what SWT aims to do, and it's certainly beyond Motif.

I'm not saying implementing AWT on SWT (or motif, which the JDK support) is impossible. 
But that requires a LOT of work on your part. Off the top of my head, some of the things
you'll probably run into trouble with is:

1) Text layouting including Unicode bidirectional text support

2) Glyph rendering, including hinting, custom kerning, and such.

3) A system for rendering of vector graphics, including porter-duff 
compositing *and* support for custom compositing methods, affine transforms, 
clipping to arbitrary vector paths and antialiasing.

4) Glyph manipulation within the framework in 3)

5) Retrieval and manipulation of laid out text as vector graphics paths.

6) Do all the above in a device-independent manner, including printing, 
on-screen drawing and off-screen drawing to *at least* the 13 different predefined pixel
formats in BufferedImage.

7) Hardware-accelerated bitmaps, and drawing support here too.

SWT just isn't up to that task.

Now for OS X, you can do a nice set of peers implementing all the above on Aqua. For Windows,
I'd target Avalon. GTK+Cairo isn't quite up to the task either, but it's getting there. 
Qt4 is mostly up to the task. But if you want Motif support, you're going to to implement all
that on your own. (or cobble together freetype and whatever and write your own GUI toolkit.)

> And on Windows and Mac OS, SWT uses native widgets. So the majority of
> those users don't have to go through complicated or unnecessary
> installations/incantations just to run a fully-certified FOSS JVM.

So write more AWT peers. But SWT is not a viable option. Unless you're pepared to code
all that above in Java, rendering to bitmaps and just using SWT to draw them. But that's 
even more work. That means approximately re-implementing Apple Quartz, 
or Cairo+Pango+Freetype, or Qt4 in Java. Get the picture of the scale of the task?

(Not that I'm against doing it. But given that there *are* native toolkits which already support
this stuff, it seems like much effort for little gain. It wouldn't make for faster AWT either.)

/Sven

Re: AWT/Swing

[Sven de Marothy <sv...@physto.se>]

> Now for OS X, you can do a nice set of peers implementing all the above on Aqua. 

Sorry, I meant Quartz of course, not Aqua.

/Sven