pub struct Act<'a> {
pub label: &'a str,
pub key: Option<&'a str>,
pub tone: Tone,
pub state: Option<State>,
pub hint: Option<&'a str>,
pub commits: bool,
pub leading: bool,
}Fields§
§label: &'a strWhat the control says.
key: Option<&'a str>The key that reaches it where a host has keys.
The one member written for a terminal before there was one. A webview
hangs it off accesskey or ignores it; a terminal has nothing else to
offer, so this is the whole of how a control is reached there.
tone: ToneWhat pressing it means. Tone::Danger is the destructive one.
state: Option<State>Disabled, or nothing said.
State::Disabled is what changes what a renderer may do: see
State::suppresses_interaction, which is what says a disabled control
is drawn and not reachable. A control’s focus is not sayable here at
all: see the crate header, “Reach, focus and the focus ring”.
hint: Option<&'a str>A sentence that is always true of this control, shown rather than hunted for.
Standing help, not a message and not a tooltip. Half the hosts that read this have no pointer: a hover is one spelling of it, and the shipped apps reached for that spelling only because egui and a browser both had one. What is being said is that the sentence is true, never that it is hidden until a pointer arrives.
§Why it is here rather than a layer up
A hint left to quasi_router::Act alone means each renderer draws it
for itself: makeover_tui had no hint to read, so quasi-tui built
the muted line, and quasi-immediate called on_hover_text outside
crate::Act rather than inside it. Field::hint was here the whole
time, so the same idea sat at two layers depending on which thing
carried it, and a host that was not quasi could say it of a field and
not of a control.
What kept it out was price rather than doubt: this crate declares
links, so a member here moves 25 manifests across 12 repos. That is a
release’s forward-fix pass, which is a cost and was being read as a
barrier.
§What a renderer owes it
Somewhere to put it, or nothing. Dropping it is legitimate; drawing it
instead of the label is not, and neither is drawing it in a way that
takes it out of the accessible tree, which is the failure title alone
has on a browser. Nothing may live only in a hint.
None is a control whose label is the whole of it, which is nearly all
of them.
commits: boolWhether pressing it commits: the one control that locks in what the reader has staged.
A form’s submit, or the verb over a set of ticked rows. Wiki
explicit-commit-affordance is the ruling: changing a control stages a
change, and a separate, visible control commits it, and the commit is
what the reader sees. So the control has to be told apart from the
controls beside it that only navigate or stage, and wiki
look-restoration says how far that goes: the mark goes on the control
that commits and on nothing else, not on every control that writes.
§What a renderer owes it
A spelling the reader can pick out at a glance, and the same one every
time. A webview draws the default-button ring the Platinum specimen
picked and never shipped; a terminal writes [ Label ] where an
ordinary control is < Label >; an immediate-mode host strokes a frame
round the button. Nothing else changes: a committing control takes its
tone, its key, its state and its hint exactly as any other.
§Why a member and not a renderer’s inference
Each renderer could guess it from the node a control sits in, and each
was left to: makeover-tui grew filled_act for a form’s submit, which
no caller in the tree reached, while the webview drew every submit like
every other button. A fact the description has is said here once, which
is the reason hint is here too.
false on nearly every control.
leading: boolWhether this is the act the screen is for: the one thing a reader came to this screen to do.
Reply on a mail reader, Start or Complete on a task, Queue on a compose. At most one per screen, and most screens have none, because a list is for reading.
§Why it is not commits
They answer different questions and a screen can want both on different
controls. commits is “pressing this locks in what you staged”, which
wiki explicit-commit-affordance and look-restoration reserve for the
control that commits and nothing else. A sub-form’s Add commits
honestly under that rule, so on goingson’s task overview the boldest
control on the screen was a subtask’s Add while the screen’s own
Start/Complete was an ordinary button. Widening commits to mean
“primary” would break a settled ruling and put every sub-form’s Add back
in competition; this is the other axis instead.
The two compose. A form that is the screen’s work carries both, and a renderer draws both marks on it.
§Why a member and not a renderer’s inference
commits’ own test, applied to itself: which act a
screen is for is a fact the description has and no renderer can work
out. The nearest guess, that a band’s acts outrank a body’s, gets the
mail reader and the compose window wrong: their primary act sits in a
pane. It also makes emphasis a function of where a control happens to
sit.
§What a renderer owes it
A spelling distinct from the commit mark, since a control may wear
both. The suite’s answer is that leading fills and committing
outlines: a webview gives it the --action ground with
--content-on-action on it while the commit ring stays a frame outside
the bevel; a terminal reverses it, keeping [ ] for the commit; an
immediate-mode host fills the button rather than stroking it. Fill and
frame are separable, so a control that is both reads as both.
false on nearly every control, and on every control of a screen that
is only for reading.
Implementations§
Source§impl<'a> Act<'a>
impl<'a> Act<'a>
Sourcepub const fn committing(self) -> Self
pub const fn committing(self) -> Self
The control that commits what the reader staged; see
commits.
Sourcepub const fn leading(self) -> Self
pub const fn leading(self) -> Self
The act this screen is for; see leading.
Separate from committing and freely combined with
it: a form that is the screen’s own work is both.