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