java.awt.Toolkit problem

[Peter C. Mehlitz]

On Fri, 02 Oct 1998, Tomas Sieger wrote:
>I've got problems with this program:
>import java.awt.*;
>public class A  {
>    public static void main(String[] args)  {
>System.out.println(Toolkit.getDefaultToolkit().getClass().getName());
>
>Hint: use AWT graphics (just draw a frame) before calling
>Toolkit.getDefaultToolkit(). It helps!
>
>I run Kaffe 1.0.b1 (kaffe-1.0.b1-1.i386.rpm)
>on RedHat Intel Linux 5.0 (Hurricane) 
>
>What's wrong?

That was a problem with the static Color field initialization, which has been
fixed some time ago. Please check with the current snap.


On Fri, 02 Oct 1998, Glynn Clements wrote:
>Kaffe's java.awt is totally broken w.r.t. Toolkits. 
> 
>Contrary to the spec (or at least all of the versions which I've 
>seen), Kaffe's java.awt.Toolkit isn't abstract, and all of the 
>Component classes use hardwired methods instead of the Peer mechanism. 
>
>Given that fixing it could be a lot of work, without any real benefit 
>for the average user, I wouldn't expect it to be fixed any time soon. 

To make Toolkit abstract would be just a matter of minutes, but - since it
doesn't have a public constructor - I don't see any reason why we should add
another class, just to end up with the same behavior (a good way to bloat the
system).

The current snap has pseudo-peer support (to please the deprecated, but still
used getPeer()). Since all our widgets are lightweights, it doesn't make
sense to add the full Peer interfaces (which are not public, anymore). There is
no useful functionality this would add. The LightweightPeer really isn't worth
to think about this.

A native widget (i.e. native toolkit) based AWT is a completely different thing
that cannot be done just by tinkering around with an own Toolkit implementation
(think of the (thread-system dependent) event handling, the drawing/clipping
mechanisms, ..).

-- Peter