Structure

The structure of the program is divided into these primary components:

Main program
Terminal emulation
Graphics generation
File handling

Main program comprises the GUI and interface logic. Terminal emulation consists of processing a text-stream that contains special codes. Graphics generation consists of rendering text with various properties. File handling manages the different types of files that the program accesses.

User interface

The user interface of that terminal is comprised of a single graphical window. The application takes no commandline parameters.

In the graphical window, a terminal emulator is rendered. The terminal emulator receives input from keyboard and transmits it to the underlying subprocess, and interprets and renders in the window whatever it receives from the subprocess.

Currently that terminal does not interpret mouse events. It does however react to mouse movements.

The user interface code is in the ui module, and it uses libSDL2 for rendering and for event handling.

Application logic

classDiagram
    class ForkPTY
    class TerminalWindow
    class Window
    class UI
    class FontPlan
    ForkPTY : Open(width, height)
    ForkPTY : Send(string)
    ForkPTY : Recv() string
    TerminalWindow : Write(string)
    Window : cells
    Window : blank
    Window : Render(fontwidth,fontheight, pixels)
    FontPlan : Create(fontwidth,fontheight, firstchar, numchars)
    FontPlan : LoadGlyph(index, scanline, renderwidth) Glyph
    Window          <-- FontPlan
    UI              <--> ForkPTY
    ForkPTY          --> TerminalWindow
    TerminalWindow   --> Window
    Window           --> UI
    FontsInfo        --> FontPlan
    ParseSimilarities --> FontPlan
    GlyphList         --> FontsInfo

The core of the application is founded upon three classes: ForkPTY, TerminalWindow and Window.

ForkPTY is at the lowest level. It is responsible for byte-stream communication between the terminal emulator and the underlying shell.
TerminalWindow is a vt100/vt220/vt500/ANSI emulator. It does the bulk of work of converting a text-stream into tangible events on the screen.
Window is a teletype renderer, but not an interpreter. It keeps track of attributes on a text-based screen, such as each cell’s foreground and background colors and character in that cell, and the current cursor position, and provides a facility to render this state into a pixel-based buffer.

The UI ties these components together as follows:

Keyboard input is received by UI from the GUI, and UI sends it to the underlying process through ForkPTY.
ForkPTY's output is sent to TerminalWindow for processing.
TerminalWindow updates the state of Window.
Window renders into a pixel-buffer provided by UI. `UI sends the pixel-buffer to the GUI for displaying.

For rendering, Window needs fonts. For that it uses a FontPlan, which follows the following hierarchy:

FontPlan, FontsInfo and ReadFonts, GlyphList and ReadFont, ParseSimilarities.

FontPlan provides facilities for mapping every unicode codepoint into a bitmap. If font of the exact size cannot be found, it creates a bitmap by scaling a differently sized one. It uses a a share-file preferences.txt which indicates which fonts are more favorable. If an exact representation of a given unicode codepoint cannot be found in any reasonable font, it uses the similarity list generated by ParseSimilarities to find an approximation. For example, Â could be approximated with A in a situation of complete absense of accented characters.
FontsInfo stores information about all fonts known by the terminal emulator. For each font, indicated by a filename and pixel dimensions, it indicates which unicode codepoints are factually supported by this font.
GlyphList stores information about a particular font file. It stores all the bitmaps within the font, the list of supported unicode codepoints within the font and the width and height of each glyph. While height is shared between all glyphs, the width can vary.
ParseSimilarities indicates which glyphs can be used to approximate the appearance of another. It does this by a combination of rules based on the character names in Unicode and a list of hardcoded mappings.

File access

Besides launching a shell — the behavior of the shell is beyond the scope of the terminal emulator — that terminal accesses a handful of files. These accesses are divided into two categories:

Files supplied with the terminal emulator (called share files)
Files created by the terminal emulator (called cache files)

Share files

The files that are supplied with the program are provided in the share/ directory and its subdirectories. At runtime, that terminal looks for these files in the following paths:

<program_path>/share/
$HOME/.local/share/that_terminal/
/home/$USER/.local/share/that_terminal/
/usr/local/share/that_terminal/
/usr/share/that_terminal/

Additionally, some files such as UnicodeData.txt are also looked for in:

/usr/local/share/unicode/
/usr/share/unicode/ as it is common for it to be found there.

Cache files

The files that the terminal generates are saved in a user-specific local directory. That terminal attempts to use the following locations, whichever first turns out writable.

$HOME/.cache/that_terminal/
/home/$USER/.cache/that_terminal/
/run/user/$UID/
/run/$UID/
$TEMP/that_terminal-$UID/