Re: extended peers

[Sascha Brawer]

graydon hoare <address@hidden> wrote on Wed, 10 Sep 2003 01:36:53 -0400:

>I would like to attach some extra methods to a singleton object of
>some sort -- something like Toolkit or GraphicsEnvironment, or a
>classpath-specific subclass of these -- to produce peer or peer-like
>(native-assisted subclass) objects for use in java2d.

I think this is an excellent idea. I guess it comes to the following:

- gnu.java.awt.peer -- abstract, platform-independent classes
- gnu.java.awt.peer.gtk -- your GTK/Cairo implementation
- gnu.java.awt.peer.(xxx) -- other implementations

package gnu.java.awt.peer;
abstract class GeneralGraphicsEnvironment
  // should this be "ClasspathGraphicsEnvironment"?
  // "CPGraphicsEnvironment"? "GNUGraphicsEnvironment"?
  extends java.awt.GraphicsEnvironment
{
  abstract GeneralFontPeer createFontPeer(java.awt.Font awtFont, double
size, ...);
}

package gnu.java.awt.peer.foo;
class FooGraphicsEnvironment
  extends gnu.java.awt.peer.GeneralGraphicsEnvironment
{
  GeneralFontPeer createFontPeer(...) { return new FooFontPeer(...); }
}

By the way, there are now some GDK/GTK-related classes in
gnu.java.awt.image. Could/should these move to gnu.java.awt.peer.gtk as well?

How will methods like java.awt.GraphicsEnvironment.getLocalEnvironment()
know about the right peers?
A test program for dumping System.getProperties() on Sun's J2SE 1.4.1
lists the following properties that sound related to graphics:

java.awt.graphicsenv = "sun.awt.X11GraphicsEnvironment"
java.awt.printerjob = "sun.print.PSPrinterJob"
sun.java2d.fontpath = ""

If we use the same system property 'java.awt.graphicsenv', where should
it get set?

>I know the java designers have currently decided that these things
>ought to all be done in "pure java" -- though they appear to be
>changing their minds yet again and moving over to hardware openGL --
>but I feel it is currently quite restrictive that, for example, we can
>have any sort of native-backed Graphics2D we like, on a
>toolkit-by-toolkit basis, but we must have only one class in all of
>classpath which is built when you ask for a new Font(...).

I fully agree with you.


>it would be much nicer if Font's constructor called a factory method
>to build an optional peer for the Font. of course, if null is returned
>then we can expect the Font to either work in pure java or fail -- as
>it currently does -- on certain operations.

Actually, I'd propose that the factory should always return a peer
object. This would make the delegating code (like java.awt.Font) simpler,
because it would not have to support a peerless case. This is not a
problem for those who want to do things in pure Java, or in an
environment that does not support C (like Jaos). Those people still can
define their peers in whatever way they want to.

>I think these sort of changes will help manage the increasing variety
>of java2d implementations we are seeing. do they sound acceptable?

I think they are very reasonable. From your first posting, I assumed that
your proposal was that everyone should switch to GTK+. So, I'm very glad
that we seem to be able to come up with a structure that allows for
multiple backends.

-- Sascha

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