This adds the ability to have multiple windows by introducing new keybind actions `new_window`, `close_window`, and `quit`. These are bound on macOS by default to the standard `cmd+n`, `cmd+w`, and `cmd+q`, respectively.
The multi-window logic is absolutely minimal: we don't do any GPU data sharing between windows, so each window recreates a full font texture for example. We can continue to further optimize this in the future.
DevMode is also pretty limited (arguably broken) with multi-window: DevMode only works on the _first_ window opened. If you close the first window, DevMode is no longer available. This is due to complexities around multi-threading and imgui. It is possible to fix this but I deferred it since it was a bit of a mess!
* This completes ours multi-threaded architecture started with #21 by moving pty IO to a dedicated thread.
* A bounded, blocking queue implementation is introduced for inter-thread communication.
* The Window thread (which previously also did IO) no longer uses libuv, and is purely a windowing event loop.
## Performance
On IO heavy workloads such as `cat big-file.txt`, throughput has increased by more than 400%. In general, I'm noticing more consistent frame rates across all workloads, with dramatic differences in IO heavy workloads.
## Architectural Notes
There are now three threads per window as shown below:
```
┌─────────────────────────────────┐
│ │
│ Window │
│ │
└─────────────────────────────────┘
│
┌───────────────────┴──────────────────┐
│ │
▼ ▼
┌─────────────────────────────────┐ ┌─────────────────────────────────┐
│ │ │ │
│ Renderer │◀───│ IO │
│ │ │ │
└─────────────────────────────────┘ └─────────────────────────────────┘
```
Notes:
* The window thread is responsible purely for windowing events: focus, mouse movement, keyboard input, etc.
* The IO thread is responsible for pty IO such as reading and writing to the pty fd. This thread also owns the terminal state.
* The renderer is responsible for turning terminal state into screen data, and auxiliary visual functions such as cursor blink.
The arrows in the diagram above show how threads can communicate. Communication is done through one-way, MPSC (multi-producer single-consumer) bounded queues. The MPSC queue implementation is _not optimal_ and can be improved but our workload is not a message-heavy workload.
Threads _also use shared memory_, as noted in #21. For large data structures such as terminal state, mutexes are utilized to avoid large copies.
Ghostty now loads the config file in `$XDG_CONFIG_HOME/ghostty/config` if it exists on startup. This follows the XDG base dir specification so if $XDG_CONFIG_HOME is not set, we default to `$HOME/.config/ghostty/config`.
