Description
TLDR:
- Move all updatable state into global
State
struct - Derive all visual state in
Control::draw
callbacks from globalState
- Can we make&mut self
into&self
? - Fork ratatui and make
Rect
serialize/deserialize - Create a PTY abstraction that allows resize events in
wicket-dbg
Details:
The way wicket-dbg
works is that a serialized recording of all totally ordered events is replayed from the initial state. Since each even is processed deterministically, replaying all events in order results in the same end state. However, as memory is limited, we cannot store an indefinite number of events. We therefore limit the number of events we store and when we fill the buffer, we take a snapshot of the current State
struct. At that point future replays in wicket-dbg
will start at event X
rather than the initial state.
For snapshotting to work however, all state mutated by incoming events must be stored in the global State
struct, and it must be serializable. This is not currently the case, as some mutable state is stored in pane implementations such as UpdatePane
. We must move this all to State
. In essence, Pane's should not store any state at all, and we should only mutate state when Control::on
callbacks are called. Control::draw
callbacks should not mutate state, but should take the current state and derive visual state used by TUI widgets.
Additionally, we have a problem where we store tui::layout::Rect
s in panes. This is to allow dynamic drawing of contents when a Resize
event comes in. We need to also store these in the global State
. Unfortunately the Rect
type is not serializable. We need to fork the new version of tui.rs
, ratatui and derive Serialize
and Deserialize
for Rect
.
Besides Rect
serialization, we also cannot handle resize of windows themselves properly in wicket-dbg
. If a user resizes their window to be smaller, this should work, although it will appear as a partial view into a terminal where the whole thing doesn't get updated. If the user resizes their window larger, we will likely panic from an overflow. What we need is some sort of pty management where we can spawn virtual terminals and resize at will.