A Java Windowing Toolkit for Text Terminals

You may not create, or authorize your licensees to create, additional classes, interfaces, or subpackages that are in any way identified as "java", "javax" or "sun".

In any case, it is not practical to run Swing applications as Charva applications without modifying some lines of source code. In Swing, for example, dimensions are measured in pixels, whereas in Charva they are in rows and columns.

Having said that, I've found that I can easily run 40 instances of the Charva "Tutorial" program (included with the download zipfile), each simulating a busy user, on a single-CPU Pentium with a 1.5GHz CPU and 768 MByte of memory. With this number of simultaneous instances there is no swapping of memory to disk.

Bearing in mind that (in 2006) RAM costs have dropped to, say, 25 US cents per megabyte, Charva is well suited for "intranet"-type data-capture applications with up to several thousand simultaneous users, provided you scale horizontally across multiple servers, with several hundred users on each server.

            export LD_LIBRARY_PATH=directory_containing_libTerminal.so:$LD_LIBRARY_PATH
        

A focus-traversable component is one which is capable of accepting the keyboard input focus, and of passing it on to the next component, when the user presses TAB or BACK-TAB. Note that JLabel is not focus-traversable. Also, components that are normally focus-traversable become non-focus-traversable when their setEnabled(false) method is called.

To my knowledge, there is never any need in a real-world application to display a Window that contains only non-focus-traversable components such as labels.

Incidentally, don't use the "gnome-terminal" application, which is the standard xterm emulator in the GNOME desktop environment; it is buggy and won't work properly with Charva. Rather use the "konsole" emulator which is the standard emulator in the KDE environment (see next question).

            acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~
        

Note that this terminfo description defines CTRL-B as the back-tab key.

The "gnome-terminal" emulator, on the other hand, doesn't seem to work properly with any terminfo file.

Note that the JFrame.show() method also blocks, except for the first time that the application program calls it.

To get more information about the infocmp and tic commands, use man infocmp and man tic

Since version 1.1.3, Charva uses Jakarta commons-logging. You should use the same mechanism for adding debug statements to your code. See the commons-logging website for details.

Another way is to use a commercial IDE such as IntelliJ IDEA which has a good debugger built into it. You have to start the debuggee application with certain command-line options which cause it to listen on a specified TCP port; the debugger then opens a connection to this port. The test scripts (test.sh and test.bat) in the distribution tarball show examples of the required command-line options.

I am told that other IDEs such as NetBeans, Eclipse and JBuilder have the same capabilities.

 java -Dcharva.script.record=scriptfile \
            -classpath ../classes:../lib/charva.jar classname

This will cause CHARVA to log the hexadecimal key-code of each key (and its equivalent symbolic name, if it is a control character or function-key) in the file "scriptfile".

There are two ways of fixing the problem. If you are using a terminal-emulator, there is usually some way of configuring the key-mapping so that any particular key will generate a specified byte-sequence. You should configure the terminal emulator so that each function-key generates the same byte-sequence as specified by the terminfo file. The same applies to the cursor keys.

If you are using a non-programmable terminal or a terminal emulator with a hardcoded key-mapping, you will have to edit the terminfo file itself. To do this:

• run infocmp > /tmp/termfile to decompile the terminfo file into a human-readable format.
• Edit the file /tmp/termfile with an ASCII editor. It may be advisable to rename the terminal-type in this file, thus creating a new customized terminal-type.
• Recompile the edited terminfo file with the command tic /tmp/termfile.

As far as your Java application code is concerned, you would have to write it to handle key-codes such as KeyEvent.VK_F13 and above; your application would not receive an indication that the SHIFT, CTRL or ALT modifier-key was pressed together with the function key.

Currently CHARVA defines only F1 to F20, but the definitions can easily be extended.

Here is a list of useful key symbols in the terminfo file (i.e. in the output of infocmp or the input to tic):

