Dynamic Windows and presentation-based interaction

CADR TV is an antecedent, not the same system

The public System 46 menu source already supports structured item lists rather than plain strings. An item can supply a displayed label, return value, evaluator or function action, documentation, font, and selection restrictions. The menu system computes geometry, tracks the current item, highlights it, and offers momentary, pop-up, multiple-choice, dynamic-item-list, and menu-choose interfaces. Mouse and frame sources coordinate tracking, exposure, selection, pane composition, and the who-line documentation string.

System 303 retains and expands this family. Its menu implementation includes computed font maps, dynamic multicolumn lists, temporary menus, multiple choice, and explicit who-line documentation methods. These mechanisms relate screen regions to operations, but the relationship is local to a menu or window implementation. The source does not declare the later presentation-type lattice, general PRESENT/ACCEPT duality, input contexts, or cross-application translator selection.

Dynamic Windows chronology

The 1989 design paper says the original system was developed in Symbolics Common Lisp during 1986–1987, first delivered to customers in 1987, and improved in early 1988. It describes CLIM as the then-in-progress portable CLOS-based successor. That is a contemporary lineage statement, not a claim that Genera 8.5 Dynamic Windows and CLIM 2 are interchangeable APIs. This museum treats CLIM on Genera as a separate dossier topic.

The paper also records an important intent: replace application programming in terms of active regions and low-level mouse callbacks with programming in terms of domain objects and operations. It identifies Concordia, the Font Editor, Graphic Editor, Display Debugger, and a business-graphics package as applications of the model. The licensed release and live world independently confirm several of those relationships.

Exact module inventory at the dossier grain

PRESENTATION-SUBSTRATE has six declared groups:

The standard type modules contain 133 DEFINE-PRESENTATION-TYPE forms at the selected file versions: 44 in core types, 19 numeric, 15 sequence, 48 general application/system types, and 7 character-style types. Conditional redefinitions and one source control escape mean this is a definition-form count, not a claim of 133 simultaneously distinct live names. The library spans Lisp objects, numeric ranges, sequences and membership, pathnames and files, time, fonts, systems, network and namespace objects, printers, windows, Flavors/CLOS/function specifications, syntax, and character styles.

DYNAMIC-WINDOWS then declares a main group for formatted output, cold support, redisplay, box geometry, displayed presentations, Dynamic Window streams, viewport graphics, window combinations, graphing, color, binary graphics, and activities; a separate command-method integration module; and graphics/formatted-output tests whose root module is deliberately false.

A user-interface type is not just a Lisp storage type

A presentation type describes the interactive meaning of an object. The same fixnum may be presented as a decimal number, an octal address, a menu choice, or a bounded coordinate. Conversely, a pathname type can describe different underlying pathname representations while retaining a common user-facing role.

The type syntax separates:

• data arguments, which refine membership or semantic subtype relationships;
• presentation arguments, which affect parsing, printing, view, defaulting or other interaction without necessarily changing the set of acceptable Lisp values;
• meta presentation options, understood by the substrate around a type; and
• compound types that call ACCEPT recursively for structured input.

Presentation types form a lattice. Exact type equality is not required: a subtype can satisfy a supertype input context, and a type can provide custom subtype/type predicates or expand into another type. The 8.5 implementation retains descriptors and cached lookup structures because data and presentation arguments cannot all be resolved statically.

Complete public method families

At this dossier's grain, a type descriptor can supply the following interaction families:

This list is deliberately more precise than “a type has a parser and printer,” while remaining bounded above the hundreds of application-specific types in the release.

Handler families

A handler can specify source and target types, gesture, tester, priority, documentation, menu visibility, highlighting policy, applicability in nested contexts, and whether it acts on an object or the presentation record. Selection therefore is not “first callback attached to this rectangle.” It searches type relationships and context, tests candidates, resolves priorities, and produces context-sensitive feedback.

The separately documented Presentation Inspector exists because this matching can be nontrivial. It reports presentation hierarchy, current contexts, effective priorities, gestures, menu placement, type reductions, and why candidates did or did not apply.

Runtime observation: this reviewed Genera 8.5 screen turns the abstract handler search into visible evidence. The inspected object is researcher-entered; the image is the first report page, not a dump of the world's handler database.

Program-level options

At the supported-workflow grain, a framework controls:

• state variables and inherited program flavors;
• command table, inheritance, command definer and keyboard accelerators;
• top-level function and process/selectability behavior;
• pretty name, activity/menu registration and Select key;
• panes, frame constraints and named configurations;
• terminal-I/O and selected interaction panes;
• initialization, selection, deselection and command-loop hooks; and
• whether panes redisplay after commands or on specific application requests.

The macro can define a useful internal program with :selectable nil. Therefore a literal framework definition proves a reusable program object, not that it appears in the activity table, System Menu, Select-key table, or default-window list. The software catalog applies that distinction to all 49 framework definitions found in the inspected media.

Standard pane types: six documented, seven registered

The Genera 8 programming manual documents the first six families below. The selected System 452.22 source registry also installs :TREE-BROWSER; this source/manual delta is why a compatible designer must enumerate the registry rather than hard-code the manual's list.

Frame-Up's complete commands, pane options, horizontal/vertical semantics, generated form and editor integration are documented in Screen Editor and Frame-Up. The actual two-pane model demonstrates that the declaration becomes a live program frame rather than a static mock-up:

