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
This article is translated to Serbo-Croatian language by Jovana Milutinovich from Webhostinggeeks.com. A
Bulgarian translation of this page was provided by Ivan Boreev.
Russian language by Ivanka from Coupofy team.
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".
- A concept block diagram.
- Block diagram of pressing a Button
with TUIAWT.
- Block diagram of setting the text
of a Button with TUIAWT.
The TUI AWT scheme was described in an
article
for the Sep97 Dr. Dobbs Journal.
GUI code that uses LayoutManager properly and does not draw general
graphics on Canvas and Panel components will work fine.
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.
The TUI concept could work under swing only by using a TUI L&F for Swing.
Even then, Swing applications tend to be much more dependent on real graphics,
so this seems less than useful.
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?
See the download page.
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!
Please E-mail suggestions for features, bugs
to stuart@bmsi.com.
Serbo-Croatian translation.
Bulgarian translation.
Russian translation.
More Java goodies.
Business Management Systems home page.
