<html>
<head>
<title>Tuipeer Enhancement Plans </title>
</head>
<body>
<h2>TUIPEER Enhancement Plans </h2>

Evaluate <a href="http://www.linuxsupportline.com/~Xterminal/">Xterminal</a>
as a possible replacement for the current homebrew TUI component lib.

<ul>
The general plan for the next version is to move as much L&F processing
as possible out of the C++ code and into the Java side without making
turnaround delay unbearable.  Window navigation and Frame decorations
will be moved to the Java side, but text editing for TextArea and TextField
will remain on the C++ side.  I will probably keep the C++ code for the
JDK1.1 component behaviour other than window navigation.  The Java end can
create custom controls via Canvas where desired.

<li>Need dropdown symbol (v or little arrow) after Choice components.
<li>Need indication of when more data is available at top or bottom
on List components.

<li>Need option to keep menu on screen at all times.  It would change when
changing frames.  There still a need for the kopt key to change focus
to/from the menu.
<li>Need "system" menu to provide access to local options without
	cmdline switches.

<li>Started to modify toolkit.cc and toolkit.h to make active Frame and Window
navigation explicit.

<li>Window panning should use copyArea() so it can take advantage of
	insert/delete line terminal functions.

<li>Make smart lineDraw that looks at cell contents to compose intersections.
<li>Missing ScrollPanel 
<li>Missing MouseEvent
<li>Need "Mouse Mode"?
<li>Use KEY_CLOSE instead of KEY_F(1) to close window so Java apps can
get F1.
<li>Provide vi-command mode alternates for critical functions keys so that
tuipeer can be used with braindead keyboards - e.g. vt100.  The alternates
should be intuitive to vi users.  An example would be 'q' in vi-command mode
to close the window.
<p>
The problem is that these keys will then not be sent to the Java server,
spoiling controls that handle keystrokes.  Currently, only TextComponents
deprive the Java end of printing keys.  The solution, I think, is to 
have the Java end hand the vi-mode for everything except TextComponents,
consistent with our guiding principle above.

</ul>

<h3>Known Bugs</h3>
<ul>
<li>Closing bmsi.db.Browse window results in an exception.

<li>Each top level window should capture entire focus.  Some keystrokes
can "leak" to screen objects with suspended focus.
<li>There is a catch-22 with shutting down an auto-loaded tuipeer.  If
the JVM exits first, then tuipeer becomes an orphan and gets an I/O error
attempting to restore the terminal mode.  If the JVM waits for tuipeer
to exit via runFinalizersOnExit, then we don't know that we are supposed
to shut down!
</ul>
</body></html>
