(almost) 100% Pure Java TUI AWT.

BMS TUI AWT Overview

Stuart D. Gathman, last update: Feb 28, 2000

Current Progress

Text attributes implemented. Label and Button peers implemented. Test program includes Label components. Delayed refresh in PWinMgr implemented.

Physical Screen

The Physical screen is handled by the PScreen class. The three basic TUI screen operations are PScreen uses the TermInfo class to read a database of terminal capabilities by terminal type. This is compatible with the Unix System V terminfo format.

A PScreen can be created from a Socket, or a InputStream, OutputStream pair. Terminals can be handled in 100% Pure Java using the javax.comm package for terminals under the complete control of Java. Terminals attached to a network terminal server are similarly easy - hence the Socket contructor. The Java console does not provide a 100% Pure way to enter 'raw' mode needed for a real TUI interface. In many systems, creating a ServerSocket and invoking 'telnet' back to that socket on localhost will open a new window with the TUI interface.

When Java is invoked from a character terminal on unix, getting a telnet command attached to the same terminal - and getting the terminal restored on exit - is tricky in Java. A custom C program is probably the best solution. I have a simple C++ program using my own network library, but an ANSI C solution would be much more portable. In the meantime, simply running Java in the background and manually invoking 'telnet' to the ServerSocket created by FSToolkit will suffice for testing.

TO DO

Physical Window

The PWin class handles windowed output on a PScreen. PWin objects are tied to a PWinMgr. These classes are closely coupled, and PWinMgr probably ought to be an inner class.

The same basic TUI operations are implemented - fill, write, copyArea - but windowized. Non rectangular clipping is handled by maintaining a mask array with the window id of the window owning each screen cell. This mask is updated when moving, resizing, and reordering windows.

TO DO

AWT Components

While the Physical layers use character cell coordinates, the AWT layer uses scaled coordinates. By default, the scaling factor is 5. This is necessary to run typical AWT programs because certain measurements are hardwired. For example, a Panel leaves a 5 pixel padding inset around its components be default. Most applications are not going to override this based on screen resolution, and 5 characters is way too much white space on a TUI screen. By treating each character cell as 5 logical pixels, there is only 1 character padding - about right.

Since component sizes are integral multiples of the scaling factor, LayoutManagers generally work well with the arrangement. Needless to say, line graphics leave something to be desired - but amazingly bar graphs are usually recognizable.

Since FSComponent extends PWin, the TUI components can implement their Look and Feel using either the AWT level or PWin level API. Terminfo virtual keys can be responded to directly by overriding postKey(int), or KeyEvents can be processed by implementing KeyListener. A combination of these can be used.

TO DO

Using FSToolkit

There are two implementations of FSToolkit. FSToolkit1 is for JDK 1.x. FSToolkit2 is for Java 2. To use the toolkit, set the awt.toolkit property. This can be done from the command line with the -D option.
$ java -Dawt.toolkit=bmsi.fsp.FSToolkit1 bmsi.fsp.testfs
Note that FSToolkit1.java will not compile under Java 2, and FSToolkit2.java will not compile under Java 1.