Runtime observation: the reviewed screen shows a generated two-pane model and short command transcript. It supports the program-frame/pane analysis here; it does not claim that this synthetic layout exhausts the pane or constraint system.

menu-program

menu-program turns an arbitrary choice set into a presentation-aware temporary menu. Pointer selection can return a choice directly. Keyboard characters build a case-insensitive prefix, update the underlined match, and allow exact keyboard choice.

The source implements six command definitions; the previous/next split shares one parameterized command through two accelerators. That is why counting labels alone would undercount interaction while counting accelerators as commands would overcount implementation entries.

standalone Accepting Values

ACCEPTING-VALUES repeatedly displays typed queries inside a redisplay environment. Each field retains a query identifier, type, value/default state and presentation. Changing one query can selectively redisplay dependent output rather than rebuilding the whole form.

The file contains 12 standalone command-definition forms, seven explicit cursor accelerators plus the four command key accelerators (Refresh, Help, End, Abort), and presentation translators for values, choices, samples and buttons. Accept Values panes reuse the query/redisplay machinery but route four pane commands through the owning program and can install the same seven cursor accelerators in a separate inherited command table.

Runtime observation: in the fresh isolated Genera 8.5 world, Set GC Options opened this standalone typed form. An expression mistakenly entered while a Boolean field still owned input was rejected by that field's type checker and then removed. No option changed. Pointing at the printed Abort object changed the bottom mouse documentation to the form-specific abort operation; left-clicking it returned to the Dynamic Lisp Listener. This directly verifies typed field input, presentation-sensitive pointer documentation, redisplay after correction, and noncommitting pointer abort. The curated capture catalog records the exact interaction prefix, hashes, isolation, and shutdown result; the rights review limits publication to this analysis.

reorder-sequence

This nonselectable temporary framework has three commands:

It resizes near its invoking context, uses presentations for each element, and returns a reordered copy/working sequence. It is not a general list editor with insert/delete commands.

alter-sequences

This larger nonselectable framework operates on multiple candidate sequences:

The source defines five commands and two presentation-to-command translators. It also wraps the cross-sequence mutation in an abort-inhibited section to avoid losing or duplicating the element between the delete and insert operations.

undo-program

undo-program is a reusable program superclass, but its selected source lives in the optional Graphic Editor family rather than in the declared Dynamic Windows core or client modules. Bitmap, Stipple and Font Editors inherit it. That source location is important catalog evidence: the base framework supports command inheritance, but the particular branching undo implementation is not proved resident merely because Dynamic Windows is loaded.

There are four command-definition forms (Undo, Redo, Skip, and clear), while left/right command-menu handlers provide the immediate-versus-menu variants. The history can branch: an element's next link can become a list rather than a single successor. This is more expressive than two flat stacks and is not apparent from the short Undo/Redo labels inherited by applications.

Established by all three evidence layers

• Genera programs use presentation records to connect visible output to typed Lisp objects, and live applications expose those objects through context-sensitive gestures and commands.
• Command tables, menus, keyboard accelerators and pointer translators are different entry paths into the same command model.
• Program frameworks combine panes, state, command tables, redisplay and activity integration; Frame-Up edits/generates that declarative structure.
• Handler selection is sufficiently context- and type-dependent to justify a dedicated live Presentation Inspector.

Source findings that a conceptual manual can hide

• The release splits TV, PRESENTATION-SUBSTRATE, CP, DYNAMIC-WINDOWS, and DYNAMIC-WINDOW-CLIENTS; “Dynamic Windows” is not one indivisible load unit.
• TV deliberately loads selected Dynamic Windows graphics/flavor components before the complete subsystem, reflecting a boot/dependency constraint rather than a clean directory boundary.
• The 133 standard type-definition forms include conditional/repeated names, so a textual form count must not be rewritten as a live unique-type count.
• menu-program has keyboard prefix matching and one parameterized highlight command, behavior more specific than “pops up a menu.”
• Accept Values panes and standalone Accepting Values share query/redisplay machinery but use different command tables and resynchronization paths.
• alter-sequences protects the cross-pane move's critical mutation against aborts.
• undo-program supports branching redo history and is delivered with Graphic Editor source, not the base Dynamic Windows subsystem.

Paper-era limitations versus Genera 8.5

The 1989 paper reports global-translator lookup cost, expensive caches, procedural compound parsers/printers, limited user view preference, comparatively weak graphical input gadgets, and performance below conventional toolkits. Those are primary historical observations about the implementation then. This page does not silently promote them to verified Genera 8.5 defects. The later source contains expanded descriptors, lookup machinery, extensive graphics and program frameworks; determining which paper-era limitations remained requires targeted measurement or revision history.

Runtime boundary

The fresh Frame-Up, Presentation Inspector, and standalone Accepting Values sessions prove the program-frame, pane, presentation, context, typed-query, correction, redisplay, and handler layers in the preserved Genera 8.5 world. Other documented applications—Zmacs List Buffers, the Inspector, Document Examiner, Zmail, Flavor Examiner and the Display Debugger—supply additional cross-checks in their own dossiers. A dedicated standalone menu-program, reorder-sequence, alter-sequences, and branching-undo exercise remains deferred because these are internal or optional facilities whose safe invocation should use entirely synthetic data and an explicitly verified loaded definition.

Public antecedent source

Licensed Genera representatives

These identities are evidence metadata. The files remain untracked.