TUIPEER Enhancement Plans

• Move the Java source code into the tuipeer package. This is what JServ does. JServ also has a C piece and a Java piece which communicate via Socket.
• Expand TestFrame to include Dialog and Window examples. We need a good test case to make the new window navigation work compatibly.
• Loading tuipeer from Java is flaky because tuipeer has trouble trying to attach itself to /dev/tty in raw mode - and restore the tty mode when terminating. One way to get around this is to have tuipeer run the JVM for single user operation.
• The socket protocol always sends 2 byte integers. We should use a MIDI like protocol for length encoding of ints. This requires updating readShort/writeShort - and could be selectable to keep backward compatibility.
• The idea mentioned below of handling more focus control in Java is a bad one (so he thinks now). We want to minimize cursor drag, and turnaround from Java processing in another process/machine makes it worse. Local focus control should look like selecting components with mouse clicks to the Java code. We should keep the option of handling tabs in Java - which the AWT already supports.
• In keeping with better local focus control, I think we need a win95 style task bar to select the active frame. It should pop up in response to KEY_SELECT as the current simple frame menu does now.
• It is really really time to fix the Menu components so that Focus works properly. While we're at it, we should keep Dialogs and Windows attached to a Frame and track the Dialog stack for each Frame.

I have removed the dependency on libg++ by recoding all references to String. I thought about making a String class that derives from string and emulates the features we use. I may still do that if there are too many bugs in the recoded version.

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.
• Need dropdown symbol (v or little arrow) after Choice components.
• Need indication of when more data is available at top or bottom on List components.
• 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.
• Need "system" menu to provide access to local options without cmdline switches.
• Started to modify toolkit.cc and toolkit.h to make active Frame and Window navigation explicit.
• Window panning should use copyArea() so it can take advantage of insert/delete line terminal functions.
• Make smart lineDraw that looks at cell contents to compose intersections.
• Missing ScrollPanel
• Missing MouseEvent
• Need "Mouse Mode"?
• Use KEY_CLOSE instead of KEY_F(1) to close window so Java apps can get F1.
• 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.

  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 handle the vi-mode for everything except TextComponents, consistent with our guiding principle above.

Known Bugs

• Closing bmsi.db.Browse window results in an exception.
• Each top level window should capture entire focus. Some keystrokes can "leak" to screen objects with suspended focus.
• 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!