Updated _Sidebar (markdown)
630d92a
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.
3427034
Merge branch 'master' of github.com:phroun/kittytk.wiki
a7907c9
Drop the chatty asides
Sentences addressing the reader's likely mistakes, telling them what they
usually want, or what to reach for. "This is the part that catches
people", "that is usually what you want", "the one to reach for", "the
first thing to check". Documentation states what the thing does.
Eighteen sentences across nine pages, prose only. No table, example or
claim changed; the generated blocks are untouched and every example still
runs.
848e563
Updated _Sidebar (markdown)
d9f41da
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.
584c37f
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.
f4817b0
Created RadioButton (markdown)
fa084fe
Updated TextInput (markdown)
e920634
Updated Button (markdown)
67421cf
Created CheckBox (markdown)
161b10f
Created Button (markdown)
c88221c
Updated TextInput (markdown)
9948619
Updated Common Properties (markdown)
c147b0e
Merge branch 'master' of github.com:phroun/kittytk.wiki
1322553
Merge branch 'master' of github.com:phroun/kittytk.wiki
1a81749
Created Common Properties (markdown)
2161f8f
TextInput: generate the property and event tables
The two tables now sit inside ktkdoc markers and are written by
cmd/kittytk-wikidoc from the wire vocabulary. Everything around them is
prose and stays hand-written; re-running the tool rewrites the marked
spans and nothing else.
Three corrections with it:
Drop the Go type from the header and rewrite "not yet on the wire" so it
describes what the trinket can do that the protocol cannot yet ask for.
It read as though in-process use were a supported way to write an
application, and it is not -- the protocol is the supported surface.
Stop calling the ^A behavior an Emacs home cycle. Emacs does something
else and does not involve selection. It is a deliberate compromise so
that both the go-to-start and the select-all habit reach something, and
the page now says that instead of misattributing it.
bb99f2e
Updated _Sidebar (markdown)
db5da21
Updated _Sidebar (markdown)
731b9c4
Updated _Sidebar (markdown)
f732a23
Updated _Sidebar (markdown)
4c1c9b7