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.