Window, Splitter, ProgressBar
Window is the largest gap in the index -- every application needs one and
nothing documented it. It states the rules that are not guessable: a window
holds exactly one content trinket, its menu bar and status bar are sibling
top-level objects rather than children, geometry is in desktop units, and
`type` needs a QUOTED string. That last one is worth its own line because
every other fixed-vocabulary property in the toolkit takes a bare word:
new window type=dialog -> type: expected a quoted string
new window type="dialog" -> ok
Splitter and ProgressBar are smaller. Both carry a behavior found by
running them: a splitter clamps position outside 0.0-1.0 rather than
refusing it, and a progress bar re-clamps value when the range changes, so
`value=50 minimum=0 maximum=10` still ends at 10 -- the opposite of
ListView's selected, where order decides the outcome.
Window is added to Home and the sidebar.
48 examples across the seventeen pages run clean against the real
registry; 4 are deliberate error demos and 6 are structural skeletons.
MenuBar, TabTrinket, Separator, Spacer; ledger correction on ListView
MenuBar covers all three types that build a bar, and leads with the thing
that catches people: a menubar is a TOP-LEVEL object adopted as the
connection's chrome, not a child of a window. Also that every item raises
`command` whether or not it has an action= -- one without gets a generated
cmd.auto.N and that is what arrives -- and that `&` mnemonics are
menu-only, with && the escape.
TabTrinket, Separator and Spacer complete the simple end. Two corrections
came out of running them rather than reading them: a separator does NOT
take its direction from the box it sits in (it is horizontal until told
otherwise, so an hbox needs orientation=vertical), and spacer has
width/height for a fixed gap as well as stretch for an elastic one.
ListView's appearance section was wrong. alternate_rows and ledger are
the same switch -- both write one field, and the paint path bands with
the ledger colors either way -- so they do not combine, and
`ledger !alternate_rows` comes out off. The page now says so and points
at ledger as the name to prefer.
Every executable example across all fourteen pages was run against the
real registry: 41 clean, 2 deliberate error demos, 5 structural skeletons
left elided on purpose.
Templates and Aliases, and point the pages that needed it at it
The wire language has template and alias verbs sitting beside new/set/
destroy, and nothing on the wiki mentioned them. Worse, ListView and
ComboBox taught a workaround for a problem templates solve.
A template's children are applied before any instance's properties, so
template Sizes=listview children={...three items...}
lv=new Sizes selected=2
selects the third row, while the same properties in one statement out of
order silently select the first. ListView and ComboBox now lead with that
and keep the manual ordering rule as the single-statement case. Panel
gains a FormRow example, since a layout built more than once is what
templates are for.
The new page covers what running the code showed: instance properties
override the template's, templates chain with the more specific winning,
template children come first and instance children are appended to them,
and keys inside a template body are namespaced under the instance key and
surfaced with key=path. Also the D18 naming rule and every rejection it
produces, each one run rather than assumed.
Two examples were wrong before this landed. font_size=20 came from a
session test that uses a mock factory accepting any property; against the
real registry a button has no font_size, so a reader pasting it would get
an error. And the appended-children example omitted its own template
declaration. Both found by executing the examples rather than parsing
them -- parsing had passed.