RE: extended peers

[Sascha Brawer]

Brian Jones <address@hidden> wrote on Thu, 11 Sep 2003 08:39:32 -0400:

>I believe there used to be a system property which told the Sun JVM
>which peers to use, so for example if everything was implemented in this
>unpublished peer interface you could plug these into Sun's JVM. In that
>sense, the java.awt.peer classes act as the public facade to internal
>private peer implementations such as the GTK peers we have today.

Stephane Meslin-Weber <address@hidden> wrote on Thu, 11 Sep
2003 14:16:04 +0100:

>That property still exists, it's "awt.toolkit" and I use it for fbAWT
>and qteAWT... Note that PJA also uses it.

Actually, Classpath is also using the same property in the implementation
of java.awt.Toolkit.getDefaultToolkit().  So, here's another proposal:

package gnu.java.awt;

import java.awt.GraphicsEnvironment;
import java.awt.Toolkit;
import java.nio.ByteBuffer;
import gnu.java.awt.peer.ClasspathFontPeer;

/**
 * FIXME: Javadoc.
 *
 * <p><b>Thread Safety:</b> The methods of this class
 * may safely be called without external synchronization.
 * This also holds for any inherited address@hidden Toolkit} methods.
 */
public abstract class ClasspathToolkit
  extends Toolkit
{
  /**
   * Returns a shared instance of the platform-specific graphics
   * environment.
   * 
   * <p>Called by address@hidden
   * GraphicsEnvironment#getLocalGraphicsEnvironment()}.
   */
  public abstract GraphicsEnvironment getLocalGraphicsEnvironment();
  
  // inherited from java.awt.Toolkit:
  // public abstract java.awt.peer.FontPeer getFontPeer(String name, int
style);
  //
  // ClasspathToolkits must return an object that implements ClasspathFontPeer
  // in addition to FontPeer. Unfortunately, it is not (yet?) possible to
express
  // such restrictions in Java.

  public abstract ClasspathFontPeer getFontPeer(ByteBuffer buf);
}



package gnu.java.awt.peer;

import java.awt.peer.FontPeer;

public interface ClasspathFontPeer
  extends FontPeer
{
  // FIXME: Methods to be defined.
  // Is the name ok? "Peer" is shorter than "delegate", and "peer" is
  // the usual AWT lingo. "ClasspathFontPeer" also makes clear that it
  // extends "FontPeer".
}



package java.awt;

import java.awt.Toolkit;
import gnu.java.awt.ClasspathToolkit;

public abstract class GraphicsEnvironment
{
  private static GraphicsEnvironment localGraphicsEnvironment;

  public static synchronized getLocalGraphicsEnvironment()
  {
    if (localGraphicsEnvironment == null)
    {
      ClasspathToolkit ctk;

      ctk = (ClasspathToolkit) Toolkit.getDefaultToolkit();
      localGraphicsEnvironment = ctk.getLocalGraphicsEnvironment();
    }

    return localGraphicsEnvironment;
  }
}



This would have the side effect that retrieving the local
GraphicsEnvironment indirectly loads the Toolkit. I think this is desirable.

Also, there is some real code that could go into ClasspathToolkit.  An
example is maintaining the cache for Toolkit.getImage(String) and
Toolkit.getImage(URL), which (in contrast to the createImage methods) is
not platform dependent.

A disadvantage is that people cannot use Toolkits that are not
ClasspathToolkits. I don't think this is a serious problem, though.  But
we then should modify Toolkit.getDefaultToolkit() to check for this, so
errors get thrown early, not at some place deep in the graphics code.

Comments?

-- Sascha

Sascha Brawer, address@hidden, http://www.dandelis.ch/people/brawer/