A Text User Interface for the Java AWT

Last modified Mar 1, 2015

Copyright (C) 2000,2002 Stuart D. Gathman

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
GNU Free Documentation License for this documentation

JDK 1.0 and 1.1 let you provide pluggable Look and Feel by implementing
the interfaces in java.awt.peer. The TUIAWT Java package and tuipeer program
provide a TUI
(Text User Interface) Look and Feel. In addition, it supports multiple
instances of java.awt.Toolkit, a prerequisite for a multi-user JVM.

The result is that the same application byte code can have a GUI or a TUI
interface depending on which Toolkit instance is used.

A screen shot of Teikade in TUI mode.
A screen shot of Teikade in GUI mode.

TUIAWT works by sending peer commands to a remote peer program and receiving
user interface events from the remote peer program. Communication with the
remote peer program takes place over a socket connection. The remote
peer program can also implement a GUI Look and Feel, and in fact could
be written in Java. While this seems redundant, the advantages are at least
two fold:

Security is enhanced by the isolation from a (possibly untrusted) client.

This enables multiple Toolkit instances for a multiuser JVM on a
server - without having to rewrite AWT.

IBM implemented this concept and made it available at their AlphaWorks
site as "Remote AWT for Java".

GUI code that uses LayoutManager properly and does not draw general
graphics on Canvas and Panel components will work fine.

A screen shot of TextEdit.java in TUI mode.
I modified TextEdit.java to removed the hardwired image size for the
decorations. The Source

A screen shot of Teikade in TUI mode.
No modifications were needed to make Teikade operate in TUI Mode! Note
that the simple rectangular graphics used in the Teikade memory
monitor are intelligible in TUI Mode. The 3D shading, however, has the effect
of erasing part of the graph.

The tuipeer version does not yet support Java 2. It has been tested with
JDK1.1.6 and JDK1.1.8. Java 2 breaks java.awt.Toolkit by sprinkling
hardwired references to sun.awt.SunToolkit throughout the AWT code. There
is no documented way to provide an alternate AWT implementation in Java 2
without rewriting the entire set of packages. It would be possible to
reverse engineer and extend sun.awt.SunToolkit - and maybe I'll do so after
submitting a bug report.

In the meantime, Rob Pitman has written a partial
source compatible implementation
of AWT and Swing that may be useful. While you can't use the same class
binaries for both GUI and TUI, it does let you recompile your applications
for TUI by changing 'java.awt' to 'charva.awt' and 'javax.swing' to
'charva.swing' in your import statements and recompiling.

Popular Windoze IDEs such as Supercede and Visual Cafe work with absolute
pixel coordinates. There is no custom LayoutManager support and even
standard LayoutManagers don't work properly in design mode. Using absolute
coordinates causes trouble when changing GUIs as well as with
TUIAWT. I have tried Supercede 1.0 and VC2.0. Both these products have
other fine features, but proper LayoutManager support is not one of them.
I have been told that JBuilder and Visual Age work properly with LayoutManager,
but these products require 64M or more of RAM and a P200 which I don't have,
so I haven't tried them.

Update: Now that I have a P200 with 64M of RAM, JBuilder and Visual Age now
require at least 128M RAM and 400MHz. The old versions are no longer
available. Similar remarks apply to Forte for Java from Sun.

How do I try out TUIAWT?

Another way to skin the TUIAWT cat is to develop a Pure Java curses using
JavaComm or Sockets and dispense with the C++ process. If anyone starts
such a project,
let me know - because I have started on a 99% Java TUIAWT implementation
that uses the terminfo database. A prototype version can be found
on the download page.

Implemented are Label,Button,Window,Frame.
MenuComponents, Canvas, Panel, and Dialog are in the next update. Note
that terminal output is unoptimized. A stdscr/curscr scheme will be
tried. A goal of the project is to keep CPU usage reasonable even with
the interpreter.

While there are a number
of advantages to the separate process - I would be glad to forego them
to get rid of the porting nightmare. (The porting problems are caused by
using the terminfo level of curses - see porting notes, and to the lack of
a standard C++ library at the time.) In addition, the
separate process could always be a JVM!