• kcub1 is the left-arrow key.
• kcuf1 is the right-arrow key.
• kcuu1 is the up-arrow key.
• kcud1 is the down-arrow key.
• kend is the END key.
• khome is the HOME key.
• knp is the PAGE DOWN key.
• kpp is the PAGE UP key.
• kich1 is the INSERT key.
• kdch1 is the DELETE key.

The underlying cause of the screen corruption may be that your terminal or terminal-emulator is not 100% compatible with the terminfo file corresponding to your $TERM environment variable (see questions above). Try running your application on a different type of terminal, with $TERM set appropriately.

• Ensure that your terminfo description supports color capability. Run infocmp and check that the string colors#8 appears in the output (or colors#n where n is the number of colors supported).

• Ensure that the terminal or emulator itself supports colors and is compatible with its terminfo description.

• Define the system property "charva.color". You can either do this on the command-line with the option -Dcharva.color, or you can define it inside your program (before calling any Charva methods):

                  System.setProperty("charva.color","");
              

• The source code of the Charva program must set foreground and/or background colors of components (using the setForeground() and setBackground() methods inherited from the charva.awt.Component class).

For those who prefer to lay out the components manually, just use the "null" layout manager:

            Container.setLayout(null);
        

Note that the setLocation() method sets the top left corner of the component, relative to the top left corner of its parent container; except in the case of a Window (i.e a Frame or Dialog), in which case setLocation() sets the absolute location on screen.

Note also that if you set the size of a Window (i.e. a Frame or Dialog) explicitly in your application, you must remember not to call the pack() method afterwards, otherwise the window will be resized to the smallest size that can contain all its child components.

• getSize()
• minimumSize()
• getHeight()
• getWidth()
• draw()

The English version of the same screen is animal_en.gif

According to Leos, there are some limitations to the UTF-8 support: "With JTextArea I cannot type any national characters, after some changes I can type most of characters in JTextEdit (but 0x11b and 0x10d do simply nothing and 0x161 works as backtab)."

            Toolkit.getDefaultToolkit().resetClipRect();
        

    public class MyFrame extends JFrame {
        public MyFrame() {
            super();
            super._insets = new Insets(0, 0, 0, 0);
        }
    }
        

Each window can hide itself by calling its own hide() method. This effectively "pops" the window off the stack, and causes the previous show() method to return. Note that calling hide() does not destroy the window; it remains in existence and can be redisplayed, in exactly the same state as it was before, by calling its show() method again.

If your application is always going to display screens (windows) in the same order, you can just get each window to create and show the next one in the sequence, thus building up the "stack". On the other hand, if the display order must be determined at runtime, you can use the following approach. Assume you have three screen classes A, B and C, and you want to show them in the order A -> B -> C -> A:

            A a = new A();
            B b = new B();
            C c = new C();
            a.show(); // show() blocks until a hides itself
            b.show(); // show() blocks until b hides itself
            c.show(); // show() blocks until c hides itself
            a.show(); // show() blocks until a hides itself
        

Use the following code to do the printing:

    Toolkit toolkit = Toolkit.getDefaultToolkit();
            .
            .
            .
    try {
        toolkit.print(String_to_be_printed);
    } catch (TerminfoCapabilityException e) {
            ...
    }
        

Use the following code to do the printing:

            Toolkit toolkit = Toolkit.getDefaultToolkit();
            String print_screen = toolkit.getStringCapability("mc0");
            .
            .
            toolkit.putp(print_screen);
        

            Toolkit toolkit = Toolkit.getDefaultToolkit();
            String open_drawer = toolkit.getStringCapability("u0");
            .
            .
            .
            toolkit.putp(open_drawer);
        

• JTextComponent.setText
• JTextArea.insert
• JTextArea.append
• JTextArea.replaceRange

Like Swing, CHARVA does all of its drawing (i.e. all of the ncurses function calls, besides reading the keyboard) in a single "event dispatcher" thread. If you want to modify the display from other threads, you should use the static SwingUtilities.invokeLater(Runnable) method, as described in the Core Java book.

The Tutorial program (tutorial/charva/Tutorial.java) included in the distribution zipfile includes an example of how to perform a time-consuming task in a separate worker thread.