max / makeover-tui
| 1 | //! The terminal renderer for [`makeover_layout`]. |
| 2 | //! |
| 3 | //! <!-- wiki: makeover-tui --> |
| 4 | //! |
| 5 | //! Named for the target and not for ratatui, the same way |
| 6 | //! `makeover-immediate` is named for the mode and not for egui. |
| 7 | //! |
| 8 | //! # What a terminal actually costs you |
| 9 | //! |
| 10 | //! Not colour. That was the original assumption here and it is wrong on any |
| 11 | //! terminal built this decade. Measured across the 31 shipped themes |
| 12 | //! (`makeover`'s `well_fidelity` example): |
| 13 | //! |
| 14 | //! | | ANSI-16 | ANSI-256 | truecolor | |
| 15 | //! |---|---|---|---| |
| 16 | //! | a well collapses onto its face | 18/31 | 4/31 | 2/31 | |
| 17 | //! | at least one bevel edge vanishes into its face | 31/31 | 4/31 | 0 | |
| 18 | //! |
| 19 | //! The threshold is 256, not 24-bit, and the two failures that survive at |
| 20 | //! truecolor are not terminal failures at all: they are the themes whose |
| 21 | //! raised surface is already white, so the lightening clamps and the well |
| 22 | //! lands exactly on its face. Those render identically in a browser. |
| 23 | //! `makeover`'s own `well_is_distinct_from_its_face` test already names them. |
| 24 | //! |
| 25 | //! **What a terminal costs is geometry, and no amount of colour fixes it.** |
| 26 | //! An edge occupies a whole cell on each side. A cell is roughly 8x17 pixels, |
| 27 | //! so a one-pixel bevel becomes something an order of magnitude heavier, which |
| 28 | //! is why [`frame`] hands back a shrunk [`Rect`] instead of pretending the |
| 29 | //! region survived intact. There is nowhere to put a corner radius, so |
| 30 | //! `radius_control` and `radius_container` mean the same thing here. A fill |
| 31 | //! can only begin and end on a cell boundary. |
| 32 | //! |
| 33 | //! That is the constraint worth designing against. It does not improve, it is |
| 34 | //! not detectable, and it applies equally to the best terminal ever written. |
| 35 | //! |
| 36 | //! What it does not mean is that the shape inside the cell stops mattering. |
| 37 | //! Half of a cell is still addressable, and a bevel drawn in half-blocks reads |
| 38 | //! as a lit edge where the same bevel in box-drawing reads as a line: `─` and |
| 39 | //! `│` are one stroke through the middle, identical on all four sides, saying |
| 40 | //! nothing about where the light is. Half-blocks also make the two corners |
| 41 | //! where light meets shadow expressible, since a glyph that fills half a cell |
| 42 | //! leaves the other half to the second tone. |
| 43 | //! |
| 44 | //! # Where fidelity does matter |
| 45 | //! |
| 46 | //! At [`Fidelity::Ansi16`] the depth vocabulary collapses outright: a well |
| 47 | //! cannot be filled distinctly on most themes *and* a bevel loses an edge on |
| 48 | //! every one of them, so a raised card and a well both read as a single-tone |
| 49 | //! box. Colour cannot carry the distinction, so [`frame`] carries it with the |
| 50 | //! glyphs instead. |
| 51 | //! |
| 52 | //! Above that, colour carries it and the glyph fallback never fires. |
| 53 | //! |
| 54 | //! [`Palette::shows`] is worth reading correctly in light of the numbers: it |
| 55 | //! is **not** a low-colour workaround. It is a correctness check that a fill |
| 56 | //! will be visible against what is behind it, and at truecolor it fires on |
| 57 | //! exactly the two clamping themes, which is precisely when it should. |
| 58 | //! |
| 59 | //! # 0.13.0: a modal, and two cues four ports were about to each invent |
| 60 | //! |
| 61 | //! [`Depth::Overlay`](makeover_layout::Depth::Overlay) arrives in |
| 62 | //! makeover-layout 0.14.0 and needed nothing here: [`Palette::fill`] has |
| 63 | //! answered `Fill::Overlay` since this crate had a palette, so what was missing |
| 64 | //! was the route from a description rather than the drawing. A test asserts it, |
| 65 | //! because a route nothing exercises is one a refactor can quietly lose. |
| 66 | //! |
| 67 | //! [`Theme::selection_on`] and [`Theme::focus_ring`] are the other half, and |
| 68 | //! both are DERIVED rather than authored. Every consumer measured did selection |
| 69 | //! with `REVERSED`, for want of an on-accent foreground; every one that wanted |
| 70 | //! a focus ring either spent makeover's `border-strong` on it, which is a |
| 71 | //! divider at 1.63:1 on Akari Dawn, or derived its own the way `alloy_tui` |
| 72 | //! does. Four terminal ports were each about to answer that separately. |
| 73 | //! |
| 74 | //! Derived, not authored, because the direction is one-way. An authored key can |
| 75 | //! fall back to a derivation and break no theme on disk; a key this crate |
| 76 | //! started requiring would break every theme that lacks it. So the theme format |
| 77 | //! does not change and nothing on disk grows, and the promotion stays available |
| 78 | //! for a theme that ever needs to tune either. |
| 79 | //! |
| 80 | //! # 0.14.0: the first structural widget |
| 81 | //! |
| 82 | //! [`table`] is the first thing here that draws content rather than a surface, |
| 83 | //! and it exists because 14 call sites across `mnw-cli` and `viewer` were |
| 84 | //! already drawing one. `mnw-cli` had written the mapping layer by hand |
| 85 | //! (`src/tui/widgets.rs`: a muted bold header, a selected row carried by the |
| 86 | //! background alone) and `viewer` had written a smaller one, which is two |
| 87 | //! answers to a question this crate is supposed to answer once. |
| 88 | //! |
| 89 | //! It is a mapping layer over [`ratatui::widgets::Table`] rather than a table |
| 90 | //! implementation, because ratatui already lays tracks out, draws a header, |
| 91 | //! highlights a row and scrolls. What it has no answer for is content |
| 92 | //! measurement and narrowing, and those are what the module is. |
| 93 | //! |
| 94 | //! # 0.19.0: `widget` is [`piece`], because the word went to the description |
| 95 | //! |
| 96 | //! `makeover-layout` 0.20.0 added `Region::Widget`, the third tier between a |
| 97 | //! primitive and `Region::Bespoke`: a named assembly of primitives that each |
| 98 | //! renderer draws its own way. That is host-agnostic and sits *above* every |
| 99 | //! renderer. |
| 100 | //! |
| 101 | //! This crate's `widget` module is the opposite end of the same stack — |
| 102 | //! renderer-local, the answer to what a meter looks like in cells, taking a |
| 103 | //! description plus what only a terminal knows. Two different things wearing |
| 104 | //! one word, and the collision would have been worst exactly here, in a crate |
| 105 | //! that has to implement the tier. |
| 106 | //! |
| 107 | //! So this half moved and the description's half kept the word. That direction |
| 108 | //! is not arbitrary: a second or third party naming a widget is naming the |
| 109 | //! layout kind, and nothing outside this tree ever needed a word for a drawing |
| 110 | //! routine. `WidgetStyle` is `PieceStyle`. |
| 111 | //! |
| 112 | //! # 0.27.0: a bar for a bounded number, and an option that is not offered yet |
| 113 | //! |
| 114 | //! `makeover-layout` 0.28.0's form findings, at the renderer that has the bar |
| 115 | //! already. A [`makeover_layout::FieldKind::Range`] is drawn as [`piece::meter`]'s |
| 116 | //! cells with its two ends read out either side, because the ends are what the |
| 117 | //! question means and a terminal is where it would be easiest to quietly show a |
| 118 | //! figure instead. An unbounded range falls back to the text path rather than |
| 119 | //! to bounds this crate invented. |
| 120 | //! |
| 121 | //! `Choice::unavailable` is the one place the three-tone convention's muted is |
| 122 | //! the truth rather than the lie it warns about: that option will not answer, |
| 123 | //! and the reason it will not now sits on its row. |
| 124 | //! |
| 125 | //! `Field::placeholder` on a chooser, the third finding, is already answered |
| 126 | //! here and needed nothing: this renderer draws every option of a select at |
| 127 | //! once, so an unanswered one is a list with no mark against any row rather |
| 128 | //! than an empty box with nothing in it. |
| 129 | //! |
| 130 | //! # 0.33.0: an interval is one line |
| 131 | //! |
| 132 | //! `makeover-layout` 0.34.0's [`makeover_layout::FieldKind::Interval`], drawn |
| 133 | //! as the low end, the word `to`, and the high end. One line because it is one |
| 134 | //! question: two rows would read as two questions, which is exactly what the |
| 135 | //! kind exists to stop the description saying, and a terminal has no |
| 136 | //! side-by-side boxes to fall back on. |
| 137 | //! |
| 138 | //! - **An open end draws the bound it falls back to**, muted, because that is |
| 139 | //! where the axis ends rather than a value anybody set. With no bound to fall |
| 140 | //! back on the end stays blank, which is [`piece::field`]'s standing position |
| 141 | //! on a value this crate would have to invent. |
| 142 | //! - **The word rather than a dash.** A dash between two numbers is a minus |
| 143 | //! sign to anyone reading a signed axis, and half the measured axes are |
| 144 | //! signed: audiofiles filters loudness in dBFS. |
| 145 | //! - The unit rides on each end, through the same `measured` the typed path |
| 146 | //! uses, so `90 BPM to 130 BPM` reads without the label being consulted. |
| 147 | //! |
| 148 | //! [`piece::Held::Between`] is the second value, for the reason the description |
| 149 | //! states both names: a separator inside one string would make this crate own a |
| 150 | //! delimiter either end could contain. |
| 151 | //! |
| 152 | //! # 0.32.0: a number reads with its unit |
| 153 | //! |
| 154 | //! `makeover-layout` 0.33.0's `Field::unit`, drawn on the value rather than in |
| 155 | //! the label. A terminal has one line the eye is on -- the number -- and the |
| 156 | //! label is a line above it, so `0.05 s` is the reading and `Attack (s)` two |
| 157 | //! rows up is not. A range shows it after the readout beside the bar; a typed |
| 158 | //! number after the value. Every other kind ignores it, and which those are is |
| 159 | //! `FieldKind::measurable`'s answer rather than a `matches!` kept here. |
| 160 | //! |
| 161 | //! # 0.31.0: the bar fills along the curve |
| 162 | //! |
| 163 | //! `makeover-layout` 0.32.0's [`Curve`](makeover_layout::Curve). Where a value |
| 164 | //! sits on the bar is the curve's answer now, not its proportion of the extent. |
| 165 | //! Under `Curve::Linear` those are the same number, so every range drawn before |
| 166 | //! this is unchanged; under a constant ratio they are not, and a bar filled |
| 167 | //! linearly would put an envelope's whole useful half inside its first cell. |
| 168 | //! |
| 169 | //! The two ends beside the bar do not move: they are `f(0)` and `f(1)`, which |
| 170 | //! is what they always were and is now what the description calls them. |
| 171 | //! |
| 172 | //! # The correction this renderer forced |
| 173 | //! |
| 174 | //! [`makeover_layout::Fill`] briefly carried a `fallback` method, returning |
| 175 | //! `Page` for `Well` so a consumer without `surface-well` had something to |
| 176 | //! use. That is an answer for a renderer that can always paint a colour. Here |
| 177 | //! it is actively wrong: page *is* the surface a well is usually cut into, so |
| 178 | //! falling back to it produces the exact invisibility the fallback was meant |
| 179 | //! to avoid. |
| 180 | //! |
| 181 | //! Substituting one intent for another is renderer policy, not description. |
| 182 | //! The fallback moved out of the description and into |
| 183 | //! `makeover-immediate`, where it belongs, which is the first thing a second |
| 184 | //! renderer was built to find. |
| 185 | |
| 186 | |
| 187 | |
| 188 | use ; |
| 189 | use Buffer; |
| 190 | use Rect; |
| 191 | use Color; |
| 192 | |
| 193 | /// The description this crate renders, re-exported. |
| 194 | /// |
| 195 | /// Every entry point here takes a type from it, so a consumer would otherwise |
| 196 | /// have to depend on the description separately and keep two version |
| 197 | /// requirements in step to name the argument it is already being handed. |
| 198 | pub use makeover_layout; |
| 199 | |
| 200 | /// A loaded makeover theme, resolved to the colours ratatui draws with. |
| 201 | /// |
| 202 | /// Behind the `theme` feature: it is the only thing here that needs `makeover` |
| 203 | /// itself, and that crate embeds the shipped theme files. A consumer that wants |
| 204 | /// [`frame`] and nothing else should not carry them. |
| 205 | |
| 206 | |
| 207 | |
| 208 | |
| 209 | pub use ; |
| 210 | |
| 211 | /// Columns, narrowing, cell parts and the sort caret, over ratatui's own |
| 212 | /// [`Table`](ratatui::widgets::Table). |
| 213 | /// |
| 214 | /// Not feature-gated. It needs no theme: [`TableStyle`](table::TableStyle) |
| 215 | /// carries the tones, and a caller with a loaded theme gets them from |
| 216 | /// `TableStyle::from_theme` instead of supplying them. |
| 217 | |
| 218 | |
| 219 | /// Word wrapping that answers a height and a drawing from the same measurement. |
| 220 | /// |
| 221 | /// The half ratatui's `Paragraph` leaves out. A flow layout asks for rows at a |
| 222 | /// width and then draws into the rect it was given, and if the two disagree by |
| 223 | /// one row a node draws over the one under it. |
| 224 | |
| 225 | |
| 226 | /// A meter, a badge, a control, a figure and a form field. |
| 227 | /// |
| 228 | /// The pieces below the level [`table`] works at. Not feature-gated, on |
| 229 | /// [`table`]'s footing: [`PieceStyle`](piece::PieceStyle) carries the tones, |
| 230 | /// and a caller with a loaded theme reaches for `PieceStyle::from_theme`. |
| 231 | |
| 232 | |
| 233 | /// How many colours the terminal can actually show. |
| 234 | /// |
| 235 | /// Only [`Fidelity::Ansi16`] changes what this crate draws. Above it, colour |
| 236 | /// separates a raised surface from a well on every shipped theme, and the |
| 237 | /// glyph fallback below never fires. Recorded rather than inferred, because a |
| 238 | /// caller that quantised its palette knows the answer and this crate cannot |
| 239 | /// recover it from the colours afterwards. |
| 240 | |
| 241 | |
| 242 | /// Sixteen colours. Depth cannot be carried by colour: a well collapses |
| 243 | /// onto its face on 18 of 31 themes and a bevel loses an edge on all 31. |
| 244 | Ansi16, |
| 245 | /// The 6x6x6 cube and the grey ramp. Enough on 27 of 31 themes. |
| 246 | Ansi256, |
| 247 | /// 24-bit. The only failures left belong to the theme, not the terminal. |
| 248 | |
| 249 | TrueColor, |
| 250 | |
| 251 | |
| 252 | |
| 253 | /// Read the terminal's own claim, from `COLORTERM` then `TERM`. |
| 254 | /// |
| 255 | /// Deliberately credulous, and the fall-through is where that is decided. |
| 256 | /// An unrecognised `TERM` is assumed capable, because the two wrong answers |
| 257 | /// do not cost the same: guessing [`TrueColor`](Self::TrueColor) on a |
| 258 | /// limited terminal costs some fidelity, and guessing |
| 259 | /// [`Ansi16`](Self::Ansi16) on a capable one throws away colour the user |
| 260 | /// paid for — and, for a caller that quantises its palette off this answer, |
| 261 | /// throws away the whole theme. `COLORTERM` is routinely stripped by ssh |
| 262 | /// and by multiplexers, so an unrecognised name is the common case rather |
| 263 | /// than the exotic one: `foot`, `xterm` and `screen` all land here. |
| 264 | /// |
| 265 | /// So sixteen colours is reached by naming the terminals that really have |
| 266 | /// them. The list is short and it does not grow: these are the fixed |
| 267 | /// consoles, and `TERM=linux` is the case this exists for — the Linux |
| 268 | /// virtual console, which is what an installer and a machine with no |
| 269 | /// desktop draw on. |
| 270 | |
| 271 | |
| 272 | Selffrom_env |
| 273 | &var.unwrap_or_default, |
| 274 | &var.unwrap_or_default, |
| 275 | |
| 276 | |
| 277 | |
| 278 | /// [`detect`](Self::detect) with the environment passed in, so the decision |
| 279 | /// can be tested without mutating a process-wide variable from a parallel |
| 280 | /// test. |
| 281 | |
| 282 | |
| 283 | if colorterm.contains || colorterm.contains |
| 284 | return SelfTrueColor; |
| 285 | |
| 286 | match term |
| 287 | "linux" | "vt100" | "vt220" | "ansi" | "dumb" => SelfAnsi16, |
| 288 | _ if term.contains || term.contains => SelfAnsi256, |
| 289 | _ => SelfTrueColor, |
| 290 | |
| 291 | |
| 292 | |
| 293 | /// Whether colour alone can tell a raised surface from a well here. |
| 294 | |
| 295 | pub const |
| 296 | !matches! |
| 297 | |
| 298 | |
| 299 | |
| 300 | /// The resolved colours this renderer needs. |
| 301 | /// |
| 302 | /// Supply them already quantised to whatever the terminal can show. That is |
| 303 | /// what makes [`Palette::shows`] a plain inequality rather than a colour-space |
| 304 | /// calculation: by the time a colour reaches here, the question of what the |
| 305 | /// terminal will actually paint has been answered. |
| 306 | |
| 307 | |
| 308 | /// `surface-page`. |
| 309 | pub page: Color, |
| 310 | /// `surface-raised`. |
| 311 | pub raised: Color, |
| 312 | /// `surface-overlay`. |
| 313 | pub overlay: Color, |
| 314 | /// `surface-well`, absent on makeover before 2.3.0. |
| 315 | pub well: , |
| 316 | /// `bevel-light`. |
| 317 | pub bevel_light: Color, |
| 318 | /// `bevel-dark`. |
| 319 | pub bevel_dark: Color, |
| 320 | /// What the terminal can show. Defaults to [`Fidelity::TrueColor`]. |
| 321 | pub fidelity: Fidelity, |
| 322 | |
| 323 | |
| 324 | |
| 325 | /// Resolve a surface intent, or `None` where this renderer has no colour |
| 326 | /// for it. |
| 327 | /// |
| 328 | /// No substitution happens here. A missing intent stays missing, and |
| 329 | /// [`frame`] answers it with structure instead of with a different colour. |
| 330 | /// That rule is what lets the wildcard below be a real answer rather than |
| 331 | /// a hole: [`Fill`] is `#[non_exhaustive]` from `makeover-layout` 0.4.0 |
| 332 | /// onward, so the description can name a surface this renderer has not |
| 333 | /// learned to paint, and saying so is better than failing to build. |
| 334 | |
| 335 | pub const |
| 336 | match fill |
| 337 | Page => Some, |
| 338 | Raised => Some, |
| 339 | Overlay => Some, |
| 340 | Well => self.well, |
| 341 | // Includes Fill::Sunken, which this renderer has no tone for: a |
| 342 | // terminal cell has one background, so a surface set back by |
| 343 | // colour alone is not a thing it can say. The chosen tab is drawn |
| 344 | // forward instead. |
| 345 | _ => None, |
| 346 | |
| 347 | |
| 348 | |
| 349 | /// Resolve a bevel edge intent. |
| 350 | |
| 351 | pub const |
| 352 | match edge |
| 353 | Light => self.bevel_light, |
| 354 | Dark => self.bevel_dark, |
| 355 | |
| 356 | |
| 357 | |
| 358 | /// Whether painting `fill` over `behind` would show anything. |
| 359 | /// |
| 360 | /// The whole of the terminal's problem in one predicate. On a truecolor |
| 361 | /// terminal this is almost always true; in sixteen colours it is false |
| 362 | /// often enough that a design relying on fills is a design that vanishes. |
| 363 | |
| 364 | |
| 365 | fill != behind |
| 366 | |
| 367 | |
| 368 | /// Whether this palette can express a bevel as two distinct edges. |
| 369 | /// |
| 370 | /// Measured, this is the wrong thing to worry about: the two edge colours |
| 371 | /// never quantise onto each other, at any depth, on any shipped theme. |
| 372 | /// What does happen is an edge vanishing into the *face* it is drawn on, |
| 373 | /// on every theme at sixteen colours. Kept because a hand-built palette |
| 374 | /// can still collide, and cheap to ask. |
| 375 | |
| 376 | |
| 377 | self.bevel_light != self.bevel_dark |
| 378 | |
| 379 | |
| 380 | /// Whether depth has to be carried by glyphs rather than by colour. |
| 381 | /// |
| 382 | /// True when the terminal cannot separate the two surfaces, which is the |
| 383 | /// sixteen-colour case and nothing else. |
| 384 | |
| 385 | pub const |
| 386 | !self.fidelity.separates_depth |
| 387 | |
| 388 | |
| 389 | |
| 390 | /// The characters a frame's edges and corners are drawn with. |
| 391 | /// |
| 392 | /// Per side rather than per axis, because the set that reads best as a bevel |
| 393 | /// does not use the same glyph on opposite sides: a half-block edge is only |
| 394 | /// half a cell, and which half it occupies is what says where the edge is. |
| 395 | /// Box-drawing sets fill `top`/`bottom` and `left`/`right` with the same |
| 396 | /// character and lose nothing by it. |
| 397 | /// |
| 398 | /// Three sets. [`BEVEL`] is what a terminal that can show two tones gets. The |
| 399 | /// other two exist because at sixteen colours the glyphs are the only thing |
| 400 | /// left to carry depth: a well cannot be filled distinctly and a bevel loses |
| 401 | /// an edge, so a raised card and a well would otherwise be the same |
| 402 | /// single-tone box. A doubled line reads as standing off the page and a light |
| 403 | /// one as cut into it, which is the same claim the fill and the bevel make in |
| 404 | /// colour. |
| 405 | |
| 406 | pub |
| 407 | pub(crate) top: &'static str, |
| 408 | pub(crate) bottom: &'static str, |
| 409 | pub(crate) left: &'static str, |
| 410 | pub(crate) right: &'static str, |
| 411 | pub(crate) top_left: &'static str, |
| 412 | pub(crate) top_right: &'static str, |
| 413 | pub(crate) bottom_left: &'static str, |
| 414 | pub(crate) bottom_right: &'static str, |
| 415 | /// Whether the two corners where light meets shadow carry both tones in |
| 416 | /// one cell, foreground over background. |
| 417 | /// |
| 418 | /// Only a half-cell glyph can: it already divides the cell, so the split |
| 419 | /// costs nothing and the corner reads as a transition rather than as one |
| 420 | /// edge overrunning the other. A box-drawing corner is a single stroke |
| 421 | /// with no such division, so those sets say `false` and both shared |
| 422 | /// corners go to dark — see [`paint_bevel_with`] for why that particular |
| 423 | /// fallback and not the other one. |
| 424 | pub(crate) split_corners: bool, |
| 425 | |
| 426 | |
| 427 | /// Half-blocks, which is what a bevel actually wants. |
| 428 | /// |
| 429 | /// A cell is roughly 8x17 device pixels, so a half-block along the top and a |
| 430 | /// half-cell column down the side are about the same number of pixels and the |
| 431 | /// edge reads as even thickness. Box-drawing cannot do that: `─` and `│` are |
| 432 | /// both a thin stroke through the middle of the cell, identical on all four |
| 433 | /// sides, which draws a *line* rather than a lit edge and gives up the light |
| 434 | /// model that makes a bevel legible. |
| 435 | /// |
| 436 | /// Adopted from `alloy_tui`, which reached this independently and got there |
| 437 | /// first (2026-07-26, two days before this crate existed). |
| 438 | pub const BEVEL: GlyphSet = GlyphSet |
| 439 | top: "▀", |
| 440 | bottom: "▄", |
| 441 | left: "▌", |
| 442 | right: "▐", |
| 443 | top_left: "▛", |
| 444 | // The two shared corners are the split ones: an upper half continues the |
| 445 | // lit top edge while the lower half starts the shaded right edge, and the |
| 446 | // mirror of that at bottom left. |
| 447 | top_right: "▀", |
| 448 | bottom_left: "▄", |
| 449 | bottom_right: "▟", |
| 450 | split_corners: true, |
| 451 | ; |
| 452 | |
| 453 | pub const LIGHT: GlyphSet = GlyphSet |
| 454 | top: "─", |
| 455 | bottom: "─", |
| 456 | left: "│", |
| 457 | right: "│", |
| 458 | top_left: "┌", |
| 459 | top_right: "┐", |
| 460 | bottom_left: "└", |
| 461 | bottom_right: "┘", |
| 462 | split_corners: false, |
| 463 | ; |
| 464 | |
| 465 | pub const DOUBLE: GlyphSet = GlyphSet |
| 466 | top: "═", |
| 467 | bottom: "═", |
| 468 | left: "║", |
| 469 | right: "║", |
| 470 | top_left: "╔", |
| 471 | top_right: "╗", |
| 472 | bottom_left: "╚", |
| 473 | bottom_right: "╝", |
| 474 | split_corners: false, |
| 475 | ; |
| 476 | |
| 477 | /// Paint a two-tone edge around the outside of `area`. |
| 478 | /// |
| 479 | /// Light takes the top and left, dark the bottom and right. What happens at |
| 480 | /// the two corners where they meet depends on what the terminal can show. |
| 481 | /// Above sixteen colours the edge is drawn in half-blocks and those corners |
| 482 | /// carry both tones, one per half-cell. At sixteen it is box-drawing, whose |
| 483 | /// single stroke has no half to give, so both shared corners go to dark. |
| 484 | /// |
| 485 | /// Costs a cell on each side, which a pixel renderer's bevel does not. Use the |
| 486 | /// [`Rect`] returned by [`frame`] rather than assuming the area is intact. |
| 487 | |
| 488 | paint_bevel_with; |
| 489 | |
| 490 | |
| 491 | /// Which glyphs to draw with, given what the terminal can show. |
| 492 | /// |
| 493 | /// Above sixteen colours the two tones are available and [`BEVEL`] renders |
| 494 | /// them as light. At sixteen the tones collapse, so the box-drawing sets carry |
| 495 | /// the distinction in weight instead, and `depth` picks which: a doubled frame |
| 496 | /// for a raised card and a light one for everything else. `None` means the |
| 497 | /// caller is drawing a bevel with no depth behind it, which is never the |
| 498 | /// doubled case. |
| 499 | |
| 500 | if !palette.needs_glyph_depth |
| 501 | return BEVEL; |
| 502 | |
| 503 | match depth |
| 504 | Some => DOUBLE, |
| 505 | _ => LIGHT, |
| 506 | |
| 507 | |
| 508 | |
| 509 | |
| 510 | if area.width < 2 || area.height < 2 |
| 511 | return; |
| 512 | |
| 513 | let = bevel.edges; |
| 514 | let light = palette.edge; |
| 515 | let dark = palette.edge; |
| 516 | |
| 517 | let = ; |
| 518 | let = ; |
| 519 | |
| 520 | // Light first: top edge and left edge, corners included. |
| 521 | for x in x0..=x1 |
| 522 | buf.set_symbol.set_fg; |
| 523 | |
| 524 | for y in y0..=y1 |
| 525 | buf.set_symbol.set_fg; |
| 526 | |
| 527 | // Dark second, so on a set without split corners the two shared ones land |
| 528 | // on it by draw order alone. |
| 529 | for x in x0..=x1 |
| 530 | buf.set_symbol.set_fg; |
| 531 | |
| 532 | for y in y0..=y1 |
| 533 | buf.set_symbol.set_fg; |
| 534 | |
| 535 | |
| 536 | buf.set_symbol.set_fg; |
| 537 | buf.set_symbol.set_fg; |
| 538 | |
| 539 | if set.split_corners |
| 540 | // Where light meets shadow, both tones share the cell: the half the |
| 541 | // glyph fills is the foreground and the half it leaves is the |
| 542 | // background, so the corner is a transition rather than one edge |
| 543 | // overrunning the other. |
| 544 | buf |
| 545 | .set_symbol |
| 546 | .set_fg |
| 547 | .set_bg; |
| 548 | buf |
| 549 | .set_symbol |
| 550 | .set_fg |
| 551 | .set_bg; |
| 552 | else |
| 553 | // Both shared corners to dark. Not arbitrary: it is the same rule |
| 554 | // `makeover-immediate` produces by drawing its dark polyline second, |
| 555 | // so a control does not change which corner is lit when it moves |
| 556 | // between a terminal and a window. A single-stroke corner has no half |
| 557 | // to give the other tone, so this is the only rule available to these |
| 558 | // sets anyway. |
| 559 | buf.set_symbol.set_fg; |
| 560 | buf.set_symbol.set_fg; |
| 561 | |
| 562 | |
| 563 | |
| 564 | /// Draw a region at a given [`Depth`] and return the area left for content. |
| 565 | /// |
| 566 | /// The fill is painted only when it would be visible against what is already |
| 567 | /// in the buffer. Everything else is the edge, which is why a well still reads |
| 568 | /// as a well on a terminal that cannot colour one. |
| 569 | |
| 570 | if area.is_empty |
| 571 | return area; |
| 572 | |
| 573 | let behind = buf.bg; |
| 574 | |
| 575 | if let Some = depth.fill.and_then |
| 576 | && shows |
| 577 | |
| 578 | for y in area.top..area.bottom |
| 579 | for x in area.left..area.right |
| 580 | buf.set_bg; |
| 581 | |
| 582 | |
| 583 | |
| 584 | |
| 585 | match depth.bevel |
| 586 | Some if area.width >= 2 && area.height >= 2 => |
| 587 | // Colour separates raised from well wherever it can. Where it |
| 588 | // cannot, the glyphs do, and only then: a doubled frame on every |
| 589 | // terminal would be shouting. |
| 590 | let set = set_for; |
| 591 | paint_bevel_with; |
| 592 | new |
| 593 | |
| 594 | _ => area, |
| 595 | |
| 596 | |
| 597 | |
| 598 | |
| 599 | |
| 600 | use *; |
| 601 | |
| 602 | |
| 603 | Palette |
| 604 | page: Indexed, |
| 605 | raised: Indexed, |
| 606 | overlay: Indexed, |
| 607 | well, |
| 608 | bevel_light: Indexed, |
| 609 | bevel_dark: Indexed, |
| 610 | fidelity: TrueColor, |
| 611 | |
| 612 | |
| 613 | |
| 614 | |
| 615 | empty |
| 616 | |
| 617 | |
| 618 | |
| 619 | |
| 620 | // The 18-of-31 case: no surface-well token at all. |
| 621 | let p = palette; |
| 622 | let mut buf = buffer; |
| 623 | frame; |
| 624 | // No fill was available, but the region still reads as recessed. |
| 625 | assert_eq!; |
| 626 | assert_eq!; |
| 627 | |
| 628 | |
| 629 | |
| 630 | |
| 631 | let p = palette; |
| 632 | let mut buf = buffer; |
| 633 | // Everything behind is already page-coloured, and the well quantised |
| 634 | // onto it. Painting it would be a no-op that hides the real problem. |
| 635 | for y in 0..4 |
| 636 | for x in 0..6 |
| 637 | buf.set_bg; |
| 638 | |
| 639 | |
| 640 | frame; |
| 641 | assert!; |
| 642 | // The edge is what carries the meaning here. |
| 643 | assert_eq!; |
| 644 | |
| 645 | |
| 646 | |
| 647 | |
| 648 | let p = palette; |
| 649 | let mut buf = buffer; |
| 650 | frame; |
| 651 | assert_eq!; |
| 652 | |
| 653 | |
| 654 | |
| 655 | |
| 656 | // makeover-layout 0.14.0's Depth::Overlay, and the wiring under it was |
| 657 | // already here: `Palette::fill` has answered `Fill::Overlay` since this |
| 658 | // crate had a palette. So this asserts the route rather than building |
| 659 | // one, and it is the assertion that would catch the route being lost. |
| 660 | let p = palette; |
| 661 | let mut buf = buffer; |
| 662 | let inner = frame; |
| 663 | |
| 664 | assert_eq!; |
| 665 | // A surface over the page is separated by the lift and by what sits |
| 666 | // behind it, so it takes no edge -- and with no edge drawn, nothing is |
| 667 | // given up to one: the content area is the whole region. |
| 668 | assert_eq!; |
| 669 | assert_eq!; |
| 670 | |
| 671 | |
| 672 | |
| 673 | |
| 674 | let p = palette; |
| 675 | let mut buf = buffer; |
| 676 | paint_bevel; |
| 677 | assert_eq!; // top-left |
| 678 | assert_eq!; // top edge |
| 679 | assert_eq!; // left edge |
| 680 | assert_eq!; // bottom-right |
| 681 | assert_eq!; // bottom edge |
| 682 | assert_eq!; // right edge |
| 683 | |
| 684 | |
| 685 | // Half-cell glyphs divide the cell already, so the corner where light |
| 686 | // meets shadow can hold both rather than picking one. |
| 687 | |
| 688 | |
| 689 | let p = palette; |
| 690 | let mut buf = buffer; |
| 691 | paint_bevel; |
| 692 | let top_right = &buf; |
| 693 | assert_eq!; |
| 694 | assert_eq!; |
| 695 | let bottom_left = &buf; |
| 696 | assert_eq!; |
| 697 | assert_eq!; |
| 698 | |
| 699 | |
| 700 | // A single-stroke corner has no half to give the second tone, so the |
| 701 | // box-drawing sets keep the old rule: both shared corners to dark, which |
| 702 | // is what makeover-immediate produces by drawing its dark polyline second. |
| 703 | // Changing that would move the lit corner between a terminal and a window. |
| 704 | |
| 705 | |
| 706 | let p = Palette |
| 707 | fidelity: Ansi16, |
| 708 | ..palette |
| 709 | ; |
| 710 | let mut buf = buffer; |
| 711 | paint_bevel; |
| 712 | assert_eq!; |
| 713 | assert_eq!; |
| 714 | assert_eq!; |
| 715 | assert_eq!; |
| 716 | |
| 717 | |
| 718 | // The whole outline, as a reader sees it. Asserted as glyphs because the |
| 719 | // shape is the point: an even-weight edge on all four sides, which is what |
| 720 | // box-drawing could not give. |
| 721 | |
| 722 | |
| 723 | let p = palette; |
| 724 | let mut buf = empty; |
| 725 | paint_bevel; |
| 726 | let rows: = |
| 727 | .map |
| 728 | .collect; |
| 729 | assert_eq!; |
| 730 | |
| 731 | |
| 732 | |
| 733 | |
| 734 | let p = palette; |
| 735 | let mut buf = buffer; |
| 736 | paint_bevel; |
| 737 | assert_eq!; |
| 738 | |
| 739 | |
| 740 | |
| 741 | |
| 742 | // Not a failure: one box is still a boundary. The palette says so |
| 743 | // rather than the renderer pretending otherwise. |
| 744 | let flat = Palette |
| 745 | bevel_dark: Indexed, |
| 746 | ..palette |
| 747 | ; |
| 748 | assert!; |
| 749 | assert!; |
| 750 | |
| 751 | |
| 752 | |
| 753 | |
| 754 | let p = palette; |
| 755 | let mut buf = buffer; |
| 756 | let inner = frame; |
| 757 | assert_eq!; |
| 758 | // Flat takes no cells, because it draws no edge. |
| 759 | let same = frame; |
| 760 | assert_eq!; |
| 761 | |
| 762 | |
| 763 | |
| 764 | |
| 765 | // Colour cannot separate raised from well here: the fill collapses on |
| 766 | // most themes and an edge vanishes on all of them. The frame has to |
| 767 | // say it some other way or the two become the same box. |
| 768 | let p = Palette |
| 769 | fidelity: Ansi16, |
| 770 | ..palette |
| 771 | ; |
| 772 | assert!; |
| 773 | let mut raised = buffer; |
| 774 | frame; |
| 775 | let mut well = buffer; |
| 776 | frame; |
| 777 | assert_eq!; |
| 778 | assert_eq!; |
| 779 | assert_ne!; |
| 780 | |
| 781 | |
| 782 | |
| 783 | |
| 784 | // The doubled fallback must not fire where colour already works, or |
| 785 | // every modern terminal gets a heavier frame it did not need. What it |
| 786 | // gets instead is the half-block bevel. |
| 787 | for f in |
| 788 | let p = Palette |
| 789 | fidelity: f, |
| 790 | ..palette |
| 791 | ; |
| 792 | assert!; |
| 793 | let mut buf = buffer; |
| 794 | frame; |
| 795 | assert_eq! |
| 796 | buf.symbol, |
| 797 | BEVEL.top_left, |
| 798 | "{f:?} got a heavier frame" |
| 799 | ; |
| 800 | assert_ne!; |
| 801 | |
| 802 | |
| 803 | |
| 804 | // Raised and well are both bevels and differ only in which way they are |
| 805 | // lit, so above sixteen colours they draw the same glyphs and the tones |
| 806 | // carry the difference. That is exactly what stops holding at Ansi16, and |
| 807 | // why the doubled set exists. |
| 808 | |
| 809 | |
| 810 | let p = palette; |
| 811 | let mut raised = buffer; |
| 812 | frame; |
| 813 | let mut well = buffer; |
| 814 | frame; |
| 815 | assert_eq!; |
| 816 | assert_eq!; |
| 817 | assert_eq!; |
| 818 | |
| 819 | |
| 820 | |
| 821 | |
| 822 | assert!; |
| 823 | assert!; |
| 824 | assert!; |
| 825 | assert!; |
| 826 | |
| 827 | |
| 828 | // Sixteen colours is reached by naming a console, never by failing to |
| 829 | // recognise a terminal. `COLORTERM` is stripped by ssh and by every |
| 830 | // multiplexer, so an unrecognised name carries no evidence at all, and a |
| 831 | // caller quantising its palette off this answer would flatten a whole theme |
| 832 | // on the strength of it. |
| 833 | |
| 834 | |
| 835 | let f = from_env; |
| 836 | assert_eq!; |
| 837 | assert_eq!; |
| 838 | assert_eq!; |
| 839 | assert_eq!; |
| 840 | |
| 841 | |
| 842 | |
| 843 | |
| 844 | let f = from_env; |
| 845 | assert_eq!; |
| 846 | assert_eq!; |
| 847 | assert_eq!; |
| 848 | |
| 849 | |
| 850 | |
| 851 | |
| 852 | let f = from_env; |
| 853 | assert_eq!; |
| 854 | assert_eq!; |
| 855 | assert_eq!; |
| 856 | // And a claim of 24-bit beats the name, which is only ever a floor. |
| 857 | assert_eq!; |
| 858 | assert_eq!; |
| 859 | |
| 860 | |
| 861 | |
| 862 | |
| 863 | let p = palette; |
| 864 | let mut buf = buffer; |
| 865 | let inner = frame; |
| 866 | assert_eq!; |
| 867 | |
| 868 | |
| 869 |