Interrupted IO and AWT

[Paul Fisher]

Jeff Sturm <jsturm@sigma6.com> writes:

> Let's say somebody wants to use gcj to write desktop apps for KDE or
> Gnome.  How would they best proceed?

Currently, using the standard Java AWT API is their best bet, with the
GTK+ Peer libraries from Classpath.  There's also the `java-gnome'
project <URL: http://www.lirmm.fr/~gutkneco/devpt/javagnome.html >,
which provides Java bindings for the GTK+ and Gnome APIs.

I read somewhere recently that the KDE project has started work on a
set of Qt AWT peers, but I don't have a URL handy.

> The PLAF's are a bad idea because they don't leverage a native
> toolkit, they attempt to reimplement it in Java.

There's no reason why a Swing PLAF couldn't be written that does
leverage the native toolkit.  (A GTK+ Swing PLAF is on the TODO list
for Classpath).

> AWT isn't so good either because it doesn't leverage much of the
> capability of good toolkits out there... e.g. there is no tree
> widget or image button in AWT.

Strictly speaking, it's permissible for getGraphics to return a valid
Graphics object for any Component.  The peer side, however, is only
required to return a valid Graphics object for Canvas and Container.
So, it is possible (and legal) to doodle on random widgets, assuming
the peer implementation supports it.

> Then implement AWT and (possibly) Swing atop this native API to be
> compatibile with other Java applications.

Swing, by design, only depends on the basic drawing primitives of the
AWT.

I don't believe it would be feasible to actually implement Swing using
GTK+ or Qt (for example, directly mapping the Swing tree widget to
GTK+'s tree widget).  However, I've often thought about this
possibility; it's certainly appealing.