Re: ClasspathToolkit redesign.

[Thomas Fitzsimmons]

Hi,

On Sun, 2005-07-24 at 00:19 +0200, Sven de Marothy wrote:

[...]

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

OK.

> 
> 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.

How could this be replaced by a property setting?

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

An EmbeddedWindowPeer is a wrapper around the native toolkit's
implementation of the XEMBED protocol.  gnu.java.awt.EmbeddedWindow
should use the current toolkit's XEMBED implementation, e.g. for GTK,
GtkPlug.  We'll need some way to create the peer dependent on the
toolkit.  Whatever we do for Robot can be done here too.

> 
> 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?

Yeah, this sounds good.

Tom