Skip to main content

makeover_layout/
region.rs

1use crate::Depth;
2
3// Names this module's prose links to, resolved for rustdoc.
4#[allow(unused_imports)]
5use crate::{Fill, Heading, Readiness, RowPart, Selector, Sort, Track};
6
7/// A named part of a screen.
8///
9/// The thing `makeover-geometry` deliberately does not name: it names the space
10/// *between* things by relationship, and nothing named the things. Six named
11/// members, taken from what the two webview apps actually use, plus
12/// [`Region::Handover`] and [`Region::Ceded`] for the parts no description
13/// should reach. Both apps'
14/// `layout.css` currently names exactly two things, `.raised` and `.well`, so
15/// this layer is absent rather than divergent, which makes it the cheapest of
16/// the schemas to add and the easiest to over-build.
17///
18/// `#[non_exhaustive]`, for [`RowPart`]'s and [`Readiness`]' reason: the member
19/// after this one should not be a lockstep event across three renderers.
20#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
21#[non_exhaustive]
22pub enum Region<'a> {
23    /// A full-width strip with a title slot and an actions cluster, either of
24    /// which may be empty. goingson's `.page-header`, Balanced Breakfast's
25    /// `.header` and `.detail-header` are all this, differing only in which
26    /// slots they fill.
27    Band,
28    /// A persistent column beside the content, holding navigation.
29    Sidebar,
30    /// A region of content with its own scroll.
31    Pane,
32    /// Things that belong together, and nothing else.
33    ///
34    /// The block [`Heading::Section`] names, which the vocabulary otherwise
35    /// cannot contain. A section heading is a leaf sitting
36    /// *beside* the things it names, so nothing said where a section started or
37    /// ended and a renderer learned one had ended only because the next heading
38    /// arrived.
39    ///
40    /// # The measurement
41    ///
42    /// 41 [`Heading::Section`] sites across the ten screens described through
43    /// the router, not one of them contained. audiofiles' settings screen is the
44    /// clearest: one pane holding a heading, a field, a heading, two toggles, a
45    /// heading, a toggle and a heading, which is four sections and no
46    /// containers. Under the hand-written CSS the ports are replacing the same
47    /// block is spelled `.settings-section` in goingson, `.form-section` and
48    /// `.content-section` in the MNW server, `.help-section` in Balanced
49    /// Breakfast: three apps, four names, one shape.
50    ///
51    /// # Why the existing members were the wrong answer
52    ///
53    /// [`Pane`](Self::Pane) is what apps reached for, and it is 28 of the 45
54    /// regions in the described screens. It claims a scroll of its own and
55    /// [`Depth::Well`], so four settings groups inside a pane are four wells
56    /// inside a well and four scroll contexts. Neither claim is true of a group.
57    ///
58    /// [`Widget`](Self::Widget) is wrong from the other side. Its own docs say a
59    /// widget is never how a primitive gets added by the back door, and a run of
60    /// related controls under a heading is furniture any app would have, which
61    /// is the generic-against-bespoke bar a primitive has to clear.
62    ///
63    /// # What it does not carry
64    ///
65    /// **A heading.** A group usually has one and it is an ordinary node in the
66    /// body, the way it already was. A group of related toggles with no heading
67    /// is a real thing and a mandatory slot would forbid it.
68    ///
69    /// **A depth.** [`Depth::Flat`], on [`Handover`](Self::Handover)'s reasoning:
70    /// it inherits, and an app that wants its group in a well puts it in a
71    /// [`Pane`](Self::Pane), which composes rather than adding a knob here.
72    ///
73    /// **A colour.** Distinguishing sibling groups by colour is the thing this
74    /// member was asked for and it is deliberately not stated here. The
75    /// description says these things belong together; which of the theme's
76    /// categorical colours a renderer reaches for, and whether it reaches for
77    /// one at all, is derived from sibling order at the renderer. A terminal
78    /// that tints nothing and separates with a rule is honouring this.
79    Group,
80    /// Two panes side by side, where the left chooses what the right shows.
81    Split,
82    /// Peer regions across, all of them equals.
83    ///
84    /// A kanban board's columns, and the shape [`Split`](Self::Split) is not:
85    /// a split's two panes stand in a master-detail relationship, where the
86    /// left chooses what the right shows. These choose nothing about each
87    /// other. Each is a whole region and the set is the arrangement.
88    ///
89    /// # What it does not carry
90    ///
91    /// **How many.** The children say, and a count here would be a second
92    /// source for something the description already states by containing them.
93    ///
94    /// **How wide.** Peers are equal by definition, so there is no [`Share`] to
95    /// state. A board whose columns wanted different widths would be a
96    /// different member, and no app has one.
97    ///
98    /// **What happens when there is no room.** Scroll across, wrap, or collapse
99    /// to one column at a time: all three are right on some host, none is
100    /// derivable from the description, and every one of them is presentation.
101    /// A terminal that stacks them vertically is honouring this, not degrading
102    /// it.
103    ///
104    /// # Why it is not an `Arrangement`
105    ///
106    /// [`Arrangement`] is the page's shape, and a board is usually a region
107    /// *inside* a page that also has a band over it. Naming it here composes;
108    /// naming it there would make a screen either a board or a list-detail and
109    /// never a band above a board. It also keeps [`Arrangement::share`]
110    /// meaningful, which a peer arrangement has no answer for.
111    Columns,
112    /// A set of panes, one visible at a time, and a [`Selector::Tabs`] that
113    /// chooses between them.
114    ///
115    /// Which way the strip runs is a [`Strip`], stated by whoever holds the
116    /// region and carried beside it, the way [`Showing`] carries the index.
117    /// Where the strip goes when there is no room is still the renderer's to
118    /// measure, the same as its overflow.
119    TabGroup,
120    /// Content over a scrim, taking input until dismissed.
121    Modal,
122    /// A region this crate names the *place* of, whose contents the app still
123    /// owes every host.
124    ///
125    /// The escape hatch, and the thing that keeps the description honest about
126    /// its own limits. A day-plan timeline, a kanban board, a calendar and the
127    /// paint interaction over the timeline are not describable here and are not
128    /// going to become describable: a description expressive enough to produce
129    /// a timeline is a widget library wearing a description's name.
130    ///
131    /// But a screen containing one still has to be a screen. Without this
132    /// member the description covers only the boring screens, and the four that
133    /// make goingson worth using would need a second, undescribed path beside
134    /// the router. Two paths is how the vocabulary starts drifting from the app
135    /// again, which is the exact failure this crate exists to end.
136    ///
137    /// So the description says "a thing called `day-plan` goes here" and stops.
138    /// The name is opaque: this crate never interprets it, and no renderer is
139    /// expected to know what it means beyond handing the space over.
140    ///
141    /// # What separates it from [`Ceded`](Self::Ceded)
142    ///
143    /// **A fill is owed here in every host's currency.** A renderer handed one
144    /// of these and given nothing to put in it is looking at a hole the app
145    /// meant to fill, and saying so is the honest drawing. [`owed`](Self::owed)
146    /// is how it asks.
147    ///
148    /// That is the whole of the split. Before it there was one opaque member,
149    /// so a region the description had given up on and a region nobody had
150    /// converted yet were the same value, and both drew as a silently empty
151    /// box on the two renderers that answer no fill.
152    Handover {
153        /// What the app calls it. Never interpreted here.
154        name: &'a str,
155    },
156    /// A region this crate names the place of, whose contents no host is owed.
157    ///
158    /// The other half of the old single opaque member. The app has decided this
159    /// space is not the description's to fill and is not going to become so:
160    /// a chart, a waveform, a rendered picture of domain data with marks
161    /// painted over it at positions no description knows.
162    ///
163    /// **Silence is the correct drawing.** A renderer with no fill for this
164    /// draws nothing and is right to; unlike [`Handover`](Self::Handover) there
165    /// is nothing missing. That is what makes the pair worth two members rather
166    /// than a flag: the two want opposite behaviour from a renderer that cannot
167    /// fill them, and one name cannot carry both.
168    ///
169    /// The measured sites are MNW's analytics charts, which already carry the
170    /// ruling that a bar chart is not describable and should not be, and
171    /// audiofiles' waveform, whose exclusion had no vocabulary to live in and
172    /// was recorded in a doc comment instead.
173    Ceded {
174        /// What the app calls it. Never interpreted here.
175        name: &'a str,
176    },
177    /// A named assembly of things the vocabulary already says.
178    ///
179    /// The third tier, between a primitive and the two opaque members.
180    ///
181    /// # What separates it from the two members either side
182    ///
183    /// A primitive is a thing every renderer draws from scratch, and the test
184    /// it has to pass is that every host has an honest answer. A carousel fails
185    /// that test — a terminal has no carousel — which is the same refusal
186    /// `Node::Html` got and is why the carousel sat unsayable for months.
187    ///
188    /// [`Handover`](Self::Handover) fails it from the other side. It is for
189    /// what one app owns and nobody will build twice, and it carries *no*
190    /// contents: the description names the place and stops. A carousel is
191    /// furniture any app would have, and every part of it — an ordered set of
192    /// frames, a position, prev and next, a strip of position indicators — is
193    /// already sayable. Only the assembly had no name.
194    ///
195    /// So this member is the pair the other two are not: a name **and**
196    /// contents. The contents are the assembly, in the region's own body, said
197    /// in members that already exist.
198    ///
199    /// # Why the name does not have to be understood
200    ///
201    /// A renderer that recognises the name draws it the way its host does it: a
202    /// carousel in a webview, a pager with a count in a terminal, a selector in
203    /// egui. A renderer that does not recognise it walks the body, which is
204    /// primitives all the way down and which it can already draw.
205    ///
206    /// That is what lets the widget set be **open** without every renderer
207    /// knowing every widget. An unrecognised widget degrades to its assembly
208    /// instead of failing, so a second or third party can name one without
209    /// three renderers releasing in lockstep to accept it. Contrast
210    /// [`Handover`](Self::Handover), which no renderer can degrade: there is
211    /// nothing under it to fall back to.
212    ///
213    /// # What it does not do
214    ///
215    /// A widget is an assembly of things the vocabulary *already* says, so it
216    /// buys no expressive power. Anything needing a member the vocabulary does
217    /// not have is a finding about the vocabulary, and the answer to a finding
218    /// is to add the member. A widget is never the way a primitive gets added
219    /// by the back door. A timeline is describable because [`Track`] was added
220    /// to say it, not because a screen was dressed up as an assembly.
221    Widget {
222        /// What the assembly is called. This crate never interprets it, and a
223        /// renderer is free not to know it.
224        name: &'a str,
225    },
226}
227
228impl<'a> Region<'a> {
229    /// How the region sits on what is behind it.
230    #[must_use]
231    pub const fn depth(self) -> Depth {
232        match self {
233            Self::Band | Self::Sidebar | Self::Split | Self::TabGroup => Depth::Flat,
234            // Flat, and it inherits. A group says its contents belong together
235            // and says nothing about the surface they sit on, so a group in a
236            // pane is in a well and a group on the page is on the page. An app
237            // wanting one lifted puts it in a `Pane`.
238            Self::Group => Depth::Flat,
239            // Flat, and it is the container rather than the columns. Each
240            // column is its own region and brings its own depth; a well here
241            // would put a second edge around a row of wells.
242            Self::Columns => Depth::Flat,
243            // A pane is looked into, the same as a table body or a tag tree.
244            Self::Pane => Depth::Well,
245            Self::Modal => Depth::Raised,
246            // Flat because it inherits: a bespoke region takes the depth of
247            // whatever frames it. An app that wants its timeline in a well puts
248            // it in a `Pane`, which composes rather than adding a knob here.
249            //
250            // A widget inherits for the same reason and it matters more here,
251            // because a widget is drawn by whichever renderer recognises it. A
252            // depth set here would be this crate deciding that a carousel is
253            // raised on every host, which is the kind of value the deferral
254            // rule exists to refuse.
255            Self::Handover { .. } | Self::Ceded { .. } | Self::Widget { .. } => Depth::Flat,
256        }
257    }
258
259    /// Whether this crate can say anything about the region's contents.
260    ///
261    /// A renderer walks the description and hands every region it understands
262    /// to the right drawing code. This is how it tells the two apart, and the
263    /// reason it is a method rather than a `matches!` at each renderer: there
264    /// is exactly one opaque member and there should stay exactly one.
265    ///
266    /// [`Widget`](Self::Widget) is described, and that is the whole of what
267    /// separates it from the two opaque members here. All three carry a name
268    /// this crate never interprets; only the widget carries contents under it.
269    /// A renderer that does not recognise a widget's name still walks its body,
270    /// so there is nothing for it to hand over and nothing it cannot draw.
271    #[must_use]
272    pub const fn described(self) -> bool {
273        !matches!(self, Self::Handover { .. } | Self::Ceded { .. })
274    }
275
276    /// Whether a fill is owed here, for a renderer that has none.
277    ///
278    /// The question the single opaque member could not answer. True for
279    /// [`Handover`](Self::Handover): the app meant to fill this and a renderer
280    /// with nothing to put in it should say so. False for everything else,
281    /// [`Ceded`](Self::Ceded) included, where silence is the correct drawing
282    /// because nothing is missing.
283    ///
284    /// A method rather than a `matches!` at each renderer, for
285    /// [`described`](Self::described)'s reason: three renderers writing the
286    /// same match is three chances to disagree about what an empty region
287    /// means.
288    #[must_use]
289    pub const fn owed(self) -> bool {
290        matches!(self, Self::Handover { .. })
291    }
292
293    /// The name an app gave this region, if it gave one.
294    ///
295    /// [`Handover`](Self::Handover), [`Ceded`](Self::Ceded) and
296    /// [`Widget`](Self::Widget) are the members that carry a name, for two
297    /// different purposes: the first two say what the app puts in the space,
298    /// the third says what the assembly under it is called. A renderer dispatching on either wants the string without
299    /// caring which member it came from, and writing that `matches!` at each
300    /// renderer is how the two drift apart.
301    #[must_use]
302    pub const fn name(self) -> Option<&'a str> {
303        match self {
304            Self::Handover { name } | Self::Ceded { name } | Self::Widget { name } => Some(name),
305            // Spelled out rather than a wildcard, so a member added later has
306            // to answer whether it carries a name instead of inheriting `None`
307            // by sitting under a `_`.
308            Self::Band
309            | Self::Sidebar
310            | Self::Pane
311            | Self::Group
312            | Self::Split
313            | Self::Columns
314            | Self::TabGroup
315            | Self::Modal => None,
316        }
317    }
318}
319
320/// How many of a region's children are visible at once.
321///
322/// One sentence covering three shapes: *this region holds several children and
323/// shows some of them, and the reader can change which.* A tab group, a
324/// carousel and a disclosure all need it, and without it a renderer has two
325/// moves: hardcode a widget name, or draw every child. That is what puts
326/// per-widget code in renderers.
327///
328/// # What is here and what is not
329///
330/// The *kind*, and only the kind. Which child is currently up is the current
331/// answer, and a layer that defers every address does not hold the current
332/// answer either — the split [`Selector`] already makes, where this crate says
333/// what kind of chooser a thing is and the router says which option is picked.
334/// So a holder of regions carries the index and the per-child label beside this.
335///
336/// # What a renderer does with it
337///
338/// Derives its chrome, once, for every widget rather than per name:
339///
340/// - Children carrying labels get a strip of the labels, the current one marked.
341/// - Children carrying none get previous, position, next.
342/// - [`AtMostOne`](Self::AtMostOne) over one child gets a summary line that
343///   opens.
344///
345/// The name on [`Region::Widget`] survives as app vocabulary, for a renderer
346/// that wants to do something *special* with one, which is what it should have
347/// been from the start.
348///
349/// Degradation runs the way it already did: a renderer ignoring this draws every
350/// child, which is more content rather than less.
351#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, Default)]
352#[non_exhaustive]
353pub enum Showing {
354    /// Every child, in order. What every region did before this existed.
355    #[default]
356    All,
357    /// Exactly one. A carousel, a tab group.
358    One,
359    /// One, or none. A disclosure, which is closed until it is opened.
360    AtMostOne,
361}
362
363impl Showing {
364    /// Whether the reader can change which child is up.
365    ///
366    /// The question every renderer's region arm asks before deriving any
367    /// chrome, and a method rather than a `matches!` at each renderer for
368    /// [`Region::name`]'s reason: three renderers writing the same comparison is
369    /// how they come to disagree about a member added later.
370    #[must_use]
371    pub const fn selective(self) -> bool {
372        !matches!(self, Self::All)
373    }
374
375    /// Whether showing nothing is a legal state.
376    ///
377    /// True only for [`AtMostOne`](Self::AtMostOne). A renderer needs this to
378    /// know whether its control closes as well as moves: a carousel's row moves
379    /// between frames and never reaches empty, and a disclosure's summary line
380    /// is the same control wearing its closed state.
381    #[must_use]
382    pub const fn dismissible(self) -> bool {
383        matches!(self, Self::AtMostOne)
384    }
385}
386
387/// Which way a [`Region::TabGroup`]'s strip runs.
388///
389/// Across is a row of tabs over the panes it opens; down is a column of them
390/// beside the panes. Both are the folder semantic, one pane showing at a time,
391/// and both put the strip first, so a tab is always read before the pane it
392/// opens.
393///
394/// # Why the description says it
395///
396/// Leaving it to each renderer was the earlier reading, and the measurement
397/// ran the other way: every renderer picked across, so a tab group that wanted
398/// a column had no way to get one. MNW's settings sections were a column beside
399/// their panes until they were described, and describing them flattened them
400/// into a row. Counted on the MNW dashboards (2026-09-12): five strips run
401/// across, one runs down today, four long panels want a strip down beside
402/// their sections, and two screens carry both. Max's ruling is that the
403/// language says both.
404///
405/// # What is here and what is not
406///
407/// The direction, carried beside the region the way [`Showing`] is: this crate
408/// names the fact and the holder of the region states it, because the region
409/// member is a place and not a record of how it is dressed.
410///
411/// **No default.** A tab group that says nothing about its strip is the silence
412/// this type exists to end, so a holder has to pick one.
413///
414/// **No breakpoint.** Room is still the renderer's to measure. A strip that
415/// runs down may fold over its panes when there is no room beside them, the
416/// way a row folds into a menu; what it may not do is run across when there
417/// is room, because then the description stopped being what was drawn.
418#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
419pub enum Strip {
420    /// A row over the panes.
421    Across,
422    /// A column beside the panes.
423    Down,
424}
425
426impl Strip {
427    /// Whether the tabs stack vertically.
428    ///
429    /// What a renderer asks for the two things that turn on direction rather
430    /// than on placement: the accessibility orientation a strip announces, and
431    /// which pair of arrow keys moves between its tabs. A method for
432    /// [`Region::name`]'s reason, so three renderers do not each write the
433    /// comparison.
434    #[must_use]
435    pub const fn runs_down(self) -> bool {
436        matches!(self, Self::Down)
437    }
438}
439
440/// A window onto a sequence: where it starts, how much it covers, and how long
441/// the sequence is when that is known.
442///
443/// The mechanism under two things the vocabulary deliberately keeps apart. A
444/// carousel is a window of one frame over children that are all present; a
445/// paged list is a window of a page over rows most of which were never fetched.
446/// Those are different facts and they stay different types — [`Showing`] says
447/// which child is up, [`Paging`] says where a reader is in a query — but the
448/// arithmetic underneath is one piece of code, so a terminal and a browser
449/// cannot come to disagree about which frame is last.
450///
451/// # Why `of` is optional and `count` is not
452///
453/// `count` is what is on screen and is therefore always known. `of` is the
454/// length of the thing being windowed, and a host that cannot count says so by
455/// leaving it empty **for the life of the screen**. It is never "not counted
456/// yet": see "First paint is final paint" in the crate header. A total that
457/// turns up on a later pass widens the text that prints it.
458///
459/// # Clamping
460///
461/// Every derivation clamps rather than refusing, and a zero `count` answers
462/// `None` rather than dividing. A window past the end is a bug in the host, and
463/// a renderer that answered it by drawing nothing would report a region that
464/// vanished, which is the hardest kind of bug to find from what is on screen.
465/// [`Share::percent`] clamps for the same reason.
466#[derive(Debug, Clone, Copy, PartialEq, Eq, Default)]
467pub struct Window {
468    /// The index into the sequence where the window starts.
469    pub from: usize,
470    /// How many the window covers. One, for a carousel.
471    pub count: usize,
472    /// How long the sequence is, when the host can say.
473    pub of: Option<usize>,
474}
475
476impl Window {
477    /// A window of `count`, starting at `from`, over a sequence of unknown
478    /// length.
479    #[must_use]
480    pub const fn new(from: usize, count: usize) -> Self {
481        Self {
482            from,
483            count,
484            of: None,
485        }
486    }
487
488    /// How long the sequence is.
489    #[must_use]
490    pub const fn of(mut self, of: usize) -> Self {
491        self.of = Some(of);
492        self
493    }
494
495    /// One item of a sequence whose length is known. A carousel frame.
496    #[must_use]
497    pub const fn frame(at: usize, of: usize) -> Self {
498        Self {
499            from: at,
500            count: 1,
501            of: Some(of),
502        }
503    }
504
505    /// Which window this is, counting from zero.
506    ///
507    /// `None` when `count` is zero, which is the only input with no answer
508    /// rather than a clamped one.
509    #[must_use]
510    pub const fn index(self) -> Option<usize> {
511        if self.count == 0 {
512            return None;
513        }
514        Some(self.from / self.count)
515    }
516
517    /// How many windows the sequence holds.
518    ///
519    /// `None` unless both the length and a non-zero `count` are known. A
520    /// partial answer here would be a renderer drawing "of 0".
521    #[must_use]
522    pub const fn windows(self) -> Option<usize> {
523        match self.of {
524            Some(of) if self.count > 0 => Some(of.div_ceil(self.count)),
525            _ => None,
526        }
527    }
528
529    /// Whether anything sits before this window.
530    #[must_use]
531    pub const fn has_before(self) -> bool {
532        self.from > 0
533    }
534
535    /// How many sit after this window, when the length is known.
536    ///
537    /// Here rather than in each renderer for [`Showing::selective`]'s reason:
538    /// three of them writing the same subtraction is how they come to disagree,
539    /// and this one has an underflow in it for whoever writes it fourth.
540    #[must_use]
541    pub const fn after(self) -> Option<usize> {
542        match self.of {
543            Some(of) => Some(of.saturating_sub(self.from.saturating_add(self.count))),
544            None => None,
545        }
546    }
547
548    /// Whether anything sits after it.
549    ///
550    /// `true` when the length is unknown: a host that cannot count cannot rule
551    /// out more, and offering a way forward that turns out to be empty is the
552    /// cheaper of the two mistakes.
553    #[must_use]
554    pub const fn has_after(self) -> bool {
555        match self.of {
556            Some(of) => self.from.saturating_add(self.count) < of,
557            None => true,
558        }
559    }
560
561    /// The window with `from` brought inside the sequence.
562    ///
563    /// A no-op when the length is unknown, since there is nothing to clamp
564    /// against.
565    #[must_use]
566    pub const fn clamped(mut self) -> Self {
567        if let Some(of) = self.of
568            && self.from >= of
569        {
570            // `max(1)` by hand: `Ord::max` is not const yet, and a zero-count
571            // window would otherwise clamp onto the end rather than inside it.
572            let step = if self.count == 0 { 1 } else { self.count };
573            self.from = of.saturating_sub(step);
574        }
575        self
576    }
577}
578
579/// Where a reader is in a set that arrived in parts.
580///
581/// A [`Window`] wearing the paged reading of itself. Distinct from a carousel's
582/// window at the top level on purpose, because the intent differs and a call
583/// site should say which one it means, while the arithmetic below is shared so
584/// the two cannot drift apart.
585///
586/// # The two idioms, and which one a renderer may draw
587///
588/// Load-more and numbered pages are both this type. Which is honest is
589/// [`paged`](Self::paged): a set whose page size is known can be drawn as
590/// "Page 3 of 8", and one without can only be drawn as "150 of 400" and a way
591/// forward. Saying it here rather than letting each renderer guess is the point
592/// — three renderers inferring it from the numbers is how they come to disagree.
593///
594/// # What it does not carry
595///
596/// No addresses. `makeover-layout` cannot name an action, and the way to ask for
597/// the next part is the host's: `quasi_router` pairs this with the addresses the
598/// same way `Row` pairs its parts with `Row::activate`. That split is the reason
599/// this type is reusable by a carousel, which has nothing to ask.
600#[derive(Debug, Clone, Copy, PartialEq, Eq, Default)]
601pub struct Paging {
602    /// The window onto the set.
603    pub window: Window,
604    /// Whether the parts are a fixed size, and so whether pages are countable.
605    ///
606    /// `false` for load-more, where the window simply grew and "page 2" would
607    /// name nothing.
608    pub paged: bool,
609}
610
611impl Paging {
612    /// A page of `per`, starting at `from`.
613    #[must_use]
614    pub const fn pages(from: usize, per: usize) -> Self {
615        Self {
616            window: Window::new(from, per),
617            paged: true,
618        }
619    }
620
621    /// The first `shown`, with more behind them.
622    ///
623    /// The load-more shape: the window starts at the beginning and grows, so
624    /// there is no page to number.
625    #[must_use]
626    pub const fn more(shown: usize) -> Self {
627        Self {
628            window: Window::new(0, shown),
629            paged: false,
630        }
631    }
632
633    /// How many there are altogether.
634    ///
635    /// Left unsaid by a host that cannot count, and left unsaid **for good**:
636    /// a total arriving later widens whatever prints it. See "First paint is
637    /// final paint" in the crate header.
638    #[must_use]
639    pub const fn of(mut self, of: usize) -> Self {
640        self.window = self.window.of(of);
641        self
642    }
643
644    /// Which page this is, counting from one, when pages are countable.
645    ///
646    /// One-based because it is read aloud. [`Window::index`] is the zero-based
647    /// form for anyone indexing with it.
648    #[must_use]
649    pub const fn page(self) -> Option<usize> {
650        if !self.paged {
651            return None;
652        }
653        match self.window.index() {
654            Some(index) => Some(index + 1),
655            None => None,
656        }
657    }
658
659    /// How many pages there are, when that is countable.
660    #[must_use]
661    pub const fn pages_total(self) -> Option<usize> {
662        if !self.paged {
663            return None;
664        }
665        self.window.windows()
666    }
667
668    /// How many are on screen.
669    #[must_use]
670    pub const fn shown(self) -> usize {
671        self.window.count
672    }
673
674    /// How many there are, when the host counted.
675    #[must_use]
676    pub const fn total(self) -> Option<usize> {
677        self.window.of
678    }
679
680    /// How many are not shown yet, when the host counted.
681    ///
682    /// The figure a load-more control puts in its label. `None` is the honest
683    /// and common case: a set that cannot say how many more there are still has
684    /// a way to ask for them.
685    #[must_use]
686    pub const fn remaining(self) -> Option<usize> {
687        self.window.after()
688    }
689
690    /// Whether there is anything further on.
691    #[must_use]
692    pub const fn has_more(self) -> bool {
693        self.window.has_after()
694    }
695
696    /// Whether there is anything back the other way.
697    #[must_use]
698    pub const fn has_previous(self) -> bool {
699        self.window.has_before()
700    }
701}
702
703/// How much of the width an arrangement's first region takes.
704///
705/// Nothing said how much room a region got, so every renderer invented its own
706/// number and two hosts showing one screen disagreed about its proportions. A
707/// webview never noticed, because the stylesheet answered once for every
708/// consumer; a terminal has no stylesheet to inherit from, so `quasi-tui`
709/// picked 24 columns for a sidebar and 40% for a list pane and neither had
710/// anything behind it.
711///
712/// # A proportion, never a unit
713///
714/// Held as a percentage, and that is the only form it comes in. A description
715/// carrying columns would be describing a terminal and one carrying pixels a
716/// webview, and the whole point is that both honour the same fact: a terminal
717/// resolves it against a column count, a webview writes it into a grid, and
718/// neither has to know what the other did.
719///
720/// It is not [`makeover_geometry::Ratio`]'s job either, which was the first
721/// guess. Geometry is scales that answer the same for every screen and takes
722/// no input that would let a sidebar screen differ from a list-detail one.
723///
724/// [`makeover_geometry::Ratio`]: https://docs.rs/makeover-geometry
725#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
726pub struct Share(u8);
727
728impl Share {
729    /// What a sidebar takes, when nobody says otherwise.
730    ///
731    /// A quarter. `quasi-tui` drew 24 columns, which is a quarter of a
732    /// 96-column terminal and about a fifth of a wide one; a quarter is that
733    /// number said in the form a webview can honour too.
734    pub const SIDEBAR: Self = Self(25);
735
736    /// What the list side of a list-detail takes, when nobody says otherwise.
737    ///
738    /// `quasi-tui`'s 40%, which was already a proportion and is the one number
739    /// this member did not have to invent.
740    pub const LIST: Self = Self(40);
741
742    /// A share of the width, as a percentage.
743    ///
744    /// Clamped to 5..=95 rather than refused. A description that asked for a
745    /// region of nothing is a bug in the app, and a renderer drawing a region
746    /// zero cells wide reports it as a region that vanished, which is the
747    /// hardest kind of bug to find from what is on the screen.
748    #[must_use]
749    pub const fn percent(percent: u8) -> Self {
750        Self(if percent < 5 {
751            5
752        } else if percent > 95 {
753            95
754        } else {
755            percent
756        })
757    }
758
759    /// The share as a percentage.
760    #[must_use]
761    pub const fn as_percent(self) -> u8 {
762        self.0
763    }
764
765    /// This share of a width, rounded to the nearest whole unit.
766    ///
767    /// What a terminal calls to turn the proportion into columns. At least one,
768    /// because a region the description named should be visible: a screen
769    /// 3 columns wide is unusable either way, and a sidebar that is there is a
770    /// truer picture of the description than a sidebar that is not.
771    #[must_use]
772    pub const fn of(self, whole: u16) -> u16 {
773        let taken = (whole as u32 * self.0 as u32).div_ceil(100);
774        if taken == 0 { 1 } else { taken as u16 }
775    }
776}
777
778/// How a screen is laid out.
779///
780/// Three, and no one of them is a variant of another. goingson is list-detail,
781/// Balanced Breakfast is sidebar plus content, and MNW's embeds are one region
782/// filling the document. The tab group is a modifier rather than a member,
783/// because goingson uses it *inside* the same content region rather than
784/// instead of one.
785///
786/// This exists at all because the router has to be able to express a screen
787/// rather than only a control. Discovering the arrangement layer missing after
788/// the renderers exist is a redesign; naming two now is a morning.
789///
790/// # Why the share rides here
791///
792/// A share is per-arrangement: how much a sidebar takes and how much a list
793/// side takes are different questions, and this enum is the only thing that
794/// knows which one is being asked. Geometry would have had to invent a channel
795/// to be told.
796///
797/// [`list_detail`](Self::list_detail) and
798/// [`sidebar_content`](Self::sidebar_content) build these with the default
799/// shares, so a screen that has no opinion does not have to have one.
800#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
801pub enum Arrangement {
802    /// A list that chooses what the detail beside it shows.
803    ListDetail {
804        /// Whether the detail side is a [`Region::TabGroup`].
805        tabbed: bool,
806        /// How much of the width the list side takes.
807        share: Share,
808    },
809    /// Navigation down the side, content filling the rest.
810    SidebarContent {
811        /// How much of the width the sidebar takes.
812        share: Share,
813    },
814    /// One region, filling the document.
815    ///
816    /// The other two are both about dividing a width between two regions, so a
817    /// screen that is one region had to borrow one of them and then undo it:
818    /// MNW's five embeds said `list_detail(title, false)` and the host spent a
819    /// `display: block` cancelling the grid that produced. A host writing CSS
820    /// to contradict the description rather than to add to it is the thing
821    /// this member ends.
822    ///
823    /// Carries no [`Share`], because there is no division to describe. That is
824    /// why [`share`](Self::share) answers `None` here.
825    Single,
826}
827
828impl Arrangement {
829    /// A list and a detail beside it, at the default share.
830    #[must_use]
831    pub const fn list_detail(tabbed: bool) -> Self {
832        Self::ListDetail {
833            tabbed,
834            share: Share::LIST,
835        }
836    }
837
838    /// A sidebar and content beside it, at the default share.
839    #[must_use]
840    pub const fn sidebar_content() -> Self {
841        Self::SidebarContent {
842            share: Share::SIDEBAR,
843        }
844    }
845
846    /// How much of the width the first region takes, when two regions divide it.
847    ///
848    /// `None` for [`Single`](Self::Single): one region takes the width, and a
849    /// renderer that asked how to divide it was asking the wrong question. It
850    /// answers `Option` rather than a full-width `Share` so that a host cannot
851    /// quietly draw a one-region screen as a grid with an empty second column.
852    #[must_use]
853    pub const fn share(self) -> Option<Share> {
854        match self {
855            Self::ListDetail { share, .. } | Self::SidebarContent { share } => Some(share),
856            Self::Single => None,
857        }
858    }
859
860    /// The same arrangement, at this share.
861    ///
862    /// [`Single`](Self::Single) is returned unchanged: it has no division to
863    /// set, so a share named for it is a statement about nothing rather than an
864    /// error worth refusing a screen over.
865    #[must_use]
866    pub const fn with_share(self, share: Share) -> Self {
867        match self {
868            Self::ListDetail { tabbed, .. } => Self::ListDetail { tabbed, share },
869            Self::SidebarContent { .. } => Self::SidebarContent { share },
870            Self::Single => Self::Single,
871        }
872    }
873}
874
875/// How wide the content of a whole screen runs.
876///
877/// Both are the description's, which is what answering the two together
878/// settled.
879///
880/// Measured in the MNW server, where 69 of 72 templates carry exactly one of
881/// three mutually exclusive classes and the choice is per screen. GoingsOn
882/// reaches for `max-width` 56 times and Balanced Breakfast 12, neither with a
883/// token for it, so three apps were solving one thing by hand.
884///
885/// # Named for the measure, not for MNW's classes
886///
887/// A renderer that is not a browser has to answer this too, and `padded-page`
888/// tells a terminal nothing. The three say how wide the text runs, which is a
889/// question every renderer can answer: a webview with a `max-width`, a terminal
890/// with gutters, an immediate-mode frame with its own width.
891///
892/// `#[non_exhaustive]` for [`Fill`]'s reason. The set is closed today because
893/// the measurement found three, and a fourth arriving should not be a lockstep
894/// release across nine repos.
895#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, Default)]
896#[non_exhaustive]
897pub enum Measure {
898    /// The whole width, with gutters. The default, and 53 of the 69.
899    ///
900    /// What a dashboard, a table and a settings screen want: the content is
901    /// wide because the content *is* wide, and constraining it would waste the
902    /// window.
903    #[default]
904    Wide,
905    /// Capped at a comfortable page width, centred. 13 of the 69.
906    ///
907    /// A form, a sign-in, a purchase. Content that does not get better by
908    /// getting wider, but is not prose either.
909    Contained,
910    /// Capped at a line length that reads well. 3 of the 69.
911    ///
912    /// Prose. The narrowest of the three, and the one with a reason outside
913    /// taste: a line of text past roughly 75 characters costs the reader the
914    /// return sweep.
915    Reading,
916}
917
918impl Measure {
919    /// A stable name, for a renderer that needs to spell it.
920    ///
921    /// Here rather than in each renderer for [`Sort::as_str`]'s reason: three
922    /// renderers spelling one enum is three chances to spell it differently.
923    #[must_use]
924    pub const fn as_str(self) -> &'static str {
925        match self {
926            Self::Wide => "wide",
927            Self::Contained => "contained",
928            Self::Reading => "reading",
929        }
930    }
931}