SwingToolkit

SwingToolkit is currently included as part of the rheise.os distribution which can be downloaded here. See a screenshot and the README file below.

SwingToolkit
============

SwingToolkit is a 100% Java toolkit that uses Swing to draw window borders,
buttons and other widgets that are usually drawn by native peers. A
JDesktopPane is created to cover the user's screen and each new Frame is
translated to a JInternalFrame which is displayed inside the JDesktopPane.

There is very little code so far and it only supports enough peers to get Java
telnet working (buttons, panels, scrollbars, labels and text fields). To test,
run the desktop.sh shell script located at src/rheise/desktop/desktop.sh. It
will bring up a desktop with one program running in it called SwingShell.
SwingShell allows you to type in the name of Java programs and execute them
within the desktop, but most likely they will either crash or not work.

HOW IT WORKS
============

... or doesn't.

First I should point out that a 100% pure Java toolkit is not possible. There
needs to be some way to draw graphics to the screen. To do this I simply load
the existing native toolkit that normally takes care of everything and use it
for the creation of graphics contexts. More accurately, it works as follows:

1. The existing native toolkit is dynamically loaded manually before
Toolkit.getDefaultToolkit() is called. We want Toolkit.getDefaultToolkit() to
load our own toolkit and once it has loaded a toolkit, that toolkit cannot be
changed.

2. Set the awt.toolkit property to rheise.desktop.awt.SwingToolkit so that
after Toolkit.getDefaultToolkit() is called, all peers will be created as
swing widgets. We also have a reference to the native toolkit if we need it.

3. Create a native frame to hold the JDesktopPane. SwingToolkit.createFrame()
will create native frames until the nativeCreated flag is set to false.

4. Set nativeCreated to false. Now all new Frames and all other widgets will
be created using swing classes.

Each time addNotify() is called on a component, a corresponding swing widget
is created and added to the native JDesktopPane where it can be seen by the
user. Events are detected by the swing widgets of the toolkit and forwarded to
the actual Java components of the user application. Repaint requests go in the
opposite direction. The user Java component requests a repaint() which goes
through the peer and invokes repaint() on the swing widget.

None of this works properly, of course.

All code contributions are welcome.