makeover-tui 0.1.0

The terminal renderer for makeover-layout, on ratatui. The surface where a fill can vanish: two intents that differ in 24 bits can land on one entry in 16 colours, so depth degrades from colour to structure.
Documentation
  • Coverage
  • 100%
    14 out of 14 items documented0 out of 7 items with examples
  • Size
  • Source code size: 28.17 kB This is the summed size of all the files inside the crates.io package for this release.
  • Documentation size: 431.23 kB This is the summed size of all files generated by rustdoc for all configured targets
  • Ø build duration
  • this release: 13s Average build duration of successful builds.
  • all releases: 14s Average build duration of successful builds in releases after 2024-10-23.
  • Links
  • Repository
  • crates.io
  • Dependencies
  • Versions
  • Owners
  • MaxJMath

makeover-tui

The terminal renderer for makeover-layout, on ratatui.

Named for the target and not for the library, the same way makeover-immediate is named for the mode and not for egui.

What a terminal changes

A terminal can paint a two-tone bevel, which is the surprise. Writing cells directly gives per-side colour control that neither ratatui's Block nor egui's single bg_stroke offers, so the lit edge that a webview does with box-shadow: inset and egui does with two polylines is available here too.

What a terminal cannot reliably do is fill. Two surface intents several steps apart in a 24-bit theme routinely land on one entry in sixteen colours, and surface-well collapses onto its own face on 18 of the 31 shipped themes. A well drawn as a fill is then a well drawn as nothing.

So depth degrades from colour to structure: paint the fill when it will be visible against what is already in the buffer, and always paint the edge, because the edge is the part that survives. Palette::shows is the whole of that problem in one predicate.

The other terminal-only fact: an edge costs a cell on each side. frame returns the area left for content rather than letting a caller assume the region is intact.

The correction it forced

makeover-layout::Fill briefly carried a fallback, returning Page for Well so a consumer without surface-well had something to paint. That is an answer for a renderer that can always paint an exact colour. Here it is actively wrong: the page is usually the surface a well is cut into, so falling back to it produces precisely the invisibility the fallback existed to prevent.

Substituting one intent for another turned out to be renderer policy rather than description. It moved out of makeover-layout and into makeover-immediate, which does want it. That is the first thing a second renderer was built to find, and it took a day rather than the API-window's usual 48 hours after adoption.

Status

Unpublished, path dep on makeover-layout. No consumer yet: alloy_tui and shop are the intended first ones, both of which already take makeover and makeover-geometry from the registry.

Design lives in the wiki note makeover-tui; the backlog is in GoingsOn under the project of the same name.

Licence

MIT.