Tui

Whether there is a terminal program to run at all.

init returns one of these when the program is built with defineProgramOrExit. Start is the ordinary answer and carries the first model. Exit says that the program has nothing to put on the screen and that the command it was started with -- printing a --help, reporting a command line that was wrong -- is the whole of what it does.

Exit is not "quit as soon as you have painted". Nothing is painted: no render message is sent, the runtime never starts Turbo Vision, and the terminal is never switched out from under whatever the output is being piped into. That is the difference that makes it worth having, and it is why the decision has to be made in init rather than answered by a later message.

The controls.

The order of the array they are in is two things, and both are easy to change by accident. The caret opens on the first view in it that can hold one, and Tab walks the array from there, so this array is the tab order. Build it as one literal where you can; a views assembled out of pieces is where the order goes wrong, and it went wrong here -- Tui.fileDialog listed its buttons first for a week, because Array.append fst second makes fst the postfix.

• StaticText -- a run of text. Longer than its rectangle is silently truncated, so budget the columns.

• Button -- sends cmd as a Command event when pressed, or closes a dialog with it. Press with Space; Enter only reaches a button with isDefault = True. takesFocus = False makes one that can still be pressed -- by mouse, or by its ~x~ hotkey -- but never holds the caret, which is what a keypad or a toolbar wants when something else in the window is reading the keyboard. A Canvas has the same field for the same reason.

  title is patched in place, so a button that says what pressing it will do -- ~S~top becoming ~S~tart -- costs its window nothing. The hotkey moves with the caption, because Turbo Vision reads the tildes when the key arrives rather than when the button is built. cmd is not: a button whose command changed is a different button, and gets one.

• InputLine -- a text field. maxLen is how many characters the user may type, and the rectangle needs two columns more than that: one the field spends on itself and one for the caret to sit past the last character. A rectangle any narrower still holds the whole value and shows it scrolled, with a \u{25C4} where the first character was.

  value is written to the field only when it changes in the model, so it never overwrites what the user is typing. allowed is the set of characters it will accept, as a string: Just "0123456789" is a field only digits can be typed into, and Nothing -- which is almost always what you want -- accepts anything. A rejected keystroke does not happen, so nothing is reported and there is nothing for the model to do about it.

  It filters typing and only typing. A value the model sets goes in whatever it contains: the model put it there, and validating what the model itself produced is the model's job. Turbo Vision would refuse to close the dialog and put up an error box; this does not, deliberately.

• History -- the \u{25BC} drop-down beside an input line, holding what was typed into it before. It has no rectangle: it occupies the three columns immediately to the right of the field it names, which is where Turbo Vision puts every one of them, so leave three. List the field before its history, as with a Label. Clicking the arrow -- or pressing Down in the field -- opens a list of items; choosing one puts it in the field and arrives as an ordinary Changed event on the field, because that is what happened.

  The list opens as tall as it is, up to the room the dialog leaves below the field. Borland gives one a fixed seven rows (thistory.cpp:93), which shows six items whatever the list holds; this one is sized from items, so a short list is a short window and a long one gets as much of the dialog as there is. It cannot leave the dialog -- that is Borland's clip and it stays -- so a list longer than the room below its field is scrolled rather than shown whole. Leave room under a field whose drop-down should be read at a glance.

  A single click chooses. Turbo Vision wants a double click or Enter, which is the convention for a list somebody might be browsing; a drop-down is not being browsed. Both still work.

  items is the model's array and nothing else writes to it. Turbo Vision remembers the field for you, in one buffer shared by the whole program; here nothing is remembered until the model decides to remember it, which is usually one Array.pushFirst when a dialog is answered. That also means the list survives a restart if the model saves it, which Turbo Vision's never did.

• ListBox -- gets a scroll bar of its own, in the single column immediately to the right of its rectangle, so leave one. (Turbo Vision puts it on the window's frame, which is right for a window that is a list and nothing else and wrong for anything with two panes in it.) That bar takes the mouse wheel only while the pointer is over the list or over the bar itself, so several lists side by side each scroll under their own pointer -- which is not how Turbo Vision routes a wheel turn, and is the reason this bar is not the stock one. Moving the highlight sends a Focused event; committing an entry (Space, or a double click) sends a Selected one. focused is that highlight seen from the other side: it is written to the list only when the model changes it, so it steers without fighting the arrow keys. Writing it sends no Focused event back, unless the list had to clamp it -- see Event, where the loop that rule exists to break is described.

  chooses is a command name, and it says that committing an entry is the same act as pressing the button that carries that command -- which inside a modal dialog is how a double click opens the file. "" for a list where it is not, which is every list in a window: a Selected event is the whole answer there, and the model is free to do what it likes with it. (Set it in a window anyway and the command travels the route a button's does, arriving as an ordinary Command event. There is nothing wrong with that; it is just longer than answering the Selected you were already sent.) It is a field rather than something the model does when the event arrives because a modal dialog can only be ended by a command, and by the time Selected has crossed the port the dialog is still open with nothing able to close it. Turbo Vision's own TFileDialog does exactly this translation, in C++, inside the dialog (cmFileDoubleClicked becomes cmOK). columns divides the list's rectangle and fills each column downwards, so a two-column list of nine items puts five on the left and four on the right. 1 is the ordinary list. This is what Turbo Vision's own TListViewer has always done and what a list too long for its window often wants instead of a scroll bar.

  top is which item is drawn on the first row, which is a different sentence from focused and is the only place in this package where a model can put the highlight out of sight. Turbo Vision moves this itself to keep the focused item visible and offers no way to say it, because a list's scroll bar tracks focused and not this. 0 is the top, and the next thing that moves the highlight scrolls it back into view of its own accord.

• CheckBoxes -- a group of boxes, ticked with Space. checked is one flag per item, and available one more flag per item: a box whose flag is False is drawn gray, is skipped by the arrow keys and cannot be ticked, which is how a form says that a choice does not apply right now rather than hiding it and moving everything below it up. [] -- the ordinary case -- says nothing about any box, and an array shorter than the cluster says nothing about the ones past its end.

  available and Enabled are different things and both are worth having: this grays one box, and Enabled grays the whole cluster, because a cluster is one view however many boxes are in it.

• MultiCheckBoxes -- the same cluster with more than two states per box. marks is one character per state, in order, drawn between the brackets: " ?X" is a box that cycles blank, ?, X. states is one index into marks per item. Space, a click or the box's hotkey moves an item to the next state and wraps.

  Turbo Vision packs every box's state into one 32-bit word, so items × bits per state has to fit in 32 -- eight boxes of four states, sixteen of three, and the binding says so rather than dropping the last few.

  available works exactly as it does on CheckBoxes.

• RadioButtons -- a group of which exactly one is chosen; selected is its index. available works exactly as it does on CheckBoxes.

• Label -- text bound to another control by its id, so Alt-x on the label focuses the control. List the control before its label: the label has to name a view that already exists.

• ScrollBar -- a scroll bar the model owns, as opposed to the one a list box makes for itself. Moving it sends a Scrolled event, and value written back from the model moves it. Whether it is horizontal or vertical is decided by its rectangle: one column wide is vertical. A click on the arrows steps by arrowStep and a click anywhere else takes the thumb straight to the pointer -- this fork of Turbo Vision does not page with the mouse, so pageStep is reached only from the keyboard (Ctrl-Left/Ctrl-Right, PgUp/PgDn). Every one of those is a single click: unlike other focusable views, a scroll bar does not spend the first one taking focus.

  The wheel is three arrowSteps, and for is what decides where it has to be pointing. Turbo Vision does not deliver a wheel turn to the view under the pointer -- it offers it to every view in the window until one takes it -- so a bar with for = "" answers from anywhere in the window, which is what a window whose only scrollable thing is this bar's wants. Name the view it scrolls, and it answers only over that view or over itself, which is what a window with two scrollable panes in it needs: without it the pane whose bar was listed last takes every turn, wherever the pointer was. List that view before the bar, the same rule a Label follows, and it may be any kind of view -- what a bar like this scrolls is usually a Canvas the model paints.

• Canvas -- paints exactly the lines it is given, and sends KeyPressed events while focused and Clicked and Dragged events for the mouse. This is the escape hatch for anything the stock controls cannot express: Turbo Vision's own calendar and ASCII chart are views of this kind. A line is an array of colored Spans; line makes the common one, which is a whole row in the window's own color. cursor is the terminal's own block cursor, in the canvas's coordinates -- the only piece of a canvas that is not made of characters. Nothing hides it.

  takesFocus means the same thing here as on a Button, and matters more: a focused canvas consumes every key it receives, Tab included, so a canvas that is only there to be looked at or clicked should say False or it will trap the caret. Clicks and drags still arrive either way -- with one exception that belongs to takesFocus = True, and it is deliberate: when something else in the same window holds the selection, Turbo Vision spends the first click on giving it back (TView::handleEvent), so that click, and a drag begun with it, do not reach the model. Every one after it does. A window whose only selectable view is the canvas never sees this, because the canvas is always the selected one; a window with a ScrollBar beside it does. The alternative -- ofFirstClick, which is what a ScrollBar carries -- would make one click both move the selection and act, on a view the user had not been working in, and that is the worse of the two.

  What it does not eat is anything the menu bar or the status line claims first. Both are ofPreProcess views (tmenubar.cpp, tstatusl.cpp), so their hotkeys are offered the key before the focused view is -- which is why Alt-X, F5 and Alt-F3 still work with a canvas focused, and why a program built around one should put every key the user must not lose on the menu bar or the status line. A key that is on neither belongs to the canvas for as long as it has the caret.

• Editor — a text editor. It gets scroll bars of its own, in the column to the right and the row below its rectangle, so leave one of each.

  It is the one view with no contents in it, and that is the whole design. Everything else here is a function of the model and is re-rendered from it; a document is the first thing too big for that, because view runs on every tick of every subscription and a file has no business in a render message. So the editor owns the buffer and the model owns the file: setEditorText puts a document in, readEditor asks for it back, and what arrives in between is an Edited event carrying whether the document is modified, where the caret is, and the three facts a program grays its Edit menu on — a handful of numbers and booleans, not a file. insertIntoEditor is the third call, and the one that puts text in without replacing what is already there.

  autoIndent is the one setting the model owns: Enter copies the leading whitespace of the line above. Turbo Vision's other editor mode, insert versus overwrite, is not a field here, because the Insert key is the user's and a field the user can move is a field the model would spend its time writing back. It arrives on Edited as isOverwrite instead.

  Give it a fixed rectangle and let Grows resize it. This is the one sharp edge of a view whose contents are not in the view. A rectangle is structural — change one and the window is rebuilt — and for every other view that is merely wasteful, because the next render re-supplies the contents. A rebuilt editor is an empty one, and the document is gone, because there was never a copy of it in the render to put back. A rectangle computed from the model (from Resized, say) will therefore throw the document away the first time the terminal changes size. The window's own rectangle is safe: that one is patched rather than rebuilt.

  Tab cannot leave it. TEditor inserts a tab character rather than passing the key on (teditor1.cpp:588 accepts charCode 9 along with the printable range), so an editor is the end of its window's tab ring exactly as a focused Canvas is. A window with an editor and something else to focus therefore needs a key of its own to get back — a command on the menu answered with focus is the shape — and it must not be one TEditor has already claimed, which is nearly every Ctrl letter plus Ins and Del (teditor1.cpp:47). The menu bar is ofPreProcess and is offered every keystroke before the focused view, so a menu accelerator that collides takes the key away from the editor underneath and nothing reports it.

  Everything Turbo Vision's editor does, it does here: insert and overwrite, selection, one level of undo, a clipboard shared between editors, auto indent, word-left and word-right, and the block and line commands from Borland's keymap.

  The command names "clipboard.cut", "clipboard.copy", "clipboard.paste", "editor.clear", "editor.undo" and "editor.selectAll" are built in — put one on a menu and it reaches whichever view has the caret without passing through update at all. The first three are clipboard. and not editor. because an InputLine answers them too; the last three an editor answers alone.

  Two things a menu entry cannot do on its own, both for the same reason: they need something only the model has. Saving needs a file, and writing one is a Task — so the model handles the command and answers with readEditor. Searching needs a string, and asking for one is a dialog — so the model handles that command and answers with findInEditor.

Grows is the odd one, and the only constructor here that is not a widget: it wraps another view to say which of its edges follow the window when the window changes size. See Grow.

Grows
    { grow = Tui.stretch
    , view = ListBox { id = "entries", rect = ..., items = ..., focused = 0, chooses = "", columns = 1, top = 0 }
    }

It is opt-in because most views do not want it, and a wrapper rather than a field on all twelve records so that a view that does not care says nothing at all. It takes a record because a Gren variant takes at most one argument, which is also what makes it look like every other constructor here. It encodes as a field on the view it wraps, so nothing downstream has a Grows to handle. Wrapping a wrapper is legal and the outer one wins.

Enabled is the second of them and works the same way:

Enabled
    { enabled = model.fileIsOpen
    , view = Button { id = "save", ... }
    }

A view wrapped in Enabled False is drawn in the palette's gray, is skipped by Tab, and is handed no keystroke and no click. It is a wrapper for the same reason Grows is -- being available is TView's sfDisabled and so is true of every widget rather than of any one of them, and a view that is always available should not have to say so.

This is not setEnabled, and the difference is the reason it exists. That grays a command, everywhere it appears -- a menu entry, a status line entry, a button carrying it. A view with no command had no way to be unavailable at all, which is every input line, list box, scroll bar and canvas in the package. Use setEnabled for a command and this for a view; a button has both and either will do.

Changing it does not rebuild the view, so an input line keeps what was typed into it and a list keeps its highlight while it is unavailable.

The first control in the list gets focus when the window opens -- the first that can take it, so a row of takesFocus = False buttons is skipped. Turbo Vision itself focuses the last one added, which in a list written top to bottom is the Cancel button; this diverges from that deliberately.

checked and selected are written to the screen only when the model changes them, which is what leaves a tick the user made alone. What the user did comes back as a Changed event instead -- so a cluster works in an ordinary window and not only in a dialog, which was not true before protocol 8 and is the reason Changed exists. A dialog still hands its whole self over at once through values, and that is still the shape a form wants; a control sitting in a window is the other shape, and it is now answered.

Which of Turbo Vision's three window color sets a window is drawn in.

BlueWindow is what a window on the desktop has been since 1990 and what almost every window here wants: white on blue for the frame, yellow on blue for the text inside it. The other two exist because Turbo Vision has always had them, and they are how a program says this window is a different kind of thing without inventing a color of its own -- Borland's own editor used blue for source and cyan for a watch window.

GrayWindow is the color a modal dialog is drawn in, and a window that wants to look like one is the only reason to reach for it. It is also, for one release, what every window in this package was drawn in by mistake -- see beWindow in tvnode.h, which is where the fifth thing it should have been putting back now is.

These are Turbo Vision's three dialog palettes rather than its three window ones, and the difference matters for exactly one reason: a window here can hold buttons, input lines and list boxes, which ask for palette entries past the eight a window palette has. Borland made the first entries of the blue dialog agree with the blue window precisely so that the two could look alike, so this is the window colors with room for a form in them.

Patched in place, like title and rect -- but the redraw it needs is TGroup::redraw and not drawView. A group that has a buffer draws by blitting it, so asking a recolored window to draw itself paints the cached colors straight back and nothing appears to happen. The caret, the z-order and every scroll position survive either way.

Note what this is not. It does not reach a Span that names a Hue: those are absolute colors with nothing in between, deliberately -- examples/palette makes the case. Recoloring a window and keeping its canvases legible is two jobs, and this is only the first.

The sixteen colors a terminal has had since 1981, which is also all that Turbo Vision's palettes deal in. The bottom eight are the plain ones and the top eight their bright counterparts; Brown is bright-shifted into Yellow, and LightGray into White, which is why those two names look out of place.

Pick these against a blue ground. A Window on the desktop is Turbo Vision's blue window -- white on blue for the frame, yellow on blue for the text inside it -- and a modal dialog is the gray one. A Hue names an absolute color with nothing in between, so it is the model and only the model that can put dark blue on blue, and nothing will report it. The four that read well on a blue window are LightCyan and Cyan for something quieter than the text, LightRed for something wrong, and LightGreen for something marked; Blue, Black and DarkGray are for the gray ground of a dialog and vanish on a window.

The same applies in reverse to Yellow: it is what a window's ordinary text already is, so a highlight painted in it is not a highlight. Use on with LightGray for a selection -- blue on light gray is what Turbo Vision's own selected text is -- rather than a background of your own.

One color in a Theme, and the choice between two kinds.

Ansi names one of the sixteen a terminal has always had, and what it actually looks like is whatever scheme the person running the program has set -- so a theme built out of Ansi belongs to their machine and matches the rest of it. Rgb pins the color exactly and looks the same everywhere; it takes one 0xRRGGBB, which is how a color is written down everywhere else and is also what TColorRGB itself takes.

, accent = Rgb 0xF08C00

Neither is a requirement: Turbo Vision quantises an Rgb down to what the terminal says it can do, so a 24-bit theme still runs over ssh -- it just stops being the color you picked. Check a theme at sixteen colors if it is going anywhere but your own terminal.

Note that this is the theme's color type and Hue is the span's. They are separate on purpose: a span color is resolved against a view's palette and has always been one of the sixteen, and giving it 24 bits would mean giving TColorBIOS up in a place where the whole point is to agree with whatever the window is already using.

An entry in a menu, or on the menu bar itself.

• Item -- cmd arrives as a Command event. key is a hotkey that works anywhere ("Alt-A", "F5", "" for none); shortcut is the hint drawn right-aligned in the menu, and is text only.
• Separator -- a horizontal rule.
• SubMenu -- a pull-down. Nests to any depth, and on the menu bar this is what a normal menu is.

A ~ in a title marks the highlighted letter: "~F~ile" draws as File.

Built-in command names work here too: "quit", "close", "zoom", "resize", "next", "prev", "menu", "help", "ok", "cancel", "yes", "no", "cascade" and "tile". Turbo Vision handles those itself and they do not arrive as events.

Then two prefixed sets, and the prefixes say who answers them.

"clipboard.cut", "clipboard.copy" and "clipboard.paste" act on whatever holds the caret, and that is an InputLine as much as an Editor -- both react to these, both light and gray them by themselves as a selection comes and goes. Bind them to keys your users expect and cut, copy and paste work in every field in the program:

, { text = "", key = "Ctrl-Ins", cmd = "clipboard.copy" }
, { text = "", key = "Shift-Ins", cmd = "clipboard.paste" }
, { text = "", key = "Shift-Del", cmd = "clipboard.cut" }

Turbo Vision binds no keys to them itself, deliberately -- picking Ctrl-C for somebody would be picking wrong for somebody else -- so until a program names some, its fields cannot copy or paste. Nothing reports that either.

They share the clipboard copyToClipboard writes and readClipboard reads, so a copy made in a field and a paste made by the model are the same text. A copy made by a field arrives as an ordinary Copied event, for the same reason the model's does: whether anything outside confirmed taking it is a thing worth saying, and it is equally unknown either way.

"editor.clear", "editor.undo" and "editor.selectAll" are the editor's alone -- an input line has no answer to any of the three.

These six are the only prefixed names here, and the prefix is the point: everything else on this list is a word a program is unlikely to want for itself, and these are everyday ones. A built-in name takes the event silently, so a program's own Clear and the editor's cannot both own the bare name -- and the program should have it.

Which makes the same list a set of names your program may not use for anything else. Calling a command "cancel" because there is a Cancel entry on the menu gets an entry that draws, a hotkey that works, and no event ever -- Turbo Vision took it, and outside a dialog cmCancel does nothing at all. Nothing reports this. Pick another name.

One known limitation, and it is the menu bar's rather than this package's. TMenuView::execute runs an event loop of its own while a pull-down is open, so for as long as one is down the program is stopped: no timers, no subscriptions, no renders. Nothing is lost -- a Time.every that should have fired arrives when the menu closes -- and a menu is open for a second at a time, which is why this has never been in the way. It is why popupMenu is not built on Turbo Vision's own TMenuPopup, and why a context menu does not have the problem.

One entry in a context menu, or the line between two groups of them.

shortcut is the right-aligned hint text ("Ctrl-X"), which is a label and nothing else -- a context menu is open for a moment, so there is no global key to bind. That is the difference from MenuItem, along with the one that matters: there is no SubMenu here.

A context menu is flat, and that is a decision rather than an omission. A submenu in Turbo Vision is a menu opened from inside the loop that is running the menu above it, and that loop is a nested getEvent -- it stops timers, subscriptions and renders for as long as it is up. popupMenu is driven by the same pump as everything else here instead, which is what a flat menu makes possible. Turbo Vision's own only context menu -- TEditor's Cut, Copy, Paste and Undo -- is flat too.

Something happened. Route these into your Msg with the onEvent field of defineProgram.

• Command -- a menu entry, status line entry or button, by its cmd name.

• Selected -- an entry in a list box was chosen (Space or double click).

• Focused -- the highlight in a list box moved, because the user moved it -- an arrow key, a click, the mouse wheel. This is how the model learns which entry an "Edit" or "Delete" button should act on; Turbo Vision's own examples read the list's focused member at the moment they need it, which a program that cannot call into C++ has no way to do.

  A highlight the model moved, by rendering a different focused, does not come back as an event -- with one exception that says why the rule is there. It does come back when the list could not do what was asked, which is a focused past the end of a list that just got shorter, because a model left believing a highlight the list does not have is worse than an extra event. Reporting the rest was a feedback loop -- the model writes the highlight, hears that it moved, stores what it hears, and writes it again -- and the mouse wheel is where that showed, since a wheel arrives as a burst of events the model is several renders behind and every echo of a stale index dragged the list back to it.

• KeyPressed -- a key reached a focused canvas. Names look like "Left", "F5", "Alt-X", "Ctrl-A" or "a".

• Clicked -- a canvas was clicked, in the canvas's own coordinates. isRight says which button, and exists for one reason: popupMenu takes a view and a point in it, which is exactly what this event carries. isDouble marks the second click of a double click; the first arrived on its own a moment earlier, so a view that acts on both will act twice.

• Dragged -- the pointer moved on a canvas with a button held down, or the button came up and ended the gesture (isDone). It is always preceded by the Clicked that began it, and always on that same canvas: a drag belongs to the view it started in and keeps reporting there however far off it is pulled, which is why x and y can be negative or past the canvas's own size. They are not clamped on purpose -- a drag above the top row is how a model is asked to scroll, and a clamped number cannot be turned back into that by anybody.

  Which button is held is not repeated here: the press said so, and this is the same gesture.

  A plain click sends none of these, and neither does motion with no button down: a terminal only reports motion while a button is held, and Turbo Vision only asks it to.

  Positions are collapsed to one per pass of the event pump, on the same reasoning as Scrolled: the pointer crossing six cells is six reports and only the sixth is worth a render. The isDone one wins any collapse it is part of, so a whole flick of the wrist can arrive as a single event -- a model that only acts on isDone still sees where the drag ended, and one that draws a selection as it grows should act on every one of them.

• Scrolled -- a ScrollBar moved, by arrow, click, drag, wheel or key. A drag reports only where it ended: the intermediate positions are collapsed, because a model that re-rendered on each of them would redraw the window a dozen times per gesture.

• Resized -- how big the desktop is, in character cells. It arrives once when the application starts and again whenever the terminal changes size, so a program that lays out against it never has to assume 80x25. The desktop rather than the screen because that is the coordinate system a Window's rectangle is written in: the menu bar and the status line are Turbo Vision's and are already subtracted.

• Changed -- the user moved a value: typed in an input line, ticked a check box, chose a radio button. This is the one event about a control whose state Turbo Vision would otherwise keep to itself until a dialog was answered, which is what made a cluster in an ordinary window invisible to the model. It reports what the view says now, so a model that stores it and renders it back writes nothing. Not sent for a value the model set itself -- only a change the model did not already know about is news.

• Edited -- an Editor was edited, or its caret moved. It carries isModified, line and column and not the document: a status line saying "12:4" and a Save that lights up when there is something to save are what a program wants on every keystroke, and a file is not. Coalesced per editor at the pump, so typing a word is one event.

  canUndo, hasSelection and isOverwrite ride along for the same reason the rest does: they are what a program grays Undo and Cut on and what it puts in the OVR corner of a status line, they change for the same reasons the caret does, and asking for them would be the synchronous query this port has never had. isOverwrite is the one of the three the user moves -- the Insert key -- which is why it is reported rather than being a field on the view.

• EditorText -- the answer to readEditor, and the only event that carries a document. Ask for one when you are about to write it to a file.

• Searched -- the answer to findInEditor and replaceInEditor. matches is how many were acted on: 0 or 1 for a find, however many were replaced otherwise. 0 is how a program says "not found" in its own words.

• Copied -- the answer to copyToClipboard. toSystem is False when nothing confirmed taking the text, which is weaker than it sounds and is not a failure: on a unix terminal the OSC 52 was written anyway and may well have landed. The text is kept either way, and readClipboard will give it back. See copyToClipboard for the whole chain and for what tmux does to it.

• ClipboardText -- the answer to readClipboard. fromSystem is False when what came back is this program's own last copy, because there was no system clipboard to ask.

• DialogClosed -- a dialog was dismissed. cmd is the button that closed it ("cancel" if it was canceled or closed from its frame), and values holds every field in it -- read them with text, number and flag.

• WindowResized -- the user moved, resized, zoomed or tiled a window, and rect is where it is now, in the same desktop coordinates as Window's own. A window that fills itself with a Grows view already resizes correctly without this; what needs it is a model that has to count -- how many rows of a file a dump can show, and therefore how far a page down goes.

  Not sent for a size the model itself set, on the same principle as Changed: only a change the model did not already know about is news. A model that ignores this keeps working, and the window keeps the size the user gave it, because what the differ compares against is the model's own rectangle and that has not changed. A model that stores rect and renders it back is the exact case this is for, and writes nothing either -- Resize is how it says which dimensions it is willing to be told about in the first place.

• WindowClosed -- the user closed a window from its frame. Handle this: if the model still lists the window, the next render reopens it.

• Unknown -- an event this version of the package does not understand.

What a Changed event carries. Four shapes because four kinds of control have a value the user can move, and they are not the same kind of thing:

• Text -- an InputLine's contents, after every edit.
• Flags -- one boolean per box of a CheckBoxes cluster, in the order the items were given.
• Choice -- which button of a RadioButtons cluster is on.
• Marks -- one state index per box of a MultiCheckBoxes cluster, in the same order.

They line up with text, flags, number and marks, which read the same four out of a dialog's answer.