(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

fill an area with a character. This uses any repeat_char or erase functions the terminal may have. An erase operation may still be used when it erases too much by repainting the excess.
write a sequence of characters.
copyArea (formerly called slide). This uses any insert/delete functions the terminal may have. An insert/delete line may still be used to slide a narrower area of the screen by repainting the excess portion. If the terminal has no insert/delete capability at all, copyArea simply repaints the entire target area.

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

PScreen.fill doesn't repaint excess erased.
PScreen.copyArea is not implemented.
If interpreted Java can handle the CPU (we avoid JIT where possible), there should be a backing copy of PScreen contents to handle repaints internally.
A portable ANSI C proxy is needed to connect a socket to the users tty in raw mode.

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

PWin.copyArea() is not implemented.
The basic TUI operations should be an interface implemented by PScreen, PWin, and FSImage (off screen character cell image).
Active window and parent window are currently tracked by FSToolkit and FSComponent. I think this would be better done by PWinMgr and PWin. The recursive set() implementation would then handled by PWin.

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

FSComponent.requestFocus() needs to activate the toplevel window.
The mapping from terminfo keys to KeyEvents in FSComponent.postKey() is rather mickey mouse at present. A more comprehensive and table driven approach is needed.
MenuComponents
FSGraphics.copyArea not implemented
TextComponents
Miscellaneous Components
ScrollPanel (needs robust copyArea)
Offscreen Images (just an array of character cells, but needed for AWT Components that use double buffering for scrolling.)

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.