ClasspathToolkit redesign.

[Sven de Marothy]

Hi all,
Ok, I've been looking into the issue of our AWT peer interface now that
I've been running my peers on Classpath in earnest.

The goal here is to try to bring our peer interface as close to Sun's
as possible. And simplify things for potential peer-authors.

First off, ClasspathToolkit provides dummy implementations for a bunch
of Toolkit methods (such as createImage(String), implemented on
createImage(URL)). *All* of these happen to be overloaded in GtkToolkit,
the only implementation. So I don't really see the point of this.
I suggest just dropping them. 

What remains then? Abstract methods, i.e. our extensions to the Toolkit
interface. Let's go through them:

Method: getLocalGraphicsEnvironment()
Comment: This is already done by
GraphicsEnvironment.getLocalGraphicsEnvironment(), which gets the
local one from the property "java.awt.graphicsenv". So this is
unnecessary. The peers should just be required to set that property
instead.

Method: getClasspathFontPeer(), getClasspathTextLayoutPeer(), getFont() 
Comment: We need these. No way around that. But they could perhaps be
put in a seperate ClasspathFontInterface or something.

Method: createFont()
Comment: Um, we don't even implement this ourselves. Sorry Sacha, but
there's no point. Right now anyway.

Method: createRobot()
Comment: This we need. But it's a rather singular item. Replace with a
property setting? Certain peers may not (or cannot) have Robots anyway.

Method: createEmbeddedWindow ()
Comment: What's an EmbeddedWindow and why do we need this as part of the
peer interface?

Method: registerImageIOSpis()
Comment: Unnecessary. The peers can register their SPIs (if they have
any) themselves without this.

Method: nativeQueueEmpty(), wakeNativeQueue(), iterateNativeQueue()
Comment: These are specific to how the GTK peers handles threads and
events, and should certainly not be part of the interface. The versions
of EventQueue using these methods should be reverted too. The GTK peers
should extend and overload EventQueue for their custom approach instead.

Summary: So, my opinion: Keep most of the font stuff and the robot
stuff. Get rid of the rest, and we'll have an interface which is both
closer to the JDKs, and simpler.

Comments?

/Sven