[kaffe] Classpath AWT progress.

[James Simmons]

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

I have to see if it would work with my design goal. The basic goal is to 
have two totally different environments work together as if they we one 
environment. One screen would be X windows and the other screen would be 
a linux framebuffer implementation. The problem is two very different 
environments are going to have two different toolkits. Since it is 
possible to pass in a GraphicsConfiguration to a Frame, Window etc I was 
thinking it would be easiest to grab the proper toolkit from the 
GraphicsConfiguration. Do you see any other way to grab the proper 
toolkit?

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

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