| 1 |
* What is VTE? |
|---|
| 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?" |
|---|
| 6 |
|
|---|
| 7 |
Update: the answer is most likely "because applications which use curses |
|---|
| 8 |
have more detailed information than that which is found in termcap". |
|---|
| 9 |
|
|---|
| 10 |
* What does VTE include? |
|---|
| 11 |
- VTE includes a library (libvte) which implements such a terminal emulator |
|---|
| 12 |
widget for GTK+ 2.2/2.4, and a sample application (vte) which wraps that |
|---|
| 13 |
widget in a GTK window. Because I'm more concerned with whether or not it |
|---|
| 14 |
works, all settings are hard-coded to whatever I needed to test the last time |
|---|
| 15 |
I touched it. If you actually want to use the widget to get work done, you |
|---|
| 16 |
should probably be using gnome-terminal. |
|---|
| 17 |
|
|---|
| 18 |
* How does it work? |
|---|
| 19 |
- The VTE library inserts terminal capability strings into a tree of tables, |
|---|
| 20 |
and then uses it to determine if data received from a pseudo-terminal is a |
|---|
| 21 |
control sequence or just random data. The sample program "interpret" |
|---|
| 22 |
illustrates more or less what the widget sees after it filters incoming data. |
|---|
| 23 |
|
|---|
| 24 |
* What's missing? |
|---|
| 25 |
- Accessibility doesn't work quite right yet. |
|---|
| 26 |
- Mouse hilite tracking isn't implemented yet. If you'll pardon the pun, for |
|---|
| 27 |
certain applications we're terminally unusable without it. |
|---|
| 28 |
- No support for bidirectional text display. No support for shaping. More |
|---|
| 29 |
on these topics: |
|---|
| 30 |
http://www.opengroup.org/onlinepubs/9638399/overview.htm#tagcjh_03_03_01 |
|---|
| 31 |
http://www.opengroup.org/onlinepubs/9638399/overview.htm#tagcjh_03_03_02 |
|---|
| 32 |
http://www.unet.univie.ac.at/aix/aixprggd/genprogc/layout_over.htm |
|---|
| 33 |
http://www.ecma-international.org/publications/techreports/E-TR-053.htm |
|---|
| 34 |
- Most control sequences are recognized, but many aren't implemented. There |
|---|
| 35 |
are enough to run ls, vim, less, emacs and mutt, but more need to be |
|---|
| 36 |
implemented (ds, ff, hd, hu, i1, i3, iP, is, LF, LO, MC, ML, mm, mo, pf, pk, |
|---|
| 37 |
pl, pn, po, pO, ps, px, r1, r2, r3, RA, RF, rp, rs, RX, SA, SX, wi, several |
|---|
| 38 |
more from the XTerm set). |
|---|
| 39 |
- I'm not sure the widget implementation itself is correct. There are many |
|---|
| 40 |
changes in going from GTK+ 1.2 to 2.x, and examples of the proper way to do |
|---|
| 41 |
things is currently scarce, so some of it's guesswork. |
|---|
| 42 |
- An actual property interface needs to be retrofitted over the various options |
|---|
| 43 |
which are only presented as get/set accessors. |
|---|
| 44 |
|
|---|
| 45 |
* What's weird? |
|---|
| 46 |
- Relative cursor motion is weird. When the character to the left of the |
|---|
| 47 |
cursor is a 3-byte UTF-8 sequence for a character which occupies two |
|---|
| 48 |
columns on the screen, three things may happen when the application sends |
|---|
| 49 |
the "cursor left" control sequence: |
|---|
| 50 |
* the cursor moves two columns (one character) to the left |
|---|
| 51 |
This eliminates the possibility of moving the cursor into the middle of |
|---|
| 52 |
a multi-column character. |
|---|
| 53 |
* the cursor moves one column (one half-character) to the left |
|---|
| 54 |
This makes determining where the cursor is easier, but requires the |
|---|
| 55 |
application to emit a control sequence more than once for multi-column |
|---|
| 56 |
characters. |
|---|
| 57 |
* the cursor moves one "byte" to the left |
|---|
| 58 |
This is what most OS kernels do when reading input using "cat". It |
|---|
| 59 |
happens to work for a few locales, and is otherwise just plain broken. |
|---|
| 60 |
Currently VTE follows the second convention. More on this topic: |
|---|
| 61 |
http://czyborra.com/unicode/terminals.html |
|---|
| 62 |
http://mail.nl.linux.org/linux-utf8/1999-10/msg00014.html |
|---|
| 63 |
http://www.debian.org/doc/manuals/intro-i18n/ch-output.en.html |
|---|
| 64 |
- Depending on your locale, the current encoding, and possibly the strengh |
|---|
| 65 |
of cosmic rays, the display width of certain Unicode characters changes. |
|---|
| 66 |
For the most part this works correctly now, but if you find that it |
|---|
| 67 |
doesn't, please file a bug report including a screenshot, the typescript |
|---|
| 68 |
file produced by the incorrectly displayed program run under "script", and |
|---|
| 69 |
the contents of your LANG/LC_* environment variables. |
|---|
