All Packages  Class Hierarchy  Class Search  Index

BMS TUI AWT Overview

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

Current Progress

Physical Screen

• 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.

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 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

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

$ java -Dawt.toolkit=bmsi.fsp.FSToolkit1 bmsi.fsp.testfs