1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
* What is VTE?
- You could say that VTE is something of a research project of mine, based on
the simple question: "if programs can use a termcap file (through either
libtermcap or curses or ncurses) to determine how to drive a terminal, why
can't a terminal emulator use a termcap file to determine how to behave?"
* What does VTE include?
- VTE includes a library (libvte) which implements such a terminal emulator
widget for GTK+ 2.0, and a sample application (vte) which wraps that widget
in a GTK window. Because I'm more concerned with whether or not it works,
all settings are hard-coded to whatever I needed to test the last time I
touched it. If you actually want to use the widget to get work done, you
should probably be using profterm.
* How does it work?
- The VTE library inserts terminal capability strings into a trie, and then
uses it to determine if data received from a pseudo-terminal is a control
sequence or just random data. The sample program "interpret" illustrates
what the widget actually sees after it filters incoming data.
* What's missing?
- Accessibility isn't completed yet.
- Mouse hilite tracking isn't implemented yet.
- Most control sequences are recognized, but many aren't implemented. There
are enough to run ls, vim, less, emacs and mutt, but more need to be
implemented (bt, ct, dm/ed, ff, fs, i1, i3, is, iP, LF, ll, LO, MC, mh, ML,
mm, mo, mp, nw, pf, pk, pl, pf, po, pO, ps, px, r1, r2, r3, RA, RF, rp, rs,
RX, SA, st, SX, uc, vb, wi, several more from the XTerm set).
- I'm not sure the widget implementation itself is correct. There are many
changes in going from GTK+ 1.2 to 2.0, and examples of the proper way to do
things is currently scarce, so some of it's guesswork.
- An actual property interface needs to be retrofitted over the various options
which are currently hard-coded at startup-time.
|
