The netbeans terminal emulator
- mailing list: email@example.com
- to manage mailing list visit http://netbeans.org/projects/www/lists
- terminalemulator open IZs list.
- API Review
- Testing and troubleshooting
Using a terminal emulator
Under NetBeans you can just use Window->Output->Terminal.
There is a standalone Java terminal application available under lib.terminalemulator/examples/TermApp although it is mainly for demonstration purposes.
In them you should be able to do the following:
- Use the shells cmdline editing.
- Use more/less/man and have them render and react as expected.
- Use a screen editor like vi
- Start a plain /bin/cat and ^C or ^D out of it or ^Z it.
- Issue "stty -a" and note how 'columns' and 'rows' tracks window size changes.
terminal emulator vs Terminal Emulator
To most of us the word terminal emulator brings to mind an application like xterm, dtterm or konsole. What we might not realise is that such an application, especially the more modern ones, is actually made up of several cooperating subsystems ...
- The wrapper application. This might implement options, searching, menus etc.
- A terminal emulator widget/component.
- Ptys and a Line Discipline.
functionality we usually associate with the application might not actually be implemented solely by the widget/component.
List of modules that we work with
lib.terminalemulator (Terminal Emulator)
This is the base Swing terminal emulator widget/component.
It implements class Term and it's subclasses.
It also provides the package org.netbeans.lib.terminalemulator.support which provides support for searching and color and font dialogs.
Most of NB accesses class Term via the IOProvider API provided by this module. Compare this module to core.output2 (Output Window).
dlight.nativeexecution (Native Execution)
Provides the primary process execution and Pty support. The Pty support is provided via pty, an external shuttle program.
lib.terminalemulator/examples/lib.richexecution (Rich Execution)
Is an alternative to (Native Execution) and is based on JNA. It provides process execution and Pty support for standalone terminal applications and testing.
dlight.terminal (Native Terminal>
Implements a fully functional terminal inside NetBeans.
A standalone Java application that implements a terminal emulator (a'la xterm).
Also see modules described in TerminalTestingAndTroubleshooting
Long term projects:
The base Term widget has served reasonably well so far but it could use some improvements:
- It doesn't implement all the ANSI or Xterm escape sequences. It suffices for common uses by vi, more, shell cmdline editing and etc but customers who try to debug full-fledged curses based applications (yes they do exist) find it wanting.
- A particularly challenging application is 'mc' (Midnight Commander). It's rendered reasonably well but cannot do the following:
- Render "graphic" characters (for boxes and such). While these characters are defined in unicode, Java fonts don't support them.
- Handle Function keys. This isn't hard to do but I have to first work out how to make this optional so there's no conflict with the IDE's Function keys.
- Convert mouse gestures to character sequences.
- Many users have expressed dissatisfaction with lack of font choices. You can get any font you want as long as it's "monospaced".
- We currently an give users a choice of various fixed width fonts through a Term property sheet. The proecss of picking out only fixed-width fonts for the font palette has been under some circumstances expensive.
- It doesn't have disk-based buffers like output2. The impact of large history size on the heap and GC can be solved using nio Buffers.
- It will not re-wrap lines. So if it starts narrow and then gets widened the text emitted while it was narrow stays narrow.
- The view paint() is lazy in that it repaints everything. This works well enough if the output to the term is buffered. However if you write one character at a time to it it will get noticable.
- It is not thread-safe. All operations must be done on the AWT event dispatch thread.
- In order to be able to evolve Terms API without worrying about API compatibility class Term needs to become final. For that, in turn, sublasses StreamTerm and ActiveTerm need to be lifted into class Term and then deprecated.
- Some of the IO* functionality provided by terminal (Terminal) should be pushed to the generic IO API. But then ...
- There is a fair amount of code that can be factored between terminal (Terminal) and core.output2 (Output Window).
- The problem with output2 was that it didn't allow for customizing the kind of tab that appeared in it's container. So the plan was to duplicate it in output3 and then factor them at some time in the future.
- The terminalemulator open IZ list (which includes some of the above).