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 _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
