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