[kaffe] Classpath AWT progress.

[Sascha Brawer]

James Simmons <jsimmons@infradead.org> wrote on Mon, 8 Dec 2003 19:25:35
+0000:

>Here is the code I have so far. I extended GraphicsEnvironment to actually 
>work. At present it gives exceptions. The main file is 
>ClasspathGraphicsEnvironment.java. Its goal is to load each type of 
>GraphicsDevice driver.

Some time ago, there was a discussion on the Classpath mailing list about
this topic. The discussion was mostly between Graydon Hoare and me, but
IIRC others had expressed their opinions as well. The conclusion was that
it seemed like a good idea to delegate the implementation of

 java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment()

to the toolkit. All Classpath toolkits would be mandated to subclass
gnu.java.awt.ClasspathToolkit. The intention is to keep the platform
dependencies limited to as few places as possible. There was some debate
about whether GraphicsEnvironment or Toolkit would be the appropriate
place for this, and the apparent conclusion, at the time, was that
Toolkit would be preferable.

(For some reason, gnu.java.awt.peer.gtk.GtkToolkit does not yet extend
gnu.java.awt.ClasspathToolkit. However, if I remember correctly, Graydon
said he wants to change this in the future.)

So, IMHO, java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment should
look as follows:

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

public static GraphicsEnvironment getLocalGraphicsEnvironment()
{
  return ((ClasspathToolkit) Toolkit.getDefaultToolkit())
    .getLocalGraphicsEnvironment();
}

Would you have a problem with this for your xlib implementation? If so,
it would be interesting to know the reason.

Just a side comment from reading your code:
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment() should never
throw a HeadlessException. Instead, it should return a headless instance
of GraphicsEnvironment when it is called in a server environment. The
returned instance is supposed to throw a HeadlessException when it gets
asked to perform things that only make sense in a GUI, such as
determining the maximal size of any attached screen.

>package gnu.java.awt;
>public class ClasspathGraphicsEnvironment extends GraphicsEnvironment

This may just be my personal opinion, but I'm currently not convinced why
this class is needed at all. It seems that pretty much all of its
functionality would be highly specific to the platform, with the
exception of the getBounds() and getCenterPoint() methods -- so why
introduce a concrete-but-not-functional subclass of the abstract
GraphicsEnvironment? But this may be different when it turns out that we
can refactor the implementation of other GraphicsEnvironment methods
(such as getAllFonts).

By the way: Thanks for having documented your code, it makes it so much
easier to read.

-- Sascha